Identity

Every request reaching GreyCat Server must be identified to enforce security measures associated with the requested data. For every HTTP request, including all generated by SDKs, GreyCat relies on a cookie or bearer identification system. Cookies are stored on the session store of the browser to only renew the token when necessary (configurable). Cookies or bearer contains a so-called token that includes User ID and associated permissions. GreyCat token contains all information about roles and associated rights, encoded in binary compact mode. To create such tokens, a login phase is necessary and this can be done using the internal integrated Access Control server or external SSO. By default, this token is only available on a secure HTTPS server. To be able to use GreyCat AD using plain HTTP, use the following param.

greycat serve --unsecure

Also, the access control layer can be entirely bypassed by using the following

greycat serve --user=1

This impersonates all requests as user 1 which results in having no security. While being very useful during the development phase, this bypass should never be used in production.

Internal Identity Server

Roles and associated permissions can be edited through the explorer tools while running the server

Explorer can be accessed using the following URL:

http://127.0.0.1:8080/explorer

In addition within the GCL code, developers can also modify the security policy.

On the first run, GreyCat Serve generates a default policy configuration and a root password.

the password contains the root password, created at the first boot in case of an empty user_policy.json file

gcdata
├── security
│   ├── password
│   ├── private_key
│   └── user_policy.json

the two files

• private_key
• user_policy.json

should not be shared between DEV and PROD environment

the key is used to encrypt the token and the second contains all roles and permissions edited by hand or through the explorer.

External SSO

GreyCat can rely on an external SSO OpenID connect compatible server (AzureAD, Keycloak) for the login phase

this can be configured through two additional parameters

--oid_client_id=<str> OpenID Client ID to use for connection
--oid_config_url=<str> url to retrieve the OpenID configuration object. 
    Ex with Azure: https://login.microsoftonline.com/{TENANT_ID}/v2.0/.well-known/openid-configuration

Once configured with these two variables, GreyCat will now expose to default login.html pages that SSO is available. Users can therefore log in within their SSO provider page and be redirected to GreyCat. By default, GreyCat Roles will be mapped to SSO provider roles so please configure them according to your application needs.

It is important to notice that GreyCat does not use the JWT SSO token for every request since it is often very heavy. Instead, GreyCat generates an internal token very lightweight and will be regenerated after a pre-defined period. This period must remain short as it defines the potential de-synchronization between SSO roles and GreyCat logged-in users.