Deciding on your Single Sign-on Strategy
This article will present a few different Single Sign-on (SSO) scenarios which should help you develop a strategy that will meet your single sign-on needs.
Step 1: Create a diagram
Before you do anything you want to diagram out where your users are and what content or sites you want them to have access to in ScreenSteps. Look at the example below:
In this case we have two different groups of users:
- Our employees who are all managed through Google G-Suite (this could also be Microsoft ADFS, Salesforce, Okta, OneLogin or any other user management system).
- Our customers who are all managed in our cloud-based web application.
We have three goals:
- Our employees can login to the Employee Knowledge Base using Google
- Our authors can login to the ScreenSteps Admin Console using Google
- Our customers can login to the Customer Knowledge Base using our web application
Drawing a simple diagram like this will make setting everything up correctly later on much easier.
Step 2: Create your single sign-on endpoints in ScreenSteps
Understand the single sign-on flow
It is important to understand the single sign-on flow when a user is trying to access content on ScreenSteps.
If a user tries to access a ScreenSteps site that has an SSO endpoint attached to it, then ScreenSteps will use that endpoint for user authentication.
In the example above, we have attached an SSO endpoint to our customer knowledge base that points to our cloud-based product. When a user tries to access our Customer Knowledge Base then they will be redirected to our cloud-based product to login.
If a ScreenSteps site does not have an SSO endpoint attached to it one of two things will happen:
- If the ScreenSteps account has an SSO endpoint configured and the ScreenSteps site is the default account associated with the account then the account SSO will be used.
- If it does not then the standard ScreenSteps login screen will be shown. SSO will not be used.
In the diagram above Google G-Suite as been set as the default for the account. Even though the Employee Knowledge Base does not have an SSO endpoint attached to it, Google G-Suite will be used to log them into the knowledge base because it is the default for the account.
If an account SSO endpoint has been set then it will be used for any access to the Admin Console.
If an account SSO endpoint has not been set then the standard ScreenSteps login screen will be used.
Step 3: Understand what happens when a user logs in via an SSO endpoint
When a user logs in via an SSO endpoint two things will happen:
- An existing user in your ScreenSteps account will be found or provisioned.
- The user will be added to the SSO user group unless they are already a member of that group.
Finding or provisioning the user
When a user logs in via an SSO endpoint ScreenSteps will look for an existing user with the same email address as the one provided by the SSO service. If that user exists then they will be logged in.
If a user with that email address does not exist then ScreenSteps will create a new user record in ScreenSteps.
Adding the user to a ScreenSteps user group
Each SSO endpoint is attached to a user group in ScreenSteps. This group is created when you create the SSO endpoint. In the example we have been using we would have two groups:
- Authentication Group (Google G-suite)
- Authentication Group (Customers)
It is important to understand that each time a user logs in using an SSO endpoint they will be added to the user group that is attached to that SSO endpoint.
Hopefully this have given you a good understanding of how to organize your SSO setup with ScreenSteps. Please don't hesitate to reach out to support if you have additional questions.