External Authentication¶
Note
If you want to configure SSO on scalr.io, please see Identity and Access Management.
SAML Integration¶
When SAML is activated, it will move the authentication step outside of Scalr and hand it over to the SAML server that you have configured. During sign in to Scalr, the user will be transferred to a sign in page provided by the SAML server. After sign in, the user will then be redirected back to Scalr which will subsequently treat the user as signed in. Each account in Scalr can have a separate SAML provider if your organization requires it.
To enable SAML, you must configure it in the global area of the Scalr UI. To do this:
Log in as a global admin, click on the Scalr icon on the top left and go to IAM -> identity providers:
Note down the SP endpoint as that will be used with the SAML provider. For example:
https://scalr.server/public/saml/idp-sp986542njcvhjv78?metadata
andhttps://scalr.server/public/saml/idp-sp986542njcvhjv78?acs
Fill in the fields required by your SAML provider.
After you save the SAML configuration, link the provider to an account:
Note
In the event you need to log in with a local administrator, add the following to the end of your Scalr url to avoid the SAML login screen: #?no-login-redirect
(https://your.scalrserver.com#?no-login-redirect
)
SAML Example : Okta¶
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:
Select SAML 2.0 in the “Create a new application integration” dialogue message:
Enter the “App name”, then select Next:
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
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” option as shown below:
Finishing the SAML integration:
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:
You can either upload the metadata to Scalr or manually enter the following. If the manual entry is being done, the following settings in to the SAML setup in the Scalr UI. Be sure to use the ID and URL that you obtained previously:
idp entity_id => http://www.okta.com/exk8ldhenajn8ckSdgh6
idp single_sign_on_service url => https://scalr.oktapreview.com/app/scalrincdev369111_scalr_1/exk8ldhenajn8ckS1111/sso/saml
idp x509cert => —–Cert Goes Here—–
Click save and you will now see the SSO option in Scalr upon the next login.
SAML Example : Azure AD SSO¶
Note
Scalr supports all SAML providers, this is just an example of a commonly used one.
Go to Azure Active Directory and click on Enterprise applications:
Select New application and Create your own application:
Name the application and select “integrate any other application you don’t find in the gallery”:
Select “Set up single sign on”:
Click edit on the Basic SAML Configuration option and enter the following:
Identifier = SP Endpoint from Scalr
Reply URL = FQDN of the Scalr endpoint
Sign on URL = the Scalr FQDN with /public/saml?acs at the end of it (i.e. https://my-account.scalr.io/public/saml?acs)
Click save
Open the User Attributes & Claims, click add new claim, add user.groups [All], and save:
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:
On the Azure Single sign-on page, go to the Set up <your app name> section:
Login URL = the IDP single sign on service URL in Scalr
Azure AD Identifier = the IDP entity ID in Scalr
Logout URL = the is the IDP single logout service URL in Scalr
In Azure, go to App registrations, find your app and click on it. Copy the Application (client) ID and Directory (tenant) ID, paste the IDs into the respective fields in Scalr:
In Azure, click on Certificate & Secrets and generate a Client secret. Paste the secret into the respective field in Scalr:
In Azure, click on API Permissions. Add a permission, select Microsoft Graph, Application permissions, and add Directory.Read.All
In Scalr, add the following settings in the mapping section:
Groups = http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
Email = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Fullname = http://schemas.microsoft.com/identity/claims/displayname
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
Click save and you will now see the SAML option in Scalr upon the next login:
Users and Teams with SAML¶
After Scalr has been reconfigured for SAML, users and teams work as follows.
Teams map to AD/LDAP groups. Account admins still have to create teams in Scalr but the team name will be validated against the groups in AD/LDAP, so the team name must match the group name.
Teams must linked to at least one environment
Once a team has been linked, any member of the related LDAP group can attempt to login to Scalr. On first login a user record gets created in Scalr and set as LDAP authenticated.
Scalr admin can still create Scalr authenticated users to act as global and account admins. SAML authenticated users can also be set as global and account admins.
If a user has access to more than one account, they will be prompted to select an account during login.
LDAP Integration¶
Integration with Scalr¶
When LDAP is activated, it will move the authentication and user management outside of Scalr and hand it over to the LDAP server that you have configured. Each account in Scalr can have a separate LDAP provider if your organization requires it.
Configuration¶
To enable LDAP, you must configure it in the global area of the Scalr UI. To do this:
Log in as a global admin, click on the Scalr icon on the top left and go to IAM -> identity providers:
Fill in the fields required by your LDAP server.
After you save the LDAP configuration, link the provider to an account:
Users and Teams with LDAP¶
After Scalr has been reconfigured for LDAP, users and teams work as follows.
Teams map to AD/LDAP groups. Account admins still have to create teams in Scalr but the team name will be validated against the groups in AD/LDAP, so the team name must match the group name.
Teams must linked to at least one environment
Once a team has been linked, any member of the related LDAP group can attempt to login to Scalr. On first login a user record gets created in Scalr and set as LDAP authenticated.
Scalr admin can still create Scalr authenticated users to act as global and account admins. SAML authenticated users can also be set as global and account admins.
If a user has access to more than one account, they will be prompted to select an account during login.