Single sign-on (SSO) allows users to access multiple websites and applications with a single login through an identity provider of your choice. This approach delegates user authentication to the identity provider, enabling you to define your own security requirements and manage which users are authorized to access the Atlar web app. Atlar supports integration with identity providers that use Security Assertion Markup Language 2.0 (SAML 2.0). To set up Single sign-on for your Atlar organization, please contact Atlar.

How SSO works

1. Users log in to Atlar using a unique SSO login URL for your organization. This URL can be found under My Account > Your Organizations.
2. When users open the SSO login URL in their web browsers, they are automatically redirected to your identity provider for authentication. If they are already logged in, no action is needed; otherwise, they will be prompted to enter their credentials. After authentication, they are redirected back to Atlar with their user information.
3. Atlar verifies whether the users are members of the organization. If they are, they are logged in automatically. If they are not yet members, they need to be invited to the organization first.

Things to know about SSO

• Once SSO is set up for your organization, users with existing Atlar accounts will no longer be able to log in using their passwords.
• Users must be invited to the organization with a designated role to log in, similar to the process when using a password.
• If users change their email addresses, they will need to be re-invited to the organization.
• Only users with email addresses that match the allowed domains configured for your organization will be able to log in.
• Users can only log in using the SSO login URL (SP-initiated SSO). For security reasons, logins cannot be initiated from the identity provider (IdP-initiated SSO). However, many identity providers support storing the SSO login URL, allowing users to log in from the identity provider portal.

Setting up SSO

The setup process for SSO varies depending on your identity provider. Here are some guides to help you with your specific provider:

AWS IAM Identity Center

• Set up your own SAML 2.0 application
• Application start URL

Google

• Set up your own custom SAML app

Microsoft Entra ID

• Enable single sign-on for an enterprise application

Okta

• Create SAML app integrations
• Simulate an IdP-initiated flow with the Bookmark App

OneLogin

• Configuring SSO for SAML-Enabled Applications
• Advanced SAML Custom Connector

1. Create a custom SAML application in your identity provider

Log in to your identity provider and create a new custom SAML application, naming it something like "Atlar". If supported, you can also upload a logo to enhance the application's appearance:

• Square black logo with transparent background: PNG, SVG
• Other aspect ratios and colors: ZIP

Add Atlar service provider details

Enter the following information in your application:

• Assertion Consumer Service (ACS) URL: https://cognito.production.atlar.com/saml2/idpresponse
  • Sometimes named Single Sign-On URL or Reply URL.
  • If possible to set, use this for Destination URL and Recipient URL as well.
• Service Provider Entity ID: urn:amazon:cognito:sp:eu-central-1_8USGTETUo
  • Sometimes named Audience URI or Identifier.
• If possible to set, make sure Service Provider (SP)-initiated SSO is enabled

If desired, and if supported by your identity provider, Atlar can enable additional security features:

• Signing of SAML requests: Atlar will sign requests to your identity provider.
• Encryption of SAML assertions: Your identity provider must encrypt all SAML assertions using a public key provided by Atlar.

Atlar will provide the necessary signing and/or encryption certificates upon request.

Enable SAML response signing

It’s highly recommended to enable signing of SAML responses if your identity provider supports it.

Add attribute mapping for email address

Map the users’ primary email address to an attribute named email. If URLs are required, use http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Note that an email address attribute mapping is needed even if the users’ primary email address is used as the Name ID.

Set Name ID format and mapping

You can choose what to use as the required Name ID. However, it is recommended to use an opaque, consistent, and case-sensitive format.

Assign users to application

Assign which users are allowed to sign in with SSO on this application. Note that users will also need to be invited to the Atlar organization to log in to Atlar.

2. Send identity provider information to Atlar

Download the identity provider (IdP) metadata XML file created for this application and send it to Atlar. Also, provide the email address domain names allowed for your organization and the attribute name used for email addresses.

3. Atlar configures your identity provider

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

If supported by your identity provider, it is recommended to store the SSO login URL in the application so users can log in to Atlar through your identity provider portal.

4. Test logging in with SSO

You are now ready to test logging in with SSO.

Note that SSO is currently in testing mode, allowing users to log in with their passwords. The SSO login option is hidden from users, so Atlar will provide you with the SSO login URL for testing purposes.

5. Enable SSO

Once you have verified that SSO login works, you can ask Atlar to fully enable SSO for your organization. After this, users will be required to log in with SSO. This step requires approval from the organization owner.

Updating identity provider metadata

Atlar will track the expiry of the response signing certificate and contact you when it needs to be replaced. If you wish to update the identity provider metadata in advance, please contact [email protected].