Protocols

SAML configuration is done by exchanging XML configuration blobs and configuring, on both sides, the attributes used for first name, last name, and email address. With SAML, there is fine-grain control over what information is sent from the IdP to the Service Provider (SP). This allows sending group membership and any other arbitrary data that is desired. At the current time, SingleStore Helios does not use anything besides first name, last name, and email address.

ODIC is generally easier to set up, but the instructions for any given IdP platform (Okta, Ping, etc.) are not obvious as the set of scopes is not well standardized. SingleStore Helios’s identity system supports IdP-initiated authentication with ODIC. SingleStore Helios Portal authentication sessions will last only as long as the access token granted by the customer IdP lasts or can be refreshed. This allows the IdP to force all sessions to close by invalidating the refresh token which may happen, for example, because an administrator removed the corresponding user. With the refresh token invalidated, the access token will expire and the session will close. SingleStore Helios does not limit the session length – that is up to the customer IdP’s policies.

Currently, IdP-initiated login and logout with SAML are not supported.

Settings Available

The following settings are available in:

General (not specific to OIDC or SAML)

JWT Token lifetime for engine access - This is for tokens generated via a browser login for accessing the SingleStore Helios database.
A list of email addresses of te format, username@domain or just username, that can bypass the per-domain SSO required setting and log in through the keycloak.

OIDC

Allowed Clock drift – useful when the IdP and SingleStore disagree about the current time.

SAML

Portal access (minutes) – determine how long should the tokens generated for the SingleStore Helios Portal last. You will have to re-authenticate when this runs out so a value like 1440 minutes (one day) is reasonable.