Single sign-on (SSO) enables an account to login to the Security Center using an identity provider (IDP) that supports SAML 2.0, such as Azure AD, Okta or OneLogin. This allows the account to use a centralized user management structure where users do not need to exist inside of Security Center to access the account. New users can easily be assigned to the Security Center from the IDP, and the security authentication process can be enhanced with MFA/2FA of any sort as it conforms to what the IDP supports.
How Single sign-on works with SAML 2.0
Security Assertion Markup Language (SAML) is a standard protocol that gives identity providers (IDP) a secure way to have a service provider (SP), in this case, Holm Security Center, know who a user is. It does this by sharing a cryptographically signed XML document with the Security Center confirming a user identity, along with some meta-information of the user.
When it is configured, a user can authenticate with the following steps:
- The user navigates to their Security Center SSO login URL.
- Security Center validates the URL, and the user's browser will be redirected to the configured IDP.
- The identity provider authenticates the user according to the IDP authentication process.
- Once authenticated, the browser is redirected to the Security Center with a SAML assertion.
- Security Center verifies the SAML assertion (and can provision a new user if needed).
- The user is granted access to the Security Center.
- User can now access their Security Center account.
Enable Single sign-on using SAML 2.0 in the Security Center
Access the Single sign-on (SSO) configuration:
- Opening the right menu inside the Security Center.
- Click on Settings.
- Select the Single Sign-on section.
To get started, apply a descriptive name of the configuration, e.g Example Organization Azure AD, and proceed by clicking Enable Single sign-on.
When enabling SSO on your account, it is important to remember the following:
- A unique login link connected to your Security Center account is created for SSO authentication. This unique login link should be bookmarked as it is the path to your account using SSO.
- Users can now log in to your account via your IDP (when properly configured).
- Local users that have been converted can only log in via SSO.
- An SSO user has higher priority over a local Security Center user, meaning that if a SSO user is signing in, it will convert any existing matching username to a SSO user.
- The primary superuser in the Security Center can not be converted to a SSO user.
Configure Single sign-on with SAML 2.0
Each IDP treats SAML 2.0 slightly different; even if it is a standard, the implementation of it will vary. To support this over several vendors, the Security Center provides three options to configure it:
- Metadata URL
Provide a publicly accessible URL with the IDP metadata. - Metadata file
Upload the IDP metadata file. - Manual settings
Apply the IDP settings manual.
All of this information is coming from the IDP. Metadata URL is the easiest way to get started by providing the URL from the IDP. Ensure you are logged in to the IDP in the same browser as the Security Center if you use the Metadata URL. Otherwise, it will lead to access error and failure to fetch the data.
Some IDPs only allows you to download the metadata file; this is where uploading it to the Security Center comes in handy.
In rare cases, you need to provide the settings manually, which require you to get the following information from the IDP:
- IDP login URL
- IDP entity ID/Metadata URL
- IDP Certificate
String representation of the IDP certificate that you paste into this field.
Security Center SAML 2.0 configuration
: The identity provider requires specific data from the Security Center to be configured properly. This data can be found in the following fields and needs to be configured and saved in the IDP for SSO to work properly:
- Customer login URL
The URL users use to log in to Security Center and the IDP redirect to when authentication is completed. - Login callback URL
Security Center SAML callback URL. - Metadata URL
Security Center SAML metadata URL. - Certificate
It can be copied or downloaded as a CRT-formatted certificate.
User attribute mapping
Security Center automatically mapping aliases from the IDP to the user attributes inside of the account in the Security Center. This is handy for supplying more information about the user that will be present within Security Center.
Below is a description of what attributes are supported, what are required, and what aliases in the IDP we are looking for to retrieve the attribute's value.
Attribute: | Required: | IDP Aliases supported (case-insensitive): |
---|---|---|
First Name | False | first_name, firstName, firstname, First_Name, FirstName |
Last Name | False | last_name, lastName, lastname, Last_Name, LastName, surname, surName |
True | email, emailAddress, loginAddress, email_address, login_address, EmailAddress | |
Phone Number | False | phone, phoneNumber, phone_number, PhoneNumber |
Role | False | user_role, userRole |
Name ID | True | Okta/Onelogin: Persistent Azure (Unique User Identifier): user.userprincipalname |
The Role of the user can be mapped to the Security Center Superuser role by using one of these values (case insensitive):
- holm_superuser
- holm-superuser