Single Sign-On (SSO)

So many passwords, so little time … Many applications have their own approach to user authentication with the obvious disadvantage of another password for users to remember (and re-enter).  In most enterprise environments, this approach also greatly complicates user provisioning / de-provisioning processes by creating additional points of administration.

Single Sign-On (SSO) solves this problem and offers many advantages:

  • Reduced administrative costs – fewer passwords to manage = fewer requests to reset forgotten passwords.  And, when users are removed from the centralized-system (often, LDAP), they can no longer access the supported applications.
  • Time savings – users take 5–20 seconds to log in to an online app (longer with typos).  Saving these seconds reduces frustration and increases productivity.
  • Increased user adoption – the greater convenience of not having to log in, users are more likely to use various applications.
  • Increased security – allows centralized password policies for work for all of your applications

Before we go further, some terms:

  • Authentication = verifying that someone is who they claim to be.
  • Authorization = which resources a particular user should be able to access and what they should be allowed to do with those resources

Applications generally need to do both.  Single sign-on (SSO) allow users access to authorized network resources with one login.  The are commonly two approaches:

  • Federated authentication which lets you send authentication and authorization data between affiliated but unrelated web services.
  • Delegated authentication which enables an application to use an authentication method of your choice.  This often is done with:
    • Internal corporate LDAP or other authentication stores
    • External often with social apps like Google or Linkein … often using OpenID Connect, which combines OpenID authentication and OAuth2 authorization

There are two distinct roles to play:

  • An identity provider is a trusted provider that lets you use single sign-on (SSO) to access other websites or apps
  • A service provider is a website that hosts apps

The typical flow becomes:

  • A user tries to login to an app or service provider with SSO
  • The service provider sends a valid SAML request to an identity provider
  • The identity provider identifies the user specified in the SAML request
  • The user is prompted to log in to identity provider (if not logged in yet)
  • The identity provider sends a SAML response to the service provider (or app)
  • The app authenticates the SAML response, and, if valid, grants the user access

 

For further reading:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s