Federation of identities

IT departments had always been characterized by an inclination toward centralization. This is easy to understand: having a centralized IT system makes it simpler to manage, secure, audit, and maintain, but on the other hand, it lacks flexibility and extensibility, and it is certainly hard, if not impossible sometimes, to share and use it outside the company’s boundaries.

Businesses usually don’t care about how difficult it could be to maintain and manage an IT system; they mainly care about its features and how they can harness them for their profit. Businesses need software to be flexible and extensible, an enabler and a catalyst for new opportunities to make people more productive and, in the end, transform a process into profit.

Let’s narrow down this very broad problem to the scope of identity management in the global internet era. Businesses demanded more collaboration with their partners in order not to be overtaken by their competitors. People outside an organization had to have access to the internal applications and assets of another company, they had to share critical information more collaboratively, and the internet was the natural candidate to start this new way of working. IT departments knew that, but they didn’t have the right tools to securely enable this new way of thinking and working without increasing the complexity of existing identity management systems based on traditional authentication protocols such as Kerberos and LDAP.

The tendency for centralization was causing too much friction in business-to-business collaboration, integration, and automation, resulting in high costs of identity management and reduced efficiency. Identity management needed a new model that could solve all these problems, and the answer was the concept of federation. Federation is based on trust. A company trusts that the identities that are managed by another company are reliable because we trust that we and the other company value the relationship that we have. After all, it creates a benefit, most likely profit, for both us and them. Generally speaking, trust is usually based on shared experience: you usually trust other organizations or people because you have a historical and established relationship with them or because other organizations or entities (that you trust) recognize that they are trustworthy.

The federated identity model innovates by delivering flexibility into business-to-business collaboration scenarios and by reducing the overall identity management costs.

Within this model, each company manages its own set of identities. Usually, this means managing the life cycles of both personal data and accounts, including the associated credentials of the company’s employees and, sometimes, a subset of their external collaborators. The latter scenario is common when the external company we collaborate with does not have an identity system, making federation practically impossible. Therefore, it is more convenient to create and manage an identity representing those external users directly in our identity system. Managing users outside of their organization will likely introduce security and liability risks. With the introduction of protocols such as SAML, WS-Federation, OAuth 2.0, and OpenID Connect (OIDC), this problem has been solved with a very elegant solution that will be discussed later in this chapter.

Through federation, companies can pursue business integration goals that best align with their business model. IT departments, on the other hand, do not have to create, manage, and centralize external identities within their authentication solutions. This allows them to avoid all those scenarios that may put them at risk of reputation damage or regulatory liability if any identity management action releases or uses information in ways that conflict with individual privacy rights.

A federated identity model has different goals/traits:

• Reduce the cost of identity management because external identity management is delegated to a trusted external company
• Do not bind or impose the use of a specific implementation on the companies that would like to start collaborating
• Leverage open standards to enable secure and reliable collaboration for businesses and individuals

From a technical perspective, a federated identity model comprises several components that build the foundation to enable identity interactions with companies beyond their IT boundaries. It’s important to know that federation technologies highly rely on web technologies such as the HTTP protocol (especially the Redirect directive).

It is worth mentioning that federation across enterprises is a topic that’s historically associated with the SAML protocol. More information on SAML will be provided later.

Federation terminology

Let’s dive into the definition of some important terms and components around federation that are common to most authentication protocols:

• Federation: In identity management, as stated earlier, federation is a trust relationship between two companies that would like to start a beneficial collaboration and access the services and the assets published by the other party with their credentials. Therefore, it is a trust contract that two or more companies have established that typically includes authentication and may also include authorization.
• IdP: An IdP is an entity that provides authentication (and sometimes authorization) to end users. It usually stores information about users’ accounts and credentials, but it is sometimes used to proxy authentication to external user stores by means of other authentication protocols, which might be different from the ones used by the applications directly federated with the IdP. An example of an IdP is Active Directory Federation Services (ADFS), which allows federation to other IdPs through the use of federated protocols such as SAML and WS-Federation. ADFS keeps account credentials in an Active Directory Domain Services infrastructure, making the interoperability between modern and legacy protocols (Kerberos and LDAP) possible.
• Security Token Service (STS): An STS is a web service that issues security tokens, and it is usually part of an IdP. An STS makes assertions about users and delivers them to trusting parties by means of a security token.
• Claim: A claim is the technical name for the user assertions made by the STS (for example, name, surname, username, and so on).
• Security token: A security token is a collection of claims. Claims in a token are organized in a shared format that depends on the authentication protocol used, such as SAML tokens for the SAML and WS-Federation protocols and JWT tokens for the OAuth 2.0 and OIDC protocols.
• Signed security token: A signed security token is a security token that is cryptographically signed by the STS.
• Service provider (relying party): A service provider is an entity, such as an application, that trusts and relies on the assertions (tokens) issued by a specific IdP.
• Federation metadata: The federation metadata is a publicly available document that defines the technical details to establish trust with the IdP that publishes it.
• Home realm discovery (HRD): This is the process that identifies a user’s IdP.

Federation example

Let’s try to apply the concepts explained in the previous section to an example.

Scenario: There are two companies, Contoso and Fabrikam.

Contoso has its own IdP, ContosoIdP, and one web application (the service provider) where important marketing documents are published.

This marketing portal has already been federated with ContosoIdP. This means that user authentication has been delegated to ContosoIdP; in other words, the marketing portal trusts ContosoIdP and accepts signed security tokens containing users’ assertions issued by ContosoIdP.

Fabrikam has just its own IdP, FabrikamIdP, which authenticates Fabrikam users.

Goal: Contoso and Fabrikam started a business collaboration, and Contoso would like to grant Fabrikam’s users access to their marketing portal.

Solution: Contoso and Fabrikam establish a federation between their IdPs. This federation has a direction, meaning that ContosoIdP will trust tokens issued by FabrikamIdP but not vice versa.

The way federation occurs in practice depends on which protocol is being used. Most commercial identity and service provider implementations provide automation tools and user interfaces where it is possible to load the federation metadata document (used within the SAML and WS-Federation protocols) of the resource we would like to federate with in the form of an HTTP Unified Resource Locator (URL). Each IdP and application publishes such a document by exposing a publicly available internet endpoint that can be fetched through the HTTP protocol. This document is automatically parsed to extract the information needed to establish the federation, such as public certificates, claim definitions, unique identifiers, and other endpoints.

The following figure shows a typical user authentication flow involving two IdPs:

Figure 1.6 – User authentication flow with two IdPs

Once the federation between Contoso and Fabrikam is in place, then a Fabrikam user can initiate an authentication flow to access Contoso’s marketing portal. The flow is described as follows:

1. A Fabrikam user accesses the URL of the marketing portal from their browser.
2. The marketing portal checks whether the user is authenticated; if not, it redirects (HTTP 302) them to ContosoIdP.
3. ContosoIdP asks for a user’s proof of authentication, which typically translates into asking for the user’s username first. ContosoIdP checks whether it can authenticate the user associated with the typed username (that is, whether the user belongs to the Contoso realm) or whether it needs to delegate authentication to FabrikamIdP. This process is called HRD.
4. ContosoIdP understands that the user is from Fabrikam and it redirects them to FabrikamIdP.
5. The user inserts their credentials into the FabrikamIdP login page, which validates them and authenticates the user.
6. Upon successful authentication, FabrikamIdP issues a signed security token and redirects the user back to ContosoIdP.
7. ContosoIdP validates the signed security token signature and reads the claims within it.
8. ContosoIdP issues a new signed security token and redirects the user back to the marketing portal (the service provider).
9. The user browser sends the signed security token to the marketing portal, which validates its signature and reads the claims within it.
10. If the user is authorized, access is granted to the marketing portal.

This example provides several important insights into how a federation and its components work and interact with each other. It is worth noting the following:

• The marketing portal (the service provider) is not aware of the existence of FabrikamIdP, it just trusts tokens issued by ContosoIdP.
• ContosoIdP will always issue a token signed with the certificate/key published in its metadata. It does not relay the token received by FabrikamIdP because service providers federated with ContosoIdP won’t trust the signature of this token.

Cookies and tokens

Some of you may be wondering why we haven’t mentioned the concept of cookies in this discussion. Cookies and tokens are different entities and must not be confused with each other, even though they are very often found together. A cookie (also known as an internet cookie, web cookie, or browser cookie) is a web application artifact used by web browsers to store information about a user’s session. It is typically created by web servers when users visit their hosted websites. In other words, a cookie is a way of creating a stateful interaction between the user and a website. A token, on the other hand, is a block of structured data (for example, issuer ID, claims, audience, and so on) strictly related to an authentication protocol, which can usually be embedded within a cookie by the applications themselves.

In the following sections, we will have a closer look at real-world federation implementations – the WS-Federation and SAML protocols.