Setting Up SSO

This ability is limited to team members with the Admin role.

Manifest integrates with your SSO provider for authentication in a few easy steps. Please reach out to one of our team members on instant messenger or email us at [email protected] to get you started.

Before you begin

  • SSO configuration is completed together with the Manifest team in a synchronous, coordinated process. It is not self-serve: configuration details are exchanged and the login flow is verified end to end typically during a scheduled call with our support team.
  • Manifest supports either magic link (email) login or SSO for your organization, not both. Once SSO is enabled, all users in your organization must sign in through your identity provider, and magic link login is disabled for your organization.

Email Domain Requirements

SSO logins are matched to your Manifest organization by email domain. For a user to sign in via SSO, the email domain your identity provider returns for that user must be one of the domains allowed for your organization in Manifest.

These are not always the same domain. For example, if your external email is [email protected] but your Azure IdP issues emails as [email protected], both bar.com and bar.biz must be allowed for your organization. Tell us every domain your users may sign in with during setup: a user whose IdP email domain is not on the allowed list will not be able to sign in.

Getting Started

Step 1: Receive a unique redirect URI from Manifest to enter into your IDP. Manifest will send you your unique redirect URI when you are ready to kick off SSO configuration.

Step 2: Create a new application registration in your IDP using the URI provided by Manifest.

Step 3: Once you have successfully created the application in your IDP, you will need to provide Manifest with the information listed below. For security purposes, please do not email or instant message us with this information. We will ask for these details during our SSO setup call. If a setup call is not possible, we can determine a method for secure sharing of this information that works for both teams.

  • [Client ID]
  • [Client Secret]
  • [Issuer URL]
  • For AzureAD, look for the name: [Directory (tenant) ID].
    https://sts.windows.net/$DIRECTORY_TENANT_ID/ NOTE: the closing “/” is essential.
  • Optional[Claims]
    List of claims available on your tokens. Token claims give us information about the appropriate data mapping for your setup.
  • [Scopes]
    List of scopes you consent to providing. Most scopes are optional, but we generally recommend including the following scopes (or their equivalents in your IDP): [email],[profile],[openid].

Step 4: To enable the OIDC Connect to properly work, your application need to expose some graph permissions.

  1. Go to API Permissions
    Click on + Add Permissions -> Click on Microsoft Graph -> click on Delegated Permissions
  2. Search for OpenID.
  3. Click on Add permissions.

Step 5: Your application now have the sufficient permissions, now we need to make sure we expose the correct data into the token.

  1. Click on Token Configuration -> Click on +Add Optional Claim
  2. On the drawer, select ID token and pick preferred_username

Please note that different settings have different fields, please contact us if your identifying email is exposed under a different property.

On our end, we use this snippet to map your IdP token into internal Manifest schema:

local claims = std.extVar('claims');{ identity: { traits: { userId: if std.objectHas(claims, 'sub') then claims.sub else error "Missing userId", email: if std.objectHas(claims, 'preferred_username') then claims.preferred_username else if std.objectHas(claims, 'email') then claims.email else if std.objectHas(claims.raw_claims, 'upn') then claims.raw_claims.upn else error "Debug info: No valid email found. Claims object: " + std.toString(claims), name: if std.objectHas(claims, 'name') then claims.name else "", givenName: if std.objectHas(claims, 'given_name') then claims.given_name else "", familyName: if std.objectHas(claims, 'family_name') then claims.family_name else "" } } }

Once SSO is live for your organization

  • All users sign in through the SSO option on the login page. Magic link login no longer works for your organization.
  • Users with an email domain not on your organization's allowed list cannot sign in. Contact [email protected] to add or change allowed domains.
  • To make changes to your SSO configuration or revert to magic link login, reach out to the Manifest team; these changes follow the same coordinated process as initial setup.

Did this page help you?