Configure OIDC SSO
This document will guide you through the process of setting up OpenID Connect-based (OIDC) authentication for single sign-on (SSO) in Snorkel Flow. By the end of the step-by-step guide, you'll be able to log in to Snorkel Flow using your identity provider mediated by OpenID Connect.
Prerequisites
- An existing Snorkel Flow deployment
- Superadmin access to the Snorkel Flow deployment
- An OpenID Connect identity provider (e.g Okta, Google, or PingIdentity)
Configuring your identity provider
We recommend having three windows open: one for Snorkel Flow, another for your identity provider, and a third with these instructions. You'll be asked to copy and paste metadata between the two systems.
Initial configuration
Open the Admin Settings page in Snorkel Flow, and navigate to the Authentication Settings tab. In SSO Settings section, change SSO Status to Enabled and SSO Type to OIDC.
DO NOT set SSO Status to Required until you have successfully verified your setup, otherwise you risk being locked out of the instance. Once the SSO Status is set to Required, you will no longer be able to log in with username/password.
Continue to the next section to read a description for each of these settings.
Registering your identity provider with Snorkel Flow
Fill out the OIDC provider settings according to the descriptions in the table below.
Field | Description |
---|---|
Client ID | The client ID created by your identity provider. |
Client secret | The client secret created in pair with the client ID by your identity provider. |
Issuer ID | An ID used by the Identity provider, this may be a URL. |
Authorization endpoint | A URL provided from your identity provider for Authorization. |
Token endpoint | A URL provided from your identity provider for generation of tokens. |
User info endpoint | A URL provided from your identity provider for user info. |
JWKS endpoint | A URL provided from your identity provider for JWKS info. This may also be referred to as a cert endpoint. |
Redirect URIs | The URIs that are allowed for redirection for this OIDC token. These must match what is set in the identity provider settings. The default path used by Snorkel Flow is /api/sso/oidc/callback . |
User info handler | Leave field blank |
Resource ID | Leave field blank |
Unique field in user info response | If your OIDC provider uses a different field or format for user identification, you can customize this field to match the desired claim. The format is scope:claim . By default, this is set to email:email |
Once you’ve finished the configuration above, select Save at the bottom of the page.
Testing the connection
You can test the connection to your identity provider by using the Test SSO button on the Admin Settings page. This will attempt to perform an authentication handshake between your identity provider and your Snorkel Flow instance. If the connection is successful you'll be redirected back to the Admin Settings page with a success message. If not, you'll be presented an error message.
If you run into an error, review your steps through the guide above to ensure everything was configured correctly. You may need additional configuration on your identity provider side. If you need additional assistance, contact Snorkel AI support.
Requiring SSO login
As an administrator, you can require that all Snorkel Flow authentication use your SSO provider. This is enabled by changing the SSO Status from Enabled to Required.
As a prerequisite, all users must already have email addresses assigned to their profile in Snorkel Flow. Emails can be provided by Snorkel Flow administrators on the User Account Management tab on the Admin Settings page.
DO NOT set SSO Status to Required until you have successfully verified your setup, otherwise you will risk being locked out of the instance. Once the SSO Status is set to Required, you will no longer be able to log in with username/password.
Admission Roles
You can allow only specific users from your OIDC provider to connect to Snorkel Flow by using the Admission Roles feature. This field lets you set a list of the roles that a user must have at least one of to be allowed to login via OIDC.
Field | Description |
---|---|
Admission Roles | (Required) The roles allowed to sign in with snorkel. User must be one of these to pass admission. |
OIDC scope for admission role check | (Optional) If set, Snorkel will call /userinfo with the specified scope. |
OIDC claim for admission role check | (Optional) If set, Snorkel will use the content of this claim after calling userinfo for admission checks. |
Considered the following scenario:
You want only employees with the
SnorkelUser
role to access Snorkel Flow using SSO. This role information is stored inroles
scope underthirdparty
claim. (In this example, bothroles
andthirdparty
are specific to your company and not part of the spec for OIDC)
Then your settings should be:
Field | Description |
---|---|
Admission Roles | SnorkelUser |
OIDC scope for admission role check | roles |
OIDC claim for admission role check | thirdparty |
After the initial handshanke, the user specified scope (roles
) will be requested from the /userinfo
endpoint, and the user specified claim (thirdparty
) will be checked to get the list of roles from the user info response. If the user does not have the specified role (SnorkelUser
), they will be denied access for the log in.
However, if your OIDC provider provides the admission role as part of the initial request, no second request to /userinfo
is needed. In this case, you should omit the scope and claim field above and the platform will check the claim on the id_token
provided by the OIDC provider.