The implication of digital transformation on identity impacted both the enterprise and the consumer market.

But let’s take a step back and start with an overview of the two markets, how they differ, and their relationships with digital identities.

On one hand, we have the consumer market. The term consumer market, in this context, refers to the market that targets internet users. In other words, every time we consume a cloud service from a PC or a mobile (for example, Microsoft OneDrive or Google Drive) or we hit a website, we are in the consumer market. The consumer market includes social networks (for example, Facebook), search engines (for example, Google or Bing), e-commerce web applications (for example, Amazon, Zalando, or eBay), and, in general, everything consumable by a general internet user. In the consumer market, the service targets us, we represent the final user, and, most importantly, we represent the source of revenue. This revenue may come from our money, our data, (which can include both personal information and/or tracking and collecting our behavior on the web), or anything else that can be profitable.

From a very high-level standpoint, the typical objectives that service has on the consumer market are as follows:

• Increase traffic
• Encourage the users to access the service as much as possible
• Get money:
  • From advertising, if the business model of the application is ad-based
  • Increase the transformation rate in e-commerce applications
  • Any other profitable revenue that comes from the product service model

On the other hand, we have the enterprise market, a market where, historically, giants such as Microsoft, VMware, HP, Cisco, Oracle, and IBM competed to sell products to install and consume on top of servers in the customer’s data center. These tech giants targeted the enterprise market by offering products to the IT department of a company. The IT department of an enterprise company, in turn, needed to create services on top of these products to be consumed by the end business. The result is that these tech giants have always been far from the end business; they have always been focused on boosting the internal IT departments of enterprises. This was the enterprise market that we knew until a few years ago.

The advent of the cloud in enterprises took this paradigm a step further. Today, some of these tech giants, such as Microsoft, Oracle, and IBM, have become enterprise cloud providers. They sell Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS) cloud services to serve their enterprise customers that don’t need a private data center anymore. Enterprise customers take advantage of cloud services by fueling external business and at the same time boosting internal employees’ productivity. This has an important implication: offloading the IT complexity and data center management outside the enterprise by delegating it to the cloud providers and letting themselves focus more on their core business rather than on IT tasks and data center management.

Thanks to the enterprise cloud, which provides the capabilities of the past with less complexity and, most importantly, the new capabilities of the next generation, the next wave of the enterprise market is being created. Companies are constantly looking for new ways to improve their business with technology. The cloud market is young, and the efforts by the IT giants to onboard new customers (enterprises) at this stage to guarantee long-term revenue in the upcoming years are a top priority for them.

The portfolio of services that cloud providers provide to enterprises is huge. As anticipated, services span from simple servers (virtual machines) to web servers, to container hosting, storage, backup as a service, and much more. Identity providers are another important service offered to enterprises, and this is the core topic of this book.

In the context of digital identities, if we try to compare the consumer market with the enterprise, we will notice something. In the enterprise market, unlike the consumer market, there is a high level of complexity. The reason for that is that companies are supposed to manage their identity services for their employee. Identity, on the other hand, is consumed in the consumer market and managed by identity providers, such as Facebook or Google, just to provide two examples.

This concept has several implications. To properly use identity services, we need an enterprise-grade identity strategy that can simplify the complexity of this wide and critical topic.

The enterprise market and the consumer market are different, but there is one common factor: simplifying the user experience.

On the one hand, we have the consumer market, where the main KPI is to prevent the users who access the service from leaving too soon. The goal is to maximize the time spent on the service and, consequently, the service adoption.

On the other hand, we have the enterprise market, where companies want to maximize their business and improve employee productivity. In both cases, the adoption of a service and the onboarding of new users are important KPIs.

The user experience (UX) is paramount to achieving these KPIs.

When it’s time to develop a service, regardless of the target market, one core item is mandatory: a user-centric approach. We may have heard this phrase many times, so let’s contextualize it to see what it means.

A user-centric approach aims to produce a UX that is tailored to the user’s needs to make interaction easier and improve productivity. When we talk about a user-centric approach, we also mean a service or a set of services that are built around the user. In the Single sign-on section, we are going to talk about the single sign-on (SSO) experience. Having SSO in place has the important benefit of preventing users from logging in with different sets of credentials to the different services: they just need to prove who they are once and everything else, including the ability to switch to a different service, is done transparently from a user perspective.

The concept of the user-centric approach can go even beyond this. The services know the user, and they can even enrich the user details and information together in a distributed way. This reduces the amount of time the user spends; for example, the user may be asked to provide their email address, phone number, and other information that can be instead provided by the Identity Provider (IdP) out of the box. There are two great advantages of a user-centric approach; one is technical and the other is more business oriented:

• Technically speaking, the application can offload some of the logic to the IdP, which results in easier development and maintenance of applications
• In the business area, the users can enjoy a custom experience that can increase user engagement

The following diagram is a graphical representation of services built upon the IdP. These services can be developed by offloading the identity’s business logic to the IdP:

Figure 1.1 – IdP and service relationship

Of course, to implement services that cooperate to facilitate the UX, an enterprise-grade user management system design needs to be done upfront.

To have an idea of a fully user-centric approach, think about consumer services such as the cloud services from Google or Microsoft. Once you are signed in with your @gmail or @outlook email ID, you don’t need to create a new user to manage calendars, maps, emails, or photos; you are the very same entity across all these services, and these services are going to share the details of your interactions to tailor the perfect UX for you across the cloud service. If you ask Google Assistant to remind you about something when you are back home, very likely you don’t need to specify where your home is, so long as this information has been provided to a different service, such as Google Maps. This gives us an idea of the benefits that can be achieved from a user perspective and how productivity can be boosted with this approach.

To summarize, having a user-centric approach means that services are tailored around users to enable them to get the most efficiency and productivity.

Recently, UX has become more and more important as the market understands that it is directly proportional to user satisfaction with the service. As a consequence, a lot of changes in blueprints and best practices have occurred.

The demonstration of this progress is visible every day. It’s pretty hard nowadays to visit a website where we are forced to register as a new user with very long registration forms and many fields that may discourage the end user from finalizing the action and make them leave the service before they even start to use it. This practice was common in the web of the past generation:

Figure 1.2 – Example of a long registration form, which is not so common nowadays

On the web, it is incredibly common to hit a service where part of the user management or the entire sign-up process is outsourced to external IdPs:

Figure 1.3 – Example of an external IdP signup

Outsourcing the onboarding process to an external IdP has been a game changer; it now takes a user a few seconds rather than minutes to register themselves for a specific web service, something that was challenging before OAuth.

The benefits of sign-up/sign-in outsourcing are multiple:

• Decreases the probability of a user leaving the service before they even start to use it
• Avoids asking for too many details from the user during registration for a service, which may raise privacy concerns and increase the probability of the user leaving the service
• Allows the user to spend their time using the service rather than on ancillary activities such as registering or completing their profile information
• Prevents bugs in the registration experience that prevent the user from accessing the service

There is another important achievement that OAuth brought to the world: a new security level for service-to-service communication. We will discuss the technical details in Chapter 4, Authentication Flows, but let’s take a quick look at it in advance with an example. Suppose you are an architect and you need to create a new service for the consumer market. This service is supposed to enable user-to-user communication through web calls, such as Zoom, Microsoft Teams, or Google Hangouts. Let’s call this service Contoso Video. One of the features of Contoso Video is integration with Google Calendar. This integration should enable users to check the calendar so that if User A wants to send an invitation to User B for a call, the Contoso Video service can check on the calendar whether User B is available at that time.

How can Contoso Video check the Google Calendar of a specified user (in our scenario, User B) without having the username and password of the Google account?

Before December 4, 2007, when the first version of OAuth was released, this wasn’t possible. The service that needed to check the Google Calendar of a specified user needed to have the username and password to log in on behalf of the user to Google Calendar.

This is not good from a security perspective for the following reasons, among others:

• Contoso Video is an external service that needs to store the user’s credentials; it can be hacked or could even be owned by malicious people that are gathering the usernames and passwords of users.
• Contoso Video has the username and password of the target account, which results in unlimited control over what the service can potentially do on the account (for example, it can read the calendar and emails, write emails, or even delete the account). The least security privilege cannot be granted.

OAuth has solved this problem in various ways:

• A user can delegate a service (in our case, Contoso Video) to call another service (in our example, Google Calendar) on their behalf, without directly requiring a username and password
• A user can delegate a service to perform only a subset of actions; in our example, User B can delegate Contoso Video to read the calendar only and not perform any further action:

Figure 1.4 – Contoso Video user flow example

For those who are already familiar with OAuth, you should already be aware of how Contoso Video can get calendar details without knowing the password of User B and how this magic works. Further details on how this flow works can be found in Chapter 4, Authentication Flows, where this magic will be explained with technical details.

Before moving to the next step, it’s important to understand, as will be outlined in the rest of this book, that the OAuth 2.0 protocol is generic and does not differ in enterprise and consumer markets from a technical perspective. The general concepts, flows, and protocol behavior are the same because they are based on the very same Request for Comment (RFC6749). What changes is the adopted IdP, which is the owner of the identities, and is, most importantly, one of the core topics of this book: how IdPs implement the OAuth specs and what the advantages and pitfalls of this are.

In enterprises, the concept is quite different as companies will manage digital identities and need to handle the IdP.

The upcoming chapters will describe the considerations the owner of IdP (enterprises) needs to take care of.

As anticipated in the Digital transformation – the impact on the market section, before the cloud era, tech giants dealt with technology within their own data centers. Identity management is not new for enterprises; historically, IdPs such as Active Directory or SiteMinder worked inside the network perimeter of enterprises with protocols such as Kerberos and NTLM.

Having an identity directory in the enterprise is paramount to managing users, computers, and enterprise assets in general that belong to the organization and configuring access to the company’s assets. The evolution of identity in the consumer and in the enterprise led to most IdPs supporting OAuth, and they typically work as SaaS outside the network perimeter of the enterprise (that is, they are exposed to the internet, not the intranet). This has several benefits because users can now log in to the enterprise’s services even outside the intranet and the VPN, improving the company’s productivity. This also brings security implications into play, which will be covered in detail in Chapter 5, Exploring Identity Patterns.

What companies tend to underestimate is that cloud IdPs nowadays take advantage of the OAuth protocol, which is very different from the previous protocols as it takes into account new concepts such as delegation across different services, app registration within the enterprise, and new authentication flows, which, in turn, can impact the way enterprises develop services and APIs.

In an enterprise, user information, identity, and access are managed by the company, which deals with the life cycle of the digital identities of its employees (at a minimum, some companies even host external identities as vendors and/or contractors in their IdP). Companies typically have processes to onboard the employee’s digital identity when hired (provisioning). The identity is then used to enable the user to access the company’s tools, services, and websites and, finally, when the user leaves the company, there is a process to delete/disable (deprovision) the user’s digital identity to prevent unwanted access to company resources.

From our experience in enterprises, we can certainly state that the concept of the user-centric approach is not yet widely adopted. IT departments and project teams are not able to collaborate efficiently with each other while working on projects/apps because they are not organized properly. Sometimes, different teams inside the organization use different IdPs, which makes the user-centric approach complicated. As a result, it often results in a very bad practice of managing user identity consistently. This outlines the importance of an organization having a clear strategy in this domain. As we are going to see in the rest of this book, it’s important to develop a strategy not only to ease the life of the users but also to handle everything that requires authentication, including service-to-service authentication.

If a bad strategy or no strategy is in place, then some applications are even developed without any IdP. When no IdP is used in an application, then the user management feature is usually developed within the application itself with further effort, using independent and custom-developed logic, which is a model that was followed in the past (before 2000) when IdPs didn’t exist at all. When this happens, users need to use a different set of credentials according to the application they need to log in to. This scenario is also known as the distributed identity problem and was common in the early 2000s. The following diagram shows the distributed identity problem:

Figure 1.5 – Distributed identity problem example

The consequence of such a model is having less productivity for the following reasons:

• Users need to remember different sets of credentials
• More lines of code have to be written for an application to handle the authentication logic, typically offloaded to an IdP, which results in increased maintenance and more time to market to develop a single application
• User information is not centralized, which might result in users wasting time enriching their profiling information for each application
• Identity needs to be managed by custom implementations, which may lead to security issues

These are the typical scenarios and the duties an enterprise needs to accomplish to manage its digital identities. If we look deeper, there are important implications for an architect to consider, as we will discuss in the upcoming section.

Every software architect, during the design phase of an application, should carefully take care of the concept of digital identity first.

Authentication and authorization are usually the very first tasks an application needs to perform before triggering any other business logic. This is common to every application that requires authentication within an enterprise.

When architects are working on demand to develop an application without taking care of the surrounding ecosystem, many items could be neglected.

For example, an application under development may have a subset of requirements that can be easily addressed by taking advantage of API logic that’s already present within the company’s portfolio. This simplifies the development complexity of the current application and represents a good practice to increase the company’s efficiency overall. This kind of scenario has many salient points, as follows:

• Companies need to have a well-known portfolio of APIs with good descriptions that can be evaluated before starting any application development
• The API to be taken advantage of needs to already be registered on an IdP with a well-known authentication process that can be consulted by the architects
• The API should be designed to take advantage of the OAuth scope’s capabilities to enhance security within the company (scope is an OAuth spec that will be explored further in Chapter 3, OAuth 2.0 and OIDC)
• The API may be designed to accept requests from two possible actors:
  • The application that calls it.
  • The user who is currently logged in to our application. As such, our application needs to call the API on behalf of the user (the concept of delegation will be explained in Chapter 4, Authentication Flows).

You don’t have to understand what these points mean in depth at this stage. Each of them will be covered in this book; what is important is to have a high-level understanding of the implications that an application design has on a wider ecosystem.

Another example is that an IdP may already have the user information the application needs to acquire. This may have an impact on the user interface and the business logic that needs to be developed.

Another important point to consider is the audience that is supposed to adopt the application under development. An enterprise application can be developed for the customers of the company, for the internal employees, for third-party companies, for a partner, or a combination of them all. This can affect the choice of IdP for the application before the development and for every scenario. It is advisable to identify the options architects can choose from in advance. Not pondering all the IdP options in advance can lead to anarchy or bad architecture, such as having multiple IdPs for the same audiences and purposes. In other words, don’t provide clear IdP options to handle digital identities for specific audiences; it will lead to chaos, which is what many companies are suffering from today.

It is also important to spend a few words on anonymous web applications as they are usually still part of a company’s application assets.

Anonymous web applications are available to every user without any awareness of who the caller is from an application standpoint. Anonymous web applications were very common in Web 1.0 when the internet was based on static websites with little or no server-side logic. Anonymous web applications, by definition, do not require any user authentication. The scope of an anonymous web application was usually to showcase a product or a service to the end users and, in many cases, was handled with poor or no server-side logic. This is because the page that was served to the client was typically the same for every request.

If you are thinking that anonymous web applications do not need to consider authentication and authorization during the design phase, it’s important to note that this is wrong. Anonymous web applications do not require any user authentication but can still interact with APIs and with the company’s assets and, as such, they may need to have their own identity within the enterprise in the same way as authenticated applications. This concept will become clear in the rest of this book when we describe OAuth flows and application registration in Chapter 5, Exploring Identity Patterns.

In the upcoming sections, we are going to tackle this topic more deeply from a technical perspective. We are going to introduce the most relevant identity protocols and technologies adopted within enterprises to lay the groundwork for the rest of this book and to present OAuth 2.0 in Chapter 3, OAuth 2.0 and OIDC.

When we talk about authentication, it is practically impossible to not talk about SSO. Everybody has found themselves stuck with different definitions of SSO, but how can we define it and understand in detail exactly what this term means and implies? SSO is an authentication capability that allows a user to not insert their credentials every time they need to access an application. SSO should not be confused with saving your credentials within a web browser when prompted to do so when logging in to a web application through a web form. SSO is more subtle and involves the interaction of different actors that contribute to preventing the user from being asked for their credentials when moving from one application to another.

To make SSO work, a user should provide an application with proof of authentication, which certifies that the user has already been through an authentication flow. The application, on the other hand, should trust this proof of authentication, which should contain enough information to make the application decide whether user authentication can be skipped entirely.

How is it possible to achieve this? This is where the federated authentication protocols lend a hand; they will be discussed in greater detail in the following chapters.

For now, it is important to understand that to implement SSO, the following components should usually be involved:

• A common authentication server: For different applications to trust the same user’s proof of authentication, a common authentication server must be put in place. Applications must not manage user credentials directly, but they have to delegate authentication to an external server.
• A common language and message format: Messages between applications and the format of the proof of authentication should be standardized to make integration and interoperation among applications easy to implement. This is usually the job that’s done by authentication protocols, which will be discussed later in this chapter.

Very often, there is a common authentication server (also known as an IdP), which takes more than one authentication protocol and can create a proof of authentication that’s suitable for every trusting application, regardless of the language (protocol) required by each of them.

Let’s examine an example. We are going to mention several protocols that will be discussed in detail in the following chapters. For now, the only important thing to know is that each protocol has a way of formatting exchanged messages and proof of authentication.

There is a user who needs to access two applications that trust a common authentication server. This authentication server can either store and manage the user’s credentials directly or delegate credential validation to an external system. In this example, let’s assume that the user’s credentials are directly managed by the authentication server. The user tries to access the first application, but since they don’t already have proof of authentication, they are forced to go to the authentication server first to obtain it. Once it is obtained, they can return to the first application with their proof of authentication and get authorized to access it. Now, let’s suppose that the user would like to access the second application. The user cannot generally use the proof they already have for the second application and therefore they need to go to the authentication server again to obtain proof of authentication that is valid for it too. This time, the authentication server does not require the user to insert their credentials again because they have already done so, and therefore it just issues new proof of authentication for the second application. This happens because the authentication server, during the user’s first successful authentication attempt, established a session with the user, meaning that it saved a state representing the interactions that the user had with it. The user can therefore access the second application without re-entering their credentials: they SSOed into it. A couple of things are worth noting here:

• Each application could potentially use a different authentication protocol with the authentication server
• The authentication server is how SSO happens; it is in charge of recognizing a user’s identity by looking at the session information the user established with it during the authentication process

SSO has greatly simplified the UX during the interaction with different applications by reducing the user prompts for credentials. This behavior has several implications, though, some beneficial and others detrimental. On the positive side, the less a user is asked for their credentials, the less they are susceptible to phishing attacks (which require the user to insert their credentials on a malicious login page). The user may wonder why they need to insert their username and password again and why SSO is not working as expected. On the negative side, having one set of credentials means that if they are compromised (or if the proof of authentication is stolen), then an attacker may get access to multiple applications since they all rely on the same set of credentials or trust the stolen proof of authentication. Using MFA and advanced security capabilities prevents most attacks related to SSO scenarios.

When most applications used to have user databases/repositories, an effort was made by several companies to create standard ways to centralize user information and details in common places. For the users, this would have meant not needing to remember passwords to access each application anymore.

In the 1980s, telecommunication companies introduced the concept of directory services into IT. A directory service was a central place where all the entities that made up a network were represented and given a name. Directory services were introduced as an Open System Interconnection (OSI) initiative to find common network standards to enable interoperability among different software vendors. This made a standard necessary, and this is one of the reasons why the x.500 directory service came into the world and subsequently the Lightweight Directory Access Protocol (LDAP) as the means to authenticate a user and allow them to access the objects within a directory. The term lightweight in LDAP was introduced to highlight how it differed from the former DAP protocol: LDAP was based on the TCP/IP protocol stack, which highly simplified the access to x.500 directories.

LDAP was great at centralizing information and making it available to end users and applications. However, it wasn’t that great at making collaboration between different directories easy. Having a single directory with all the network users and objects is not easy to achieve, even within the same company. Different business units and areas might have different needs in terms of security and segregation, and they very often do not want to risk that a user without the proper authorization may access restricted and sensitive assets. Luckily, the Massachusetts Institute of Technology (MIT) developed and published the Kerberos v5 protocol in 1993 to protect network services through authentication and authorization of users and applications (versions 1 to 3 were internal to MIT, and version 4 was published in the 1980s).

As an authentication protocol, Kerberos introduced several new innovative concepts:

• SSO: The Kerberos Foundation is about ticket exchange. Successful authentication for either a user or a computer (which is a separate entity) will issue proof of this authentication by an authentication server in the form of a ticket. The authentication server component that oversees the issuing of tickets is known as the ticket-granting server (TGS). An authenticated entity can therefore use this ticket to prove they are who they claim to be and, consequently, request authorization from other entities who trust the same Kerberos authentication server. This process involves other tickets being issued by the TGS – generally, one for each service an entity requests access to. Once, for instance, a user has been authenticated and receives their ticket from the TGS, they can then access different services without being required to insert their credentials each time. They can use their ticket to SSO into other services, so long as the ticket has not expired (in that case, the user must re-enter their credentials).
• Realms and cross-realm authentication: Kerberos also introduced the important concept of realms. A realm is a domain where a Kerberos authentication server is allowed and has the authority to authenticate a user, a service, or a computer. When it comes to a complex organization with different business areas and independent administration requirements, then it is very likely that more than one realm should be put in place. What is the difference from LDAP, then? Kerberos introduced the concept of cross-realm authentication, where a TGS in a realm trusts tickets issued by the TGS in another realm by creating a sort of trust relationship between Kerberos realms. This quite simple concept enabled new use cases that were impossible to achieve before, such as the highly sought-after collaboration between different business unit realms within the same company.

It is worth mentioning that, at the beginning of the new millennium, Microsoft introduced both LDAP and Kerberos as standard authentication protocols in one of its iconic products, Active Directory. Active Directory has been, and it is still today, the foundation of authentication and authorization for most enterprises. But nowadays, its success is also the main IT professionals’ pain in the neck when it comes to shifting that paradigm (which was great in the early 2000s) to a more modern authentication approach.

Everybody remembers that the end of the 1990s was also famous for the advent of a revolution in the IT world. We are talking about the rise of the global internet, known as Web 1.0 – that is, commercial use of the internet on a global scale. This important transition brought with it a higher demand for collaboration between companies where businesses had to interact with other businesses more and more, expanding their horizons on a global scale to avoid being cut off from the great innovation that could overwhelm them in the blink of an eye.

In that era, Kerberos and LDAP could not enable this new type of collaboration; their capabilities were not suitable for making users, services, and computers interact when such services were managed by different legal entities.

The reason why Kerberos wasn’t ideal to be used over the public internet wasn’t related to the security of the protocol but rather to its authentication model, which didn’t easily fit the needs of most public internet applications due to its complexity. Try to imagine the distribution of the keys required by the protocol to all the machines used by end users to access a website. LDAP, on the other hand, would need to import the users of our company into all the LDAP directories of those external organizations that publish a website that we would like to get access to. The larger the number of organizations involved, the greater the complexity of making collaboration work.

It was time for a different way to manage authentication; it was time to introduce the concept of federation.

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.

Everybody remembers Simple Object Access Protocol (SOAP). SOAP was one of the very first protocols whose goal was to standardize communication messages for web services among computers in a network. SOAP uses eXtensible Markup Language (XML) as its message format and leverages protocols such as HTTP for its communication layer because of its great utilization among the most common operating systems, such as Windows, Linux, and macOS.

WS-Federation is part of the WS-Security framework (published by OASIS), which is an extension of SOAP created to standardize the security of web services in terms of the confidentiality and integrity of their messages. WS-Federation’s purpose is to unify the way different realms (which could be different companies or different units within the same company) manage identities and authentication by creating a common way of exchanging user information among their web services.

We know federation is based on trust, but how can we establish trust between two web services? WS-Federation introduced the concept of federation metadata to solve this problem. The federation metadata is an XML file published by a web service to share all the information needed to establish a trust relationship with the realm that the web service belongs to. The web service could be either an IdP or a service provider, and the information in the metadata differs according to which role the web service has:

• In an IdP, the typical information within the federation metadata file includes claims definitions, the IdP identifiers and endpoints, and the public keys of the certificates used to sign and encrypt the responses and the tokens issued by the IdP’s STS (defined in the WS-Trust specification, also part of the WS-Security framework)
• In a service provider, the typical information includes the service provider identifiers and endpoints and the public keys of the certificates used to sign and encrypt the requests to the IdP’s STS

Once a federation has been established and the parties have exchanged the information, users belonging to the realm where the IdP is located can start using web services provided by the realm where the service provider is.

There are two ways (or profiles, as defined within the protocol specification) to implement an authentication flow: the WS-Federation Passive Requestor Profile and the WS-Federation Active Requestor Profile, which will be briefly described next.

WS-Federation Passive Requestor Profile

A web browser, the Passive Requestor Profile, tries to access the web service resource that requires the requestor to be authenticated. If the requestor hasn’t already obtained proof of authentication, then it is redirected to its identity provider’s STS where, after successful authentication, it will obtain a security token. This security token will be redirected to the web service resource, which will decide whether to authorize access based on the information included in the token.

This flow is a typical service-provider-initiated flow, where the passive requestor tries to access the service provider directly. A slightly different flow, called the identity-provider-initiated flow, starts with a web browser (the passive requestor) accessing the IdP first but specifies in the request the web service resource (the service provider) it would like to be redirected to after successful authentication.

WS-Federation Active Requestor Profile

WS-Federation added the Active Requestor Profile to support all those clients that behave as active requestors. An active requestor (which could be a native application running on Windows or Linux), unlike a web browser (a passive requestor), which passively follows the redirections provided by the web service resources it would like to access, collects the information needed for the authentication first (typically, the username and the password of a user) and then it sends them directly to the identity provider’s STS to obtain a security token that can later be used to get access to the web service resource (the service provider) if the user is authorized. The IdP usually exposes a dedicated HTTP endpoint to enable this flow.

In the next section, we will focus on another important authentication protocol: SAML.

The OASIS Security Services Technical Committee (SSTC), in 2001, had the very ambitious goal of defining an XML framework that could be used for exchanging authentication and authorization information. WS-Federation only partially achieved this as SAML also adopted the XML format for the request and response messages, unofficially signing the death warrant for the declining SOAP specification.

The SAML protocol came out of the joint efforts of several companies that were part of this committee as a passive and claim-based authentication protocol for federated identities.

The SAML specification defines three roles:

• The principal (typically, this is a user, also known as the subject)
• The IdP
• The service provider

In a typical SAML use case, the principal requests a service from the service provider. The service provider usually redirects a user accessing it from a web browser to the IdP to obtain an authentication assertion (a signed security token). Based on the assertions included in the token, the service provider can decide whether to authorize the security principal that completed the authentication flow or simply block the access because the requested permissions cannot be requested.

Before issuing the signed security token to the service provider, the IdP may require the user to prove their identity, usually by asking for a username and a password.

Here is an example of an extract from a signed SAML response token:

<?xml version="1.0" encoding="utf-16"?>
[..]
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://sts.katsuton.com/adfs/services/trust</Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
[..]
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[..]
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
[..]
    <ds:SignatureValue>OUPJpFsnUODCK2h7T5SYMVhlWDnCBT6Qy T9CcVnrjcWUPZTAaz2FNGEpPPhb/P9kW23cw5D1+fjhtAQurN/Du9uYfdkGtXcTPfcOOVfuzgQT1d75HmYnbAtTvhsOrS8gvGCY6o Jk3wsqNar3hrqLHDFxsszY41lZvOe2/Qax1SMpHeglQSbu6WOFe3sPdSiLY8rnWBE5QubS85N1E+HNvjHqXS7Luwr RDNK0InMM+LdPZw1YdOGUikgTbyIFKMR/eXR5UqbVrvmwv58XxT9C5p7FYPu3eKjWLD2aGjCnJufFNfHiVGYrB8OU1FN1E/2sLNXnSuMyNnQJ5iWCQWP3vQ==</ds:SignatureValue>
[..]
        </ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">fabarca@katsuton.com</NameID>
</Subject>
[..]
        <Conditions NotBefore="2021-06-28T09:26:39.720Z" NotOnOrAfter="2021-06-28T09:27:39.720Z">
            <AudienceRestriction>        
    <Audience>urn:microsoft:adfs:claimsxray</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute 
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
      <AttributeValue>kadmin</AttributeValue>
            </Attribute>
            </AttributeStatement>
[..]
</samlp:Response>

Let’s discuss the main pieces of information within the token:

• Issuer: This is the identifier of the IdP that issued the token.
• Status code: The status code of the whole authentication process. If anything other than success is returned, then the receiving party (typically, the service provider) has to raise an error.
• Signature method: The signature algorithm that’s used to sign the token.
• Signature: The signature of the token. The signature can be calculated for the entire response or just for the assertions within the token: it must be agreed upon upfront between the parties involved.
• Validity: The time window when the token is considered valid. Once the token has expired, the user must return to the IdP and ask for another token.
• NameId: The SAML token’s part that uniquely identifies the user. It can contain the user’s username in different formats (for example, userprincipalname format), which are usually specified in the Format attribute.
• Audience: The party the token has been issued for. An application (service provider) must control whether the token it receives has been issued for itself and not for another application by checking the Audience field.
• Attributes (claims): A list of assertions regarding the authenticated user needed by the service provider to authorize access and implement its business logic.

Most of the information provided here can be found in different types of tokens, such as JWTs in the OAuth 2.0 and OIDC protocols. To avoid confusion, please note that SAML is both the name of the token format and the protocol. WS-Federation uses SAML tokens within its authentication flows.

SAML does not specify which method of authentication must be used by the IdP. This is a key point: SAML was created to rely on existing authentication protocols. It naturally integrates with them as its source of authentication. Kerberos, LDAP, and Active Directory can still be used as SAML sources of authentication while leaving the SAML protocol with the task of federating with the identities of external companies.

This chapter covered both technical and non-technical topics. In the first few sections of this chapter, we were provided with an overview of the current market landscape, where identities are used, and the differences between the markets. We also discussed how the evolution of identity protocols has enabled a simplification of the UX and an improvement in user engagement in the services that delegate the authentication logic to external IdPs. This chapter also drilled down to showcase the technical landscape of the identities around today, the most common protocols, and a specific emphasis on SSO, which is widely adopted in the enterprise market.

In the next chapter, we will provide a historical overview of cloud identity and its evolution in enterprises, why it is needed, and the difference between cloud and hybrid identities. We will also provide an overview of the future of identity technologies.