Tenant Configuration
      Back to home
      1. Support Center
      2. Knowledge Base
      3. Tenant Configuration

      Single sign-on (SSO)

      Learn how to use the Single sign-on (SSO) authentication method on the Parashift platform

      Single Sign On (SSO) is a solution that delegates users' authentication process to a third-party service (Identity Provider). It allows users to reuse their existing accounts (convenience) and enables administrators to control access to a variety of resources by managing a single authentication center (security).

      Core assumptions

      The data model is rather strict in order to avoid ambiguity and simplify the overall design.

      • A tenant (Tenant) can use only one SSO provider (SsoIdentityProvider). Also, a SsoIdentityProvider can be assigned only to one Tenant. This avoids manipulating shared configuration which could lead to unexpected access to resources.
      • When a user is assigned to a tenant which has SSO configured (SSO tenant), then the SSO method takes precedence over the standard sign-in method (email/password).
      • A user can be assigned only to one SSO tenant. However, it is possible to create a hierarchy of tenants (via Tenant.super_tenant) in which only the super tenant is an SSO tenant, and sub-tenants inherit the method. This way, a user may have roles in two tenants having a common super tenant which has the SSO enabled.

      Steps to set up SSO for a tenant:

      Before SSO is enabled, it must be pre-configured by Parashift tech support in the internal id-api node. There's no UI for that as there are sensitive attributes that may not be exposed via API and should be exchanged via a trusted channel. 

      1. The customer adds on their side a new 'application' - an entity characterized by a set of keys (Client ID and Client Secret) and callback URL(s) provided by Parashift. The callback URL for prod is https://id.parashift.io/oidc/sso_callback. 
      2. Parashift collects attributes for configuration. The customer has to provide Parashift with the generated set of keys and a .well-known discovery endpoint which includes all the information needed for the integration.

      Examples of .well-known endpoints:

      Attributes:

      Before setting up, the attributes to be gathered (with examples from auth0.com) and passed on to the Parashift tech support (support@parashift.io) or the onboarding contact person are tabulated below.

      Attribute

      Source

      Example

      tenant_id

      Parashift

      1234

      redirect_uri

      Parashift

       https://id.parashift.io/oidc/sso_callback

      identifier

      Customer, known as Client ID

      o0XMfQs7ISMSYiHyLXgzh6q81eW5ixVv

      secret

      Customer, known as Client Secret

      7fc6474ddc641a3060e79b41643c2aa092410df7968ae0bc084bfecab86d5426

      issuer

      .well-known endpoint or provided by the customer

      https://dev-7t05cmyt.us.auth0.com/

      authorization_endpoint

      .well-known endpoint or provided by the customer

      https://dev-7t05cmyt.us.auth0.com/authorize

      token_endpoint

      .well-known endpoint or provided by the customer

      https://dev-7t05cmyt.us.auth0.com/oauth/token

      userinfo_endpoint

      .well-known endpoint or provided by the customer

      https://dev-7t05cmyt.us.auth0.com/userinfo