Single Sign-On

Configuration

Scalr supports SSO providers that use SAML 2.0. When SSO is activated, it will move the authentication step outside of Scalr and hand it over to the SSO provider that you have configured. During the login to Scalr, the user will be transferred to a sign-in page provided by the SSO server. After signing in, the user will then be redirected back to Scalr which will subsequently treat the user as signed in.

To enable SSO, go to the integration tab at the account scope and click on SAML IDP. You will then be given information that will be needed on in your SSO provider:

1214

Go to your SSO provider and start the configuration (see below for examples). The Scalr setup can be finished upon completion of the SSO provider configuration.

Upload the metadata file or manually fill in the fields required by your SSO provider and verify the connection when prompted:

2202

After you save the configuration, turn on the SSO authentication by going to the account settings:

2196

Okta Example

📘

Note

Scalr supports all SAML 2.0 providers, this is just an example of a commonly used one.

Create an application by clicking Applications, then Applications, and Create App Integration:

1208

Select SAML 2.0 in the “Create a new application integration” dialogue message:

921

Enter the “App name”, then select Next:

708

Configure SAML settings. Fill in the form as shown in the example below.

  • The “Single sign-on URL” is your SP endpoint, but with ?acs instead of /metadata at the end. Example: https://example.scalr.io/public/saml/idp-tl2g4mu9v47a111?acs

  • The “Audience URI (SP Entity ID)” is your SP endpoint. Example: https://example.scalr.io/public/saml/idp-tl2g4mu9v47a111/metadata

702

Ensure the “Group Attribute Statements (Optional)” field is populated in order for the user groups to be sent to Scalr correctly. It’s extremely important to correctly enter the “Attribute name”, “Format”, and “Filter” options as shown below:

691

Finishing the SAML integration:

708

When complete, you will be forwarded to a Sign On page where the SAML Service Provider configuration options link can be found. Click “View Setup Instructions” to see details:

1446

You can either upload the metadata to Scalr or manually enter the following. If the manual entry is being done, the following settings into the SAML setup in the Scalr UI. Be sure to use the ID and URL that you obtained previously:

Click save and you will now see the SSO option in Scalr upon the next login.

Azure AD SSO Example

📘

Note

Scalr supports all SAML 2.0 providers, this is just an example of a commonly used one.

Go to Azure Active Directory and click on Enterprise applications:

1152

Select New application and Create your own application:

1452

Name the application and select “integrate any other application you don’t find in the gallery”:

1050

Select “Set up single sign-on”:

1980

Click edit on the Basic SAML Configuration option and enter the following:

1502

Open the User Attributes & Claims, click add new claim, select “All groups”, and save:

2720

On the Single sign-on page, go to the SAML Signing Certificate section and download the Certificate (Base64). Paste that into the IDP x509cert section in Scalr:

Azure:

1372

Scalr:

1210

On the Azure Single sign-on page, go to the Set up section:

  • Login URL = the IDP single sign-on service URL in Scalr
  • Azure AD Identifier = the IDP entity ID in Scalr
  • Logout URL = is the IDP single logout service URL in Scalr

Azure:

1302

Scalr:

1204

In Azure, go to App registrations, find your app and click on it. Copy the Application (client) ID and Directory (tenant) ID, and paste the IDs into the respective fields in Scalr:

Azure:

2652

Scalr:

904

In Azure, click on Certificate & Secrets and generate a Client secret. Paste the secret into the respective field in Scalr:

Azure:

1616

Scalr:

904

In Azure, click on API Permissions. Add permission, select Microsoft Graph, Application permissions, and add Directory.Read.All. Ensure that “admin consent” is set to yes and the permission type is “application”.

2662

In Scalr, add the following settings in the mapping section:

1016

In Scalr, click on the advanced section and update the following fields:

  • IDP single sign on service binding = urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
  • SP name id format = urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
858

Click save and you will now see the SSO option in Scalr upon the next login.

Users and Teams with SSO

After Scalr has been reconfigured for SSO, users and teams work as follows:

  1. Teams map to SSO groups. Account admins have access to create teams in Scalr and the team name will be validated against the groups in SSO, so the team name must match the group name.

  2. Teams must link to at least one environment and account.

  3. Once a team has been linked and given the proper permissions, any member of the related SSO group can attempt to log in to Scalr. On the first login, a user record gets created in Scalr and set as SSO authenticated.

Break Glass Users

Incidents happen and it is likely that, at some point, your SSO provider will have an outage. If this happens, you can avoid being locked out of Scalr through the “break glass” feature. This feature allows you to specify a list of users who are exempt from SSO login the event of a SSO outage. These users can be specified by going to account settings:

2162

Edit the SSO setting:

1082

Now add the list of users who can bypass SSO when needed:

1732