Key Concepts
Many businesses want to control access to their ScreenSteps site. There are several ways you can approach this depending on your needs. This article will describe some key concepts and approaches.
Identity Provider
The identity provider is the system that hosts the records for the users that you want to grant access to your ScreenSteps site.
The identity provider could be one of the following:
- Your own web application
- Your Salesforce instance
- ScreenSteps itself if you are creating your "reader" users in ScreenSteps
When deciding how to manage viewing access for your ScreenSteps site you need to have a clear idea of where the original user records are going to reside.
Authentication Mechanism
Once you know who the identity provider is you then need to decide what the authentication mechanism is going to be. Here are your options:
- ScreenSteps username/password
- SAML
- Remote Authentication
- Login via URL
ScreenSteps username/password
ScreenSteps username/password means that the users have a user record in ScreenSteps and they will login through the ScreenSteps login screen. For this to work, ScreenSteps must be your identity provider.
You will create user records in ScreenSteps and grant them permission to view your site.
SAML and Remote Authentication
With SAML or remote authentication you connect ScreenSteps to a separate identity provider. That identity provider needs to be able to:
- Login your user
- Send a response back to ScreenSteps to let ScreenSteps know that the user is a valid user
ScreenSteps offers two methods for doing this: SAML and our own flavor of remote authentication.
In order to support this your identity provider must support SAML authentication or you need to add code to the application that is functioning as the identity provider to send the authentication message back to ScreenSteps.
If you want to take this approach you can find instructions on using remote authentication here.
Login via URL
A third option is to log a user in via a url. This can be a valid approach if you have a separate identity provider from ScreenSteps, but you don't have any way to send the remote authentication response to ScreenSteps.
With Login via URL you put a URL on a page in a third party system that only your users can access. The URL contains a username and password embedded in the query parameters. When the user clicks on the URL they are taken to your ScreenSteps site and logged in.
Considerations
There are a couple of things to consider if you use this approach:
- Security - Obviously, anyone with the URL can login to view your ScreenSteps site. If someone where to copy the URL and share it with someone outside of your system then they would be given access.
- Shared login - Since everyone will be clicking on the same URL they will be logged in as the same user. For that reason we have created a special kind of user called an API Access User. This user type is designed for shared access. When a user logins as an API Access user they cannot change any user settings.
- Sharing URLs to articles - If you need to send a URL that points to an article in ScreenSteps directly to a customer then they won't be able to access the article unless they have recently logged in via the Login URL or you have embedded the login credentials in the direct URL.
Here is more information about embedding login credentials in a URL.
Which should I choose?
If you have a separate identity provider then the most reliable solution is to use SAML (preferred) or remote authentication. It will provide the lowest amount of friction for your users.
If you have a lower number of users then you can create user accounts for them in ScreenSteps but they will then have a separate ScreenSteps login/password from your current identity provider.
If neither of these options work for you then you can login users via URL.
Nicola Carraro
Can we have both local (for External consultants to be managed manually) and remote (for company users with SSO) authentication in place?
Trevor DeVore
@Nicola - No, you can only have one SSO authentication endpoint in place for each site. In this case you would need to have two sites - one that points to the local authentication provider and another that points to the remote authentication provider.