A Single Sign On (SSO) allows users to access multiple related, but independent software systems without needing multiple accounts. SSOs are a convenient way for our clients to make one site the central hub for everything a user would need to access. Many clients will use Wisetail as their site to login to and the users will then gain access to other sites from there. For others, Wisetail is a site that is accessed with no login from another internal site they use (such as your HRIS).
An SSO is not a datafeed, though they can be used together to fit your needs. See this article for more info on what sets them apart.
We have a Glossary of SSO-related terms here.
What types of SSO’s can we support?
SAML is the open generic, standard SSO. This involves three parties: The user, an identity provider and a service provider. This functions by a user originating in the identity provider system and requesting access to the service provider system.
Want to learn more? Check out The Beer Drinker's Guide to SAML.
Oauth functions by a user granting a third party system access to THEIR data housed in another system. For example, we’ve all encountered a site that says “Log in with your Google account” or “Log in with Facebook”. This is an Oauth SSO - essentially when the user is asked to log into a third party system via their Google or Facebook accounts, they’re allowing that third party site to access their data held within Google or Facebook. Example use case: A user is trying to log into Spotify (SP) with their Google account (IDP). When they are in Spotify, they click “log in with Google” at which point they’re redirected to Google and asked to allow certain permissions. Upon acceptance of these permissions, they will be redirected back to Spotify with authorization to access.
- Pro Tip: For further reading on Oauth - “What the Heck is Oauth?”
ADFS is the Active Directory Federation Services. This functions through an identity federation, which allows a company to share selected information from their users with another company in the identity federation. The identity federation uses a trust policy and claims based access control model to verify and authenticate users. This functions by an organization (IDP) authenticating a user based on a set of claims about the user’s identity, these claims are transmitted to a service provider in a trust token. The other organization (SP) in the identity federation receives and validates the token - at which point the SP generates another token to accept the identity defined by the claims in the first token. This results in the user gaining access to the service provider’s site.
IDP vs. SP Initiation
When doing SSO there are two ways things get initiated:
This means a user logs into the system of record (IDP) and clicks a button to log into a separate system (SP). For example, if a client is using Okta as an IDP and Wisetail as the SP, their users would log into Okta and click a button that brings them to Wisetail.
How does this function? A user will log into the IDP (Okta) and then the identity provider sends a request to the SP (Wisetail) verifying the user and requesting access to sign that user into our site, without the user needing to enter credentials. User’s do not need a password because during the process of configuring an SSO we establish a trust connection that typically involves an SSL and the user is automatically validated by their unique ID.
In this case, as soon as users hit our login page we redirect automatically to another system. OR we have a button that says “Click here to SSO”.
How does this function? The request comes from the service provider and sends it to the IDP, if systems could speak it would sound something like this “Hey, this user would like to log in, please log them in and send them back to me once complete”. Similar to IDP login, except original request comes from service provider.