What is Federated Identity Management?

  • By Johann Nallathamby
  • 18 Jun, 2018

Introduction

Federated identity management is an arrangement that can be made between two or more trust domains, to allow users of these trust domains to access applications and services using the same digital identity. An identity such as this is known as federated identity and the use of such a solution pattern is known as identity federation.

Federated identity management is built upon the basis of trust between two or more domains. For example, a trust domain can be a partner organization, a business unit, a subsidiary, etc.

In any digital organization today, identity and access management (IAM) is a specialized function that is delegated to a service provider known as the identity broker. An identity broker is a service provider that specializes in brokering access control between multiple service providers (also referred to as relying parties). Federated identity management is an arrangement that is made between two or more such identity brokers across organizations.

An identity broker could be known by more specific names depending on the role it plays in federated identity management. These names are not quite standardized across the industry, although used in common parlance and you may find people using these names interchangeably. Therefore it is important to specify these names with the relevant context whenever they are used and depending on the arrangement, an identity broker may play more than one role.

These roles include:

  1. Identity Provider
  2. Resident Identity Provider
  3. Federated Identity Provider
  4. Federation Provider
  5. Resident Authorization Server

An identity provider is an identity broker that is responsible for asserting digital identities with claims for service providers to consume.

A resident identity provider is defined with respect to a digital identity, and is the identity provider responsible for asserting the digital identities within its trust domain. Sometimes this is also referred to as local identity provider or incumbent identity provider.

A federated identity provider is defined with respect to a trust domain, and is responsible to assert digital identities that belong to another particular trust domain. A trust relationship is established between the two identity providers.

The term federation provider is often used to denote an identity broker that specializes in mediating IAM operations between multiple service providers and multiple identity providers, based on trust relationships.

A resident authorization server is defined with respect to a service provider, and is where the logical representation of the application or service provider resides. It is responsible for authenticating and authorizing the application or service provider for the requested access.

Identity federation provides the following benefits:

  1. Users are required to remember only one set of credentials which provides a seamless user experience.
  2. Single sign-on is supported in most implementations.
  3. Avoids administrative overhead by delegating account and password management responsibilities to the resident identity provider, instead of having multiple identity silos to be managed.
  4. Simplifies data management and storage costs.
  5. Avoids privacy and compliance burdens.

Following are some examples of federated identity management use cases:

  1. Provide access to users from supplier, distributor, and partner networks.
  2. Provide access to new users outside the traditional organization perimeter after mergers and acquisitions.
  3. Provide access to users from commercial identity providers like banks, for example, Third Party Payment Providers (TPPs) in PSD2.
  4. Provide access to citizens using national identity provider, for example, DigiD, Emirates ID, etc.
  5. Provide access to users who own a public organization ID, for example, ORCID ID.
  6. Social Login (sign-up/sign-in/connect), for example, Facebook, Google, LinkedIn, etc.
  7. As a temporary arrangement for supporting transitioning between IAM systems.

Inbound and Outbound Identity Federation

Identity Federation is broadly categorized into two areas:

  1. Inbound Identity Federation
  2. Outbound Identity Federation

In an identity federation flow, an identity broker which receives an assertion from another identity broker is known as inbound identity federation. In other words, inbound identity federation allows you to provide access to your applications and services to identities that are outside your organization’s traditional boundary/trust domain.

Similarly, an identity provider which produces an assertion to be consumed by another identity broker is known as outbound identity federation. Outbound identity federation allows identities that you manage to access applications and services that are outside your traditional organization boundary/trust domain.

Figure 1: Identity Federation between the Enterprise and SaaS Application

Figure 1 illustrates an identity federation arrangement between an enterprise and a SaaS application. The SaaS application is hosted in Azure cloud and its authentication is delegated to a federation provider. The enterprise is a tenant in the SaaS application and the federation provider. The enterprise identity provider (ADFS) is configured as a federated identity provider in the respective tenant of the federation provider in Azure cloud. Thus, a trust is established between the cloud tenant’s federation provider and the enterprise identity provider. Therefore the users in the enterprise identity provider will be able to login to the respective tenant of the SaaS application using their identities in the enterprise identity provider.

The flow described is with respect to authentication. However, in order for users to gain complete access they need to pass authorization as well. Authorization may or may not be part of this federation arrangement.

Identity Federation vs. Single Sign-On

Most federated identity management solutions are implemented in a way in which users are not required to prove their identity more than once per logged-in session. Single sign-on is not synonymous with identity federation. However, it is a by-product of the way identity federation is implemented.

On the other hand, not all single sign-on implementations can be categorized as identity federation. For example, Integrated Windows Authentication (IWA) based on kerberos network authentication protocol, is an example of a single sign-on implementation across applications and services, but not considered an example of identity federation because it is limited to a particular network.

Bring Your Own Identity

The phrase bring your own identity (BYOID) became popular following the trend of using social identities to gain access to applications and services. Although BYOID is commonly used in the context of social identities, the concept applies to any federated digital identity issued by the government, non-government organizations or enterprises.

Use cases 3, 4, 5, and 6 are all examples of BYOID, and are commonly found in Customer IAM (CIAM). They can be further divided as BYOID for sign-up, sign-in, and to connect. Although technically all these 3 use cases follow the same kind of flow, there are subtle differences in the objectives of these use cases.

The objective of “BYOID for sign-up” is to improve the user experience of the self sign-up process by retrieving a part of or complete profile information that is necessary to create an account for the user in the intermediary identity broker, using an identity managed by a third party.

The objectives of “BYOID for sign-in” is to make the login flow as smooth as possible to the end-user with minimal prompts for additional input as possible. BYOID for sign-in doesn’t necessarily have to have a local account provisioned in the intermediary identity brokers.

The objective of “BYOID to connect” is simply to enrich/fill the local user profile with additional/missing information.

Federated Account Linking

One of the key features of a federation provider is linking digital identifiers of a single identity in multiple federated identity providers to a digital identifier in the resident identity provider. This is known as federated account linking.

Without federated account linking, a federation provider will simply only mediate between a service provider and a federated identity provider. This mode of federation is commonly seen in non-critical applications and services such as public forums, downloading marketing material, etc.

Figure 2: Federated login without account linking

However with federated account linking, in addition to mediating, the federation provider may also provide features such as account management, password management, and entitlements management.

Figure 3: Federated login with account linking

Just-In-Time Account Provisioning

Just-In-Time account provisioning technique is used to setup an account for the user in an intermediary identity broker on the fly. Just-in-Time account provisioning is a key part of just-in-time account linking.

Figure 4: Federated login with just-in-time account provisioning

Just-In-Time Password Provisioning

Just-In-Time Password provisioning is an optional step of just-in-time account provisioning. The need for this type of provisioning generally depends on the combined account and password policies of the organization and the applications the user will be accessing. If you decide to provision a new password for the local account, it is also optional to allow the user to continue signing in using the federated identity.

Home Realm Discovery

Federating with a single identity provider is not sufficient for today’s enterprise needs. Typically there are multiple federated identity providers (realms) that are configured, due to the need of supporting multiple partners or multiple social login options. In such cases choosing the resident identity provider (home realm) for the particular user who is trying to access the application or service becomes a challenge, especially in terms of user experience.

Home Realm Discovery (HRD) is the process of identifying the resident identity provider of a particular user in order to authenticate the user and assert the user's identity with claims. HRD was originally a Microsoft term but the concept applies to all modern identity federations. There are no standards around how HRD should be implemented, each vendor has their own style and as such, it’s hard to support portability.

HRD methods can be automatic or involve manual user interaction. Following are some commonly used methods for HRD:

  1. Present a list of options to the user to choose from.
  2. Identifier first login — Prompt the user to enter his/her identifier and resolve the identity provider based on the identifier. For example, if identifier is johann@gmail.com, we would know that the identity provider for Johann is Google, initiate an authentication request to Google, and ideally the identifier would be pre-filled in the Google login form so that the user does not have to re-enter his identifier.
  3. Selective home realm discovery — Limit the identity providers that are used for a specific service provider. This can be useful in situations where there are multiple federated identity providers that you trust, but have service providers that will only be used and access by users in a specific subset of identity provider.
  4. Use HTTP query parameters added by the service provider.
  5. Use the IP address of the user’s device. For example, intranet users must login using local accounts in AD, whereas Internet users must login from upstream identity provider with multi-factor authentication for additional security.
  6. Use headers added via an intercepting proxy server.
  7. Use cookies to remember the realm the user previously selected on the device. If cookies are not found fallback to manual methods.
  8. The federated identity provider can itself be a federation provider who will in-turn federate with other identity providers. In those kind of situations prompting the user to provide information for HRD at each intermediary federation provider, could be considered poor user experience. Therefore in those situations, it may be required to collect all possible information from the user upfront to be routed to the correct resident identity provider.

Supporting IAM Transitions

Identity federation can also be used as a transition strategy for IAM. It can facilitate transitioning from multiple decentralized source user directories to a single centralized target user directory. In this case passwords will be provisioned. Once all the accounts are eventually migrated, you may decide to disconnect these federated identity providers governing the distributed directories from the ecosystem.

Summary

This article focuses on federated identity management and its usage. There are many identity federation protocols such as SAML2 Web SSO, OpenID Connect, WS-Trust, WS-Federation, etc. Although we haven’t looked at any of the specific protocols used to implement federated identity management, the concepts what we discussed remain intact for any protocol that you may choose to implement with.

WSO2 Identity Server is an open source IAM product distributed under the Apache 2.0 license. It possesses a powerful identity management and identity federation framework, which gives it the ability to play any role of an identity broker, as described in this article, in a federated identity management arrangement.

About Author

  • Johann Nallathamby
  • Associate Director/Solutions Architect
  • WSO2