Single Sign On Detailed Documentation
The below document details all the functionality of each screen of the SSO configuration.
On the SSO Account Settings page, there are 3 distinct areas of functionality. The first is the area is the main enablement of SSO.
The first toggle (#1) is to enable SSO for your account. This cannot be enabled until you upload your Identity Provider Settings (see instructions here) and have at least one domain approved (discussed in the next section). Once this is enabled, your account is able to use SSO right away. Yet it does not impact accounts for existing users and they still are able to use the username and password they have.
This allows for you to administratively activate SSO, test and validate and then communicate to your clients the ability to use SSO asynchronously. This is to not have our platform enforce an immediate cutover when SSO is enabled and make it more convenient to work on your internal timeline.
The second toggle (#2) is to force non-Client Administrators to use SSO. Existing users can use their username/password unless this is enabled. This is the toggle you will want to enable once you have tested the SSO integration and informed your users of the change.
When this second switch is “On”, then non-Client Administrator users will be rejected by the traditional Lotame login pages, and those users will be forwarded back to the client's login system if they try.
To the right of those two toggles is an “Access Notes” info block (#3), which provides the URL’s at which your users can log in with your SSO solution (or in the case of client administrators, force yourself to log in with our login system in case you need to troubleshoot or fix your SSO).
The middle section of this page contains domain management.
Domain Management is where you can set up the expected email domains for your users. This allows Lotame to map a user email domain to your SSO configuration and forward them to your SSO platform for authentication.
New domains added go into a pending queue for Lotame Administrators to validate the domain before allowing it to be active on your account. You can see this with one of the two domains above showing “Pending”
New User Configuration
At the bottom of this main page is the Assigned Clients section.
By enabling the Auto-Create New Users toggle (#1), when a user to Lotame comes from your ID system, we will automatically create a credential in Lotame. This is a convenience feature and your requirements will dictate whether you want to use this feature or continue to ensure your Admins create users as a gate to control who can access the Lotame platform.
The next section allows you to determine which Clients can be accessed by a user created with this feature. For a new user, our SSO solution will by default give them access to each client listed along with default permission on that client (#2). Once the users are created in the Lotame platform, the existing Client Admin pages can be used to fully edit their access at a more granular level.
Service Provider Settings
The Service Provider settings page is information about Lotame you will need to add into your Identity Provider. Most commonly you can download the Identity Provider Metadata XML file that is compatible with most standing ID solutions and load this directly into your Identity Provider. The values are also read-only on the page so that you can copy and paste the values into your configuration UI if preferred.
Identity Provider Settings
The Identity Provider Settings page is where you upload the information about your Identity Provider into Lotame’s platform. The easiest option is to upload an Identity Provider Metadata XML file if you have one from your system. If your ID system does not have that functionality, you can manually enter the values on this page.
Lotame optionally supports Single Logout Redirect URL if you require SAML Single Sign Out functionality. Similarly, Lotame supports an Encryption Certificate if your Operational Security team requires it.
Log-level information for user authentication activity over the past 24 hours. This is particularly useful for troubleshooting SSO implementations. The log will show both assertions received and any errors around signature verification or new user creation.