Authentication vs. Federation vs. SSO

Subway of Life 8/52 / Dennis Skley

Authentication. Federation. Single Sign On (SSO). I’ve mentioned these concepts many times. I haven’t actually formally defined what each of these terms mean even though I’ve used these many times throughout my writing — these concepts are closely related.

Authentication: process of an entity (the Principal) proving its identity to another entity (the System).

Single Sign On (SSO): characteristic of an authentication mechanism that relates to the user’s identity being used to provide access across multiple Service Providers.

Federation: common standards and protocols to manage and map user identities between Identity Providers across organizations (and security domains) via trust relationships (usually established via digital signatures, encryption, and PKI).

First, Identity and Access Management (IAM) is the management of identity concerns within an information technology organization. The term, IAM, can refer to the team or the responsibilities of the team. Ideally, IAM is a centralized team, but due to history, politics, or organizational structure that isn’t always possible. The next best option is to have a central team dedicated to each of Business-to-Business (B2B), Business-to-Consumer (B2C), and Business-to-Employee (B2E) concerns. All too often, every individual group handles their own IAM responsibilities — this creates additional hurdles to adopting Federation and SSO across an organization. IAM can include authentication of users and system, authorization of those users and systems, user provisioning, audit of identity systems, user repository management (think LDAP or Active Directory), password policies, and other concerns.

Authentication

  • Userid and password
  • Digital Signature
  • X509v3 client certificate
  • pin # + random number from a FOB, Google Authenticate, or similar technology.

For completeness, a User Repository contains information about Users (Principals), their Credentials, Groups, group membership, and other user attributes. An LDAP Server or Active Directory is a typical example of a User Repository. More detailed descriptions of these concepts can be found here. I previously defined Federation Server and Identity Provider in a previous post.

Single Sign On

  • an LDAP server, Active Directory, database, or similar directory server
  • a system that generates and passes a trusted token around to applications for the purposes of authentication.
  • Sometimes, the term SSO is used to describe signing into applications with a password manager.
  • Before 2005, SSO might have been used to mean a common set of credentials were used across multiple systems (probably with some type of asynchronous password synchronization system), but those credentials had to be provided by the user to log into each separate system — in some contexts, this is probably still the case.
  • Federation as described below.

Single Sign On (SSO) deals with authentication and the technical interoperability of the actors involved to provide the common login credentials across systems.

A Directory Server-based SSO solution for multiple applications looks something like the following diagram.

SSO thru a common directory server

Another SSO example is N Service Providers (SPs) within an organization trusting a single Identity Provider (IdP) looks something like the following (this is actually identity federation, see next section).

N SPs trusting a single IdP

Federation

From the WS-Federation spec (one of numerous SSO protocols that enable federation) we have, “The goal of federation is to allow security principal identities and attributes to be shared across trust boundaries according to established policies.” This is a good description of federation in general; it involves having common standards and protocols to manage and map user identities between Identity Providers across organizations (and security domains) via trust relationships (usually established via digital signatures, encryption, and PKI). Federation is the trust relationship that exists between these organizations; it is concerned with where the user’s credentials are actually stored and how trusted third-parties can authenticate against those credentials without actually seeing them.

The federation relationship can be accomplished through one of several different protocols including (but, not limited to):

  • SAML1.1
  • SAML2
  • WS-Federation
  • OAuth2
  • OpenID Connect
  • WS-Trust
  • Various proprietary protocols

Federation can take many forms. Within an organization (departments, business units), the patterns could look like:

  • N Service Providers (SPs) within an organization trusting a single Identity Provider (IdP) — see diagram in the last section.
  • N SPs across multiple organizations trusting a single third-party IdP
N SPs across multiple organizations trusting a single third-party IdP
  • N IdPs within an organization trusted by one SP.
N IdPs within an organization trusted by one SP
  • N IdPs within an organization trusting a single IdP
N IdPs within an organization trusting a single IdP
  • N SPs (let’s call them API Providers) across multiple organizations trusting a single IdP, which is then trusted by a common system (such as an API Gateway)
N SPs across multiple organizations trusting a single IdP, which in turn trusted by a common system (API Gateway)
  • Identity Broker (IdP managing relationships between) with N SPs and N IdPs spanning multiple organizations with interrelated federation relationships.
Identity Broker pattern with N SPs and N IdPs

In 2017 and beyond, all end user authentication should involve Single Sign On with a well-known Identity Provider product in the enterprise space. The same is mostly true in other contexts as well. Likewise, in the enterprise space, SSO with actors outside of the local organization should involve federation relationships. The use of federation relationships between systems within different organizations should be used as it makes sense.

Image: Subway of Life 8/52 / Dennis Skley

My focus within Information Technology is API Management, Integration, and Identity–especially where these three intersect.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store