This article applies to:
- SEG Service Provider Edition 4.X
- SQM
Question:
- How do customers configure a SAML provider for SSO?
Procedure:
SPE 4.X supports use of SAML based Single Sign On for the SQM console.
SPE 4.3.3 supports Single Sign On for both the SQM and the Customer Console. The remainder of this article references 4.3.3 interfaces.
When SSO is enabled for a customer, the Customer Console includes one or more configuration pages (see Configuration > Security Configuration > Single Sign On). These pages allow the customer to configure one or more providers as required.
- SSO works with SAML 2.0 compliant providers such as Google, Azure AD, and Microsoft ADFS.
- Note: For ADFS, the Certificate to be used is the Token Signing certificate from the ADFS server.
- Click Provider Metadata to download an XML file containing the metadata definitions for the SPE installation. This file can be imported to the provider.
- Click Add to create a new provider.
- This window displays the Entity ID and ACS URL for the SPE installation. You can use this information to configure the provider. If you import the metadata file to the provider, these items will be populated automatically.
- Complete configuration of SSO on the provider side.
- Ensure that you have enabled at least one user for SSO on the provider side.
- After SSO is configured on the provider side, enter the details given by the provider in the Identity Providers window: the Entity ID, the SSO URL, and the SSL certificate, if required.
- After saving the provider data, for SQM you can further select the default provider (using the button above the list).
- You can also select different providers for each domain (see Server Configuration > Domains).
- Console SSO only allows one provider.
- Test SSO with the user name that is enabled on the provider side.
- When ready to deploy SSO, enable all required groups or users for SSO on the provider side.
User Management - Customer Console
SSO for the Customer Console only authenticates existing Console users. You must create users and set permissions using the Console. Self provisioning is not supported.
- Caution: If the provider data is incorrect, no users in the organization will be allowed to log in. Before logging out of the session where you configure SSO, the customer should test using a different account.
- If a customer is unable to log in due to incorrect SSO settings, you can log on to the customer console using a Support login and disable SSO. Support logins always use the local password, not SSO.
User Management - SQM
When a SQM user is authenticated with SAML SSO for the first time, a user record is created and the user name/email address is added as the alias managed by this login.
- If the email address is already managed as an alias by an existing SQM user, then a SQM user is not created.
If the provider delivers additional alias information (multiple email addresses), then the additional aliases are added to the list of aliases managed by the user (unless they are already managed by another user).
- New aliases, if any, are added each time the user is authenticated via SSO.
- Aliases are not removed from SQM by the SSO process even if they are no longer listed by the provider.
Field mapping
When configuring SSO on the Provider site you might be required to enter the names of attributes. SQM uses the following attributes (note that all attributes are case INsensitive, and spaces are ignored):
- FullName, Name
- The personal name or friendly name of the user.
- User, UserName
- The primary email address for the user, and their login username. This value is only used if the username is not provided directly by the IDP.
- FirstName, GivenName
- Used to create Fullname if Fullname not present
- Surname, LastName
- Used to create Fullname if Fullname not present
- Email, EmailAddress, EmailAddresses, Alias, Aliases, Emails
- Any and all of these values will be added as alias email addresses. Some providers do not allow these attributes to be mapped.