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:
- Authentication and Authorization: OpenID vs OAuth2 vs SAML – May 30, 2016
- Concept of the Week: SAML, OAuth2 and OpenID Connect – Jan 27, 2017