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:

      If you want to activate SSO on your Tenants you need to contact the Parashift Support. The information that is needed for the setup are the following:

      • Tenant ID and Name
      • SSO application that is wished to be used (ex. Microsoft Entra ID)

      The setup that is requested in this way allows the customer to administrate the User on their side, but the administration of the SSO is handled by Parashift.

      If you want to also administrate the SSO configuration, you have to provide us with the following information.

      Before SSO is enabled, Parashift tech support must pre-configure it in the internal id-api node. There's no UI for that, as sensitive attributes 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