Skip to main content
Version: 0.95

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.

warning

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.

oidc_setup_11.webp

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.

FieldDescription
Client IDThe client ID created by your identity provider.
Client secretThe client secret created in pair with the client ID by your identity provider.
Issuer IDAn ID used by the Identity provider, this may be a URL.
Authorization endpointA URL provided from your identity provider for Authorization.
Token endpointA URL provided from your identity provider for generation of tokens.
User info endpointA URL provided from your identity provider for user info.
JWKS endpointA URL provided from your identity provider for JWKS info. This may also be referred to as a cert endpoint.
Redirect URIsThe 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 handlerLeave field blank
Resource IDLeave field blank
Unique field in user info responseIf 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.

warning

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.

admission-role-settings.webp

FieldDescription
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 in roles scope under thirdparty claim. (In this example, both roles and thirdparty are specific to your company and not part of the spec for OIDC)

Then your settings should be:

FieldDescription
Admission RolesSnorkelUser
OIDC scope for admission role checkroles
OIDC claim for admission role checkthirdparty

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.