All you need to know about Single Sign-On and Federated Identity

Most times people confuse single sign-on with federated identity. Both are based on the same principle of accessing multiple digital services with the same identity but they are not the same. The authentication method may be similar, but the underlying principles differ. This post will help you to understand the similarities, as well as the key differences between single sign-on and federated identity.

The Basics of Digital Identity

All digital services rely on an identity and access management (IAM) system to identify the user, verify the claimed identity of the user and thereafter, grant the required access. There are 3 key components of an IAM – Identification, Authentication and Authorisation. These 3 crucial components are exemplified in the IAM flow diagram below.

1. A user requests access to an online service (e.g. web application). A user could be a person or device who wants to access a protected resource.
2. In the background, the online service communicates with the service provider.
3. The service provider asks the IAM system to check if the user is permitted to access the service. The IAM system identifies the user. This is done by comparing the identifier provided by the user (such as an email address) with other identifiers, to see if there’s a match. This is called Identification.
4. If there is a match (i.e the user does exist in the system), the IAM system asks the user to prove that indeed, it owns the identity. This is called authentication.
5. Upon successful authentication, the IAM system checks what the authenticated user is allowed to do.
6. Thereafter, the user is permitted access based on her access rights. This is called authorisation.

How the IAM is managed as we would see later on is where the difference lies between Single Sign-On and Federated Identity.

Single Sign-On

Single Sign-On(SSO) is an authentication mechanism whereby a single identity/authentication allows access to multiple services. A user only needs to sign in to the first service. Thereafter, the user can access other services without re-entering her credentials. SSO is not to be confused with Same Sign-On where a user has to authenticate to each service separately with the same credentials.

SSO is usually within a single organisation. An organisation can support SSO for example between two separate applications (A and B). For SSO to work between applications A and B, the organisation would have to configure application B to use authentication attributes from A and vice versa. This means that when the same user identity who’s already authenticated to A wants to access B, application B can rely on the existing authenticated session of A to allow the user access to B without asking her to re-authenticate. But If there’s no existing authenticated session and/or the authentication session is no longer valid, then the user would be re-authenticated.

With SSO systems, access is granted to multiple services based on an authentication token. This token is created as a result of the authentication to the first service (application A in our example) and passed seamlessly to application B when access is requested. Application B relies on the information contained in the token to grant the user access. If the information contained in the token doesn’t satisfy application B’s requirements ( e.g. the token has expired), application B requests the user to enter her credentials.

The organisation defines the SSO configuration such as device and network restrictions, validity period and authentication requirements.

SSO reduces the use of weak and/or insecure credentials. This is because a user only has to remember one set of credentials to access multiple services. It lowers the administrative cost and is more convenient for the user.

However, SSO is a single point of failure. A compromise of a single access credential provides malicious actors access to numerous services.

Same Sign-On

SSO is often confused with Same Sign-On. Same Sign-On requires separate authentication per service with the same credential. SSO requires the user to authenticate only once to access multiple services.

On SSO systems, access is granted to multiple services based on a token passed seamlessly to other services. With Same Sign-On, the exact credential (e.g. username and password)has to be provided to each of the services to gain access.

Although both SSO and Same Sign-On depend on the same identity and credentials, SSO is more convenient and limits the exposure of authentication credentials.

Federated Identity

While SSO allows access to multiple services within a single organisation, a federated identity and access management (FIAM) system provide access to multiple services across different organisations.

In FIAM, the service party (relying party) relies on an external party (usually referred to as an identity provider) for its IAM. The identity provider (IdP) identifies and authenticates the user and thereafter, provides an assertion to the service provider. The service users do not provide credentials directly to the service and/or service provider, instead, the user is redirected to the IdP. The IdP identifies and authenticates the user based on the service provider’s security requirements. Afterwards, the IdP provides an assertion to the service provider indicating the authenticated user’s identity. The assertion indicates to the service provider the user identity and authentication status.

As depicted on the FIAM flow diagram below, the IdP manages the digital identities. The service provider just has to trust and rely on the IdP to allow its users access to requested resources. For this to happen, there must be a trust relationship between the IdP and the service provider (relying party). Authentication protocols such as Security Assertion Markup Language (SAML) and OpenID Connect could be used to establish this trust between the two parties. This trust relationship is the bedrock of FIAM.

The main advantage of FIAM is that the service provider won’t have to manage user credentials. And for the user, only one identity/credential is required to access multiple services across many organisations without having to undergo an identity proofing process for each service. The user only needs to keep and maintain one identity.

The disadvantage is that if that one user’s identity is stolen, multiple services could be compromised. In addition, the IdP is a single point of failure and once compromised, all the relaying parties are vulnerable.

Conclusion

It’s very important to remain the following:

1. SSO allows access to multiple services with a single identity within a single organisation. It improves convenience and reduces administrative overhead. However, it’s a single point of failure and lucrative for malicious actors.
2. FIAM takes administrative overhead away from the service provider and enables access to multiple services across many organisations using a single identity.
3. However, FIAM doesn’t solve the problem with SSO. A compromise of the IdP may cripple all the relying parties. IdP is even more lucrative for malicious actors as a compromise could provide access to many more services when compared to SSO.