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)
1
Part 1: Impact of Digital Transformation
4
Part 2: OAuth Implementation and Patterns
8
Part 3: Real-World Scenarios

The multiple IdP dilemma

Having to deal with multiple IdPs is not as uncommon as one may think. Dealing with multiple IdPs can be the result of intended but also unintended design.

As mentioned previously in this chapter, the most notable side-effect of API proliferation is that different teams work in different ways, using different techniques and technologies, and sometimes this means using different IdPs. This is an example of unintended or unwanted IdPs, where a company needs to deal with multiple IdPs not because of a design choice but because of a lack of initial governance. There may be circumstances where multiple IdPs are the result of a design decision. It’s important to understand that collaboration extends beyond the enterprise.

Multiple IdPs are usually involved when an application’s scope spans multiple companies collaborating to achieve the application’s business logic, which needs to harness features provided by external APIs or applications...