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 the user id and an expiry, signed with the private key of the server. Permissions are not stored in the token. They are read from the current role of the user on every request, so a role change applies to open sessions at once. To create such tokens, a login phase is necessary and this can be done using the internal integrated Access Control server or external SSO. The login endpoint is runtime::Identity::login(login, password), which returns a token and sets the greycat cookie. The built-in webroot/index.html uses it to sign in. From the command line, greycat token --user=<name> prints a token for the user <name>, to send in the Authorization header.

By default, the GreyCat 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=root

This impersonates all requests as the root user which results in having no security.

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 creates the public and root users, a root password and a root token.

gcdata
├── security
│   ├── password
│   ├── private_key
│   ├── token
│   └── users.mdb

the two files

• private_key
• users.mdb

should not be shared between DEV and PROD environment

the key is used to sign the tokens and the second is the user database (names, passwords, roles and grants). Roles and their permissions are declared in the code with @role and @permission (see Permissions).

External SSO

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

This is provided by the openid library, which registers the providers in GCL and resolves each SSO user to a GreyCat identity. Users can therefore log in within their SSO provider page and be redirected to GreyCat. See External SSO for the configuration.

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, which is valid for the duration set by --validity.