What is a Single Sign On (SSO)?

by C.W. Holeman III

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 2.0

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.


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. 


Wisetail does not support Oauth.

IDP vs. SP

IdP :Identity Provider.

SP: Service Provider.

When doing SSO there are two ways things get initiated:

 IDP 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.

SP Initiated

In this case, as soon as users hit our login page we redirect automatically to another system. Or there is a button: Click here to log in via 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. 

Next Up:

Configuring a Single Sign On (SSO) Overview



Article is closed for comments.