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 Workspace (this could also be Microsoft Entra ID, 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: Configure Single Sign-on for your Content Management and Admin Centers and/or your Sites
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 is configured to use Single Sign-on, then ScreenSteps will use the identity provider endpoint for user authentication.
In the example above, we have configured Single Sign-on for 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 is not configured to use Single Sign-on then one of two things will happen:
- If the site is configured to use ScreenSteps username/password for login then the user will be taken to the ScreenSteps login page.
- If the site is configured to login through the Account Domain then ScreenSteps will check to see if the user is already logged into the your ScreenSteps account domain. If the user is logged in then they will be given access to the site they are trying to access. If they are not then the user will be sent to the login screen that is configured for the account.
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 associated with the SSO configuration for the site 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 configuration is attached to a user group in ScreenSteps. When configuring Single Sign-on for a site an existing group is assigned to it or a new group is created. In the example we have been using we would have two groups:
- Authentication Group (Google Workspace)
- 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.
Conclusion
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.
0 Comments
Add your comment