Single sign-on (SSO) enables an account to login to Security Center using an identity provider (IDP) that supports SAML 2.0 such as Azure AD, Okta or OneLogin. This allows the account to make use of a centralized user management structure where users do not need to exist inside of Security Center to be able to access the account. New users can easily be assigned to 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 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 Security Center with a SAML assertion
- Security Center verifies the SAML assertion (and can provision a new user if needed)
- User is granted access to Security Center
- User can now access their Security Center account
Enable Single sign-on using SAML 2.0 in Security Center
Access the Single sign-on (SSO) configuration:
- Opening the right menu inside of 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, 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 in to your account using SSO
- Users can now login to your account via your IDP (when properly configured)
- Local users that has been converted can only login via SSO
- A SSO user has higher priority over a local Security Center user which means that if a SSO user is signing in, it will convert any existing matching username to a SSO user.
- The primary superuser in Security Center can not be converted to a SSO user
Each IDP treats SAML 2.0 slightly different, even if it is a standard the implementation of it will vary. In order to support this over several vendors Security Center provides three options to configure it:
- Metadata URL - Provide a public accessible URL with the IDP metadata
- Metadata file - Upload the IDP metadata file
- Manual settings - Apply 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 that you are logged in to the IDP in the same browser as Security Center if you are using Metadata URL. Otherwise it will lead to access error and failure to fetch the data.
Some IDP's only allows you to download the metadata file, this is where uploading it to 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 in to this field
The identity provider is requiring specific data from Security Center in order to be configured properly. This data can be found in the following fields and needs to be configured and saved in the IDP in order for SSO to work properly:
- Customer login URL - The URL which users are using to login to Security Center and the IDP is using to redirect to when authentication is completed
- Login callback URL - Security Center SAML callback URL
- Metadata URL - Security Center SAML metadata URL
- Certificate - Can be copied or downloaded as a CRT formatted certificate
Security Center is automatically mapping aliases from the IDP to the user attributes inside of the account in Security Center. This is handy to supply more information of the user that will be present within Security Center.
Below is describing what attributes that are supported, what are required and what aliases in the IDP that we are looking for in order to retrieve the value for the attribute.
|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|
|Name ID||True||Okta/Onelogin: Persistent
Azure (Unique User Identifier): user.userprincipalname
The Role of the user can be mapped to Security Center Superuser role by using one of these values (case insensitive):