Single Sign-On (SSO)

💡

Centralize user authentication with your own identity provider Single Sign-On (SSO) allows users to access Atlar through a single login managed by your identity provider. Atlar supports SAML 2.0 to give you full control over security policies and user access.


How SSO works

  1. Start login
    • Users log in to Atlar by entering their email address, and are then presented with an option to log in with SSO.
    • Alternatively, users can log in directly using their organization’s SSO login URL, available under My Account → Your Organizations.
  2. Authenticate with the identity provider
    • When users choose SSO (or open the SSO login URL), they are redirected to your identity provider.
    • If they are already authenticated, no further action is required.
    • Otherwise, they are prompted to enter their credentials, based on your organization's security policies.
  3. Access Atlar
    • After successful authentication, Atlar verifies the user’s organization membership and logs them in automatically.
    • Users who are not yet members must be invited to the organization before they can access Atlar.

Things to know about SSO

  • Once SSO is enabled, users cannot log in with passwords.
  • Users must still be invited to the organization with a designated role.
  • Changing a user’s email requires a new invitation.
  • Only email addresses matching your allowed email domains can log in.
  • Users must be assigned to the identity provider’s SAML application for Atlar.
  • Users can only log in from Atlar (SP-initiated SSO).
    • Logging in from the identity provider (IdP-initiated SSO) is not supported.
    • Most identity providers allow storing the SSO login URL in their portal as a workaround.
  • Automatic redirection to your identity provider based on email domain is enabled by default.
    • Contact Atlar if you want this behavior disabled.
  • API integrations are unaffected and continue using the existing authentication methods.

Setting up SSO

To enable SSO, Atlar must configure your identity provider. The process varies depending on your provider.

Step 1: Create a custom SAML application

Log in to your identity provider and create a new custom SAML app, naming it “Atlar”. Upload a logo if supported:

  • Square black logo: PNG, SVG
  • All assets: ZIP

Add Atlar service provider details

FieldValue
Assertion Consumer Service (ACS) URLhttps://cognito.production.atlar.com/saml2/idpresponse
Service Provider (SP) Entity IDurn:amazon:cognito:sp:eu-central-1_8USGTETUo
  • Sometimes ACS is called Single Sign-On URL or Reply URL. Use it also for Destination URL and Recipient URL if possible.
  • Enable SP-initiated SSO and Redirect Binding if supported.

Security options (optional)

Atlar can enable:

  • Signed SAML requests – Atlar signs requests to your IdP.
  • Encrypted SAML assertions – Your IdP encrypts all SAML assertions with a public key provided by Atlar.

Atlar will supply signing and encryption certificates if needed.

Attribute mapping

  • Map the user’s primary email to an attribute named email.
    • If a URL is required, use: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  • Set the Name ID to a stable, case-sensitive identifier (email recommended).

Assign users

Grant access to users who will sign in via SSO. They must still be invited to the Atlar organization.

Step 2: Share IdP metadata with Atlar

Provide Atlar with:

  • The SAML metadata for your identity provider, either as:
    • a metadata URL (preferred), or
    • a metadata XML file.
  • The allowed email domains for your organization.
  • The attribute name used for email addresses.
  • Whether automatic redirection to the identity provider based on email domain should be disabled (this behavior is enabled by default).

Atlar will configure the identity provider and generate a unique SSO login URL for your organization.

Step 3: Test SSO login

Atlar will provide the SSO login URL for testing.

During the testing phase:

  • Password-based login remains enabled.
  • The option to log in with SSO is hidden, except when users access Atlar via the SSO login URL.

Step 4: Enable SSO

Once testing is complete, request Atlar to enable SSO for your organization.

  • This step requires Owner approval.
  • After SSO is enabled, all users must authenticate using SSO.
  • Password-based login is disabled at this point.

Updating IdP metadata

  • Atlar tracks the expiry of your response signing certificate and will notify you when it needs replacement.
  • If you provided a metadata URL, Atlar automatically refreshes metadata at regular intervals.
  • During certificate rotation, configure your IdP to publish both old and new certificates for at least 6 hours.

Troubleshooting

Use an incognito browser window when testing changes to avoid caching issues.

Google Workspace

If you see a Google error page, refer to SAML app error messages.

Common issues:

  • Error: app_not_enabled_for_user – The user has not been granted access to the SAML app.

Provider-specific guides