Book Image

Cloud Identity Patterns and Strategies

By : Giuseppe Di Federico, Fabrizio Barcaroli
5 (1)
Book Image

Cloud Identity Patterns and Strategies

5 (1)
By: Giuseppe Di Federico, Fabrizio Barcaroli

Overview of this book

Identity is paramount for every architecture design, making it crucial for enterprise and solutions architects to understand the benefits and pitfalls of implementing identity patterns. However, information on cloud identity patterns is generally scattered across different sources and rarely approached from an architect’s perspective, and this is what Cloud Identity Patterns and Strategies aims to solve, empowering solutions architects to take an active part in implementing identity solutions. Throughout this book, you’ll cover various theoretical topics along with practical examples that follow the implementation of a standard de facto identity provider (IdP) in an enterprise, such as Azure Active Directory. As you progress through the chapters, you’ll explore the different factors that contribute to an enterprise's current status quo around identities and harness modern authentication approaches to meet specific requirements of an enterprise. You’ll also be able to make sense of how modern application designs are impacted by the company’s choices and move on to recognize how a healthy organization tackles identity and critical tasks that the development teams pivot on. By the end of this book, you’ll be able to breeze through creating portable, robust, and reliable applications that can interact with each other.
Table of Contents (15 chapters)
Part 1: Impact of Digital Transformation
Part 2: OAuth Implementation and Patterns
Part 3: Real-World Scenarios


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.