Single Sign-On vs. Federation

Nairuz Abulhul
R3d Buck3T
Published in
3 min readMay 18, 2020

A simple explanation of the difference between Single Sign-On and Federated Authentication

Many organizations nowadays have plenty of applications that require authentications daily. Forcing users to authenticate to all these applications traditionally with credentials opens a massive risk of getting credentials compromised during Social Engineering attacks or breaches.

Single Sign-On authentication, either internally or externally [federation], minimizes the cumbersomeness of dealing with password security and reduces the risk of losing sensitive identity data.

Single Sing-On is a way of authenticating users through their identities internally across the organization and allowing them to access resources [applications] tied to their identities.

Before we delve into the authentication process, we need to understand a few terms:

Identity: is a group of attributes and information defines a user in an organization. These attributes include name, role, access policies.etc

Identity Service Provider: is the system that verifies user identities before granting them access to an applications.

Service Provide: is the application that provides the service to users. Applications can be on-prem or on cloud.

Let’s say we have a user named Steve who has permissions to access SP 1[Splunk] and SP 2 [Tenable] internally. These permissions are considered his attributes stored in Steve’s identity on the organization’s Identity Provider [IDP].

When Steve wants to access Splunk or Tenable application, he will authenticate to the organization Identity Provider first before accessing the applications. If the IDP recognizes the user, it will send back an assertion token that allows Steve to access Splunk and Tenable.

The IDP mainly checks for two main things :

1- If the user Steve exists in the organization Identity Provider Data Base.

2- What permissions/attributes Steve has to grant him the right type of access to the internal applications

In the above example, Steve authenticated to the IDP and granted him access to only Splunk and Tenable and not Workday as his identity does not have the attribute that allows him to access it.

Federated authentication is a broad Single Sign-On for accessing applications and service providers among different organizations like third party applications i.e., Salesforce, Cloud applications, etc.

Federated authentication does not involve the passing of sensitive information or credentials during the authentication process. It relies mainly on user identities authenticated by the federated Identity Provider that passes these identities to the service providers that dictate the required access for these users. The service provider does not need authentication from the user directly; it trusts the IDP to provide that confirmation of identity.

A user first authenticates to a federated identity provider that is part of the federation application and checks if the user’s identity exists, if it does, it passes the identity attributes to the service provider and authorizes the user to have access to its service.

That’s basically a quick overview of the difference between Single Sign-On and Federated Authentication.

Resources:

--

--

Nairuz Abulhul
R3d Buck3T

I spend 70% of the time reading security stuff and 30% trying to make it work !!! aka Pentester [+] Publication: R3d Buck3T