Skip to main content

How do I configure Single Sign-On (SSO) for Atlas?

D
Written by Daria Nasedkina

What is Single Sign-On (SSO)?

Single Sign-On (SSO) lets users access Atlas using their existing corporate credentials instead of a separate Atlas-specific username and password. Atlas supports logging in through your organisation's identity provider (IdP), such as Microsoft Entra ID (Azure AD), Okta, or Google Workspace.

Some terms you'll see:

  • Service Provider (SP) – Atlas, the system users are logging into.

  • Identity Provider (IdP) – the system that confirms who the user is (for example Google Workspace, Azure AD / Entra ID, Okta).

  • SAML 2.0 – the technical standard that lets the IdP and Atlas talk to each other. You don't need to know the details, but both sides need matching settings.

Is it a paid-for feature?

Yes, this needs to be purchased. Please get in touch with your Client Development Manager for more details.

Who can configure SSO

Any user with one of the following profiles automatically has access to configure SSO:

  • Training Service Owner

  • Training Admin

Before you start

Make sure you have:

  • An Atlas account with SSO configuration rights.
    Your Atlas account must have permission to configure SSO.

  • Admin access to your SSO system.
    You must be able to create or edit an SSO / SAML application in your identity provider (IdP), such as:

    • Google Workspace (Google Admin console)

    • Azure AD / Entra ID

    • Okta

    • Auth0

    • Or another SAML 2.0-compatible system

  • A clear idea of who should use SSO.
    Decide which users or groups should be allowed to log into Atlas using SSO.

Step 0 (in Atlas) – Open the SSO configuration wizard

  1. Log in to Atlas.

  2. Go to Single Sign On from the menu on the left.

  3. Click the Add identity provider button.

Step 1 (in Atlas) – Configure name & select protocol

  1. When asked for a Configuration name, use something clear, for example "Google Workspace SSO", "Azure AD SSO", or "Okta SSO".

  2. If asked for the protocol, choose SAML 2.0.

  3. Click Next.

Step 2.1 (in Atlas) – Get Atlas SSO endpoints

Atlas shows you some URLs that you must copy into your IdP:

  • User Login URL

  • Assertion Consumer Service (ACS) URL

  • Entity ID / Metadata URL

Keep this page open, or copy these values somewhere safe and secure — you'll need to paste them into your IdP admin console in the next step.

Step 2.2 (in IdP console) – Set up the Atlas app in your identity provider

Now create or edit the SSO / SAML app on your IdP side, using the values you just got from Atlas.

1. Create or select the SAML application

  1. Sign in to your IdP admin area.

  2. Go to where you manage applications or SSO integrations. For example:

    • Google Workspace: Apps → Web and mobile apps

    • Azure AD / Entra ID: Enterprise applications

    • Okta: Applications

    • Auth0: Applications

  3. Create a new SAML / SAML 2.0 application for Atlas, or open an existing one if it's already been created.

  4. Give it a clear name, such as "Atlas SAML SSO".

2. Add the Atlas details to the IdP

In the SAML settings for the app you just created:

  1. Find the fields related to the Service Provider or SP.

  2. Enter the values from the Atlas SSO wizard:

    • Assertion Consumer Service (ACS) URL / Single Sign On URL: paste the Single Sign On URL from Atlas.

    • Audience URI / Entity ID: paste the Audience / Entity ID from Atlas.

    • Name ID format: if in doubt, set this to Email or EmailAddress, unless your Atlas documentation or admin tells you otherwise.

    • Name ID source: normally the user's primary email address or another unique identifier.

  3. Save your changes in the IdP.

3. Configure which user details are sent (attributes / claims)

Atlas needs some basic user information to identify people. In your IdP SAML settings:

  1. Find where you configure attributes, claims, or mappings for the SAML app.

  2. Make sure you're sending at least: email address, first name, and last name.

  3. Use simple, clear attribute names so you can map them easily in Atlas. Common examples: email, given_name (first name), family_name (last name).

  4. Optionally, you can also send other details like department, role, or phone number, if your organisation or Atlas setup needs them.

  5. Save the attribute / claim configuration.

4. Allow the right users to use the Atlas app

  1. In your IdP, assign the Atlas SAML application to the right users or groups (for example, "All staff" or a specific department).

  2. Make sure at least one test user account (that you can log in with) has access to the app.

Step 3 (in Atlas) – Configure Service Provider (get metadata, URLs, certificate from your IdP)

In your IdP app for Atlas, find the section for SAML metadata or IdP metadata. This may let you:

  • Download a metadata XML file, or

  • Copy individual values such as:

    • IdP SSO URL (sometimes called SAML login URL or Single Sign On URL)

    • Entity ID / Issuer for the IdP

    • Signing certificate

Copy this information into the relevant fields in Atlas.

  • If Atlas asks for a logout URL, add it if your IdP supports SAML logout for this app. If you're not sure, it's usually safe to leave it blank or follow your admin's instructions.

  • Click Next.

Step 4 (in Atlas) – Map user attributes

Now tell Atlas which SAML attributes match which user fields. You can choose default or custom attribute mapping. For custom mapping, in the User attribute mapping step in Atlas:

  1. Map the attribute that contains the email address (for example email) to the Atlas email field.

  2. Map the attribute that contains the first name (for example given_name) to the Atlas first name field.

  3. Map the attribute that contains the last name (for example family_name) to the Atlas last name field.

  4. If Atlas shows optional fields like phone number or department, you can map them if you're sending those attributes from the IdP, or leave them blank.

  5. Make sure all required fields are mapped.

  6. Save your mappings and complete the wizard.

When you're done, click Next and check that Atlas confirms the configuration has been saved without errors.

Step 5 (in Atlas) – Additional settings

Here you can set up the following rules:

  • Just-in-Time (JIT) provisioning: let Atlas automatically create a user account the first time someone signs in via your SSO provider, using their SSO profile details.

  • Force SSO: require everyone to log in only through SSO, so users aren't given the option to sign in with separate Atlas credentials.

Once done, click Save.

Step 6 (in Atlas) – Test the SSO connection

  1. On the Atlas SSO configuration page, find the Identity Provider (IdP) you just added.

  2. In the Action column for this IdP, click the (...) menu and select Test connection.

  3. Start the test.

What should happen next:

  1. Atlas redirects you to your IdP's login page for the Atlas app.

  2. You sign in using your test user account (which already has access to the Atlas app in the IdP).

  3. After logging in, you're redirected back to Atlas.

  4. Atlas displays a message confirming that the connection test was successful.

  5. If all of this works, your SSO trust and user attribute mappings are very likely configured correctly.

Troubleshooting

If the test fails or users can't log in with SSO, check the following:

  • Endpoint values: make sure the Single Sign On / ACS URL and Audience / Entity ID in your IdP match exactly what Atlas shows in the SSO endpoints step.

  • IdP details in Atlas: confirm the IdP SSO URL, Entity ID / Issuer, and certificate in Atlas are correct and up to date.

  • User access: check that users exist in both systems — your IdP and Atlas — with matching emails or identifiers.

  • Attribute names and mappings: make sure the attribute names you set in the IdP (for example email, given_name, family_name) match the ones you chose in the Atlas attribute mapping step.

  • Error messages and logs: look at any error messages shown in Atlas and in your IdP's SSO / SAML logs. They often point to whether the problem is with URLs / endpoints, certificates, or attributes / claims.

If you still can't solve the issue, share the error messages and log snippets (without sensitive information) with your internal IT / administrator, or Atlas support.

Did this answer your question?