Cloud Identity Patterns and Strategies E-Book

Giuseppe Di Federico

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 391

Veröffentlichungsjahr: 2022

Beschreibung

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.

Leseprobe

Cloud Identity Patterns and Strategies

Design enterprise cloud identity models with OAuth 2.0 and Azure Active Directory

Giuseppe Di Federico

Fabrizio Barcaroli

BIRMINGHAM—MUMBAI

Cloud Identity Patterns and Strategies

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Mohd Riyan Khan

Publishing Product Manager: Mohd Riyan Khan

Senior Editor: Romy Dias

Technical Editor: Rajat Sharma

Copy Editor: Safis Editing

Language Support Editor: Safis Editing

Project Coordinator: Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Manju Arasan

Production Designer: Nilesh Mohite

Senior Marketing Coordinator: Marylou De Mello

Marketing Coordinator: Ankita Bhonsle

First published: December 2022

Production reference: 1021222

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80181-084-5

www.packt.com

To Valerio, who was born as I was writing the first chapter. He keeps pushing me to discover the real meaning of love on a daily basis.

– Giuseppe Di Federico

To my family and my future wife.

– Fabrizio Barcaroli

Contributors

About the authors

Giuseppe Di Federico started working for Microsoft in 2011, with previous experience working for IBM and Accenture in software development. He became an architect for cloud and hybrid solutions, serving customers in more than 10 countries across EMEA. He had the opportunity to lead multicultural teams, visit many multinational customers, and learn about different cultures, mindsets, and assets, which enabled him to also appreciate how organizations’ structures impact their results. During his experience, he has been able to appreciate many identity patterns designed to last, to be reliable and secure. In June 2022, he accepted the challenge to join a new leading-edge team for the greatest service company in Italy.

I want to thank my wonderful family, Valerio and Luisa, for giving me the space and support I’ve needed to write this book during a tough period, with a child born, a transfer, a house renovation, and a job change. A special thanks to my parents as well, for providing me with all the tools I need in life.

Fabrizio Barcaroli (born in 1987) started his career as a consultant in Italy after obtaining a master’s degree in computer science in 2012. In 2013, Fabrizio joined Microsoft as part of the Microsoft Consulting Services unit, where he developed his technical skills and helped customers achieve their business goals through the usage of Microsoft technologies. With the rise of the cloud era, Fabrizio specialized in cloud and identity solutions, and in 2020, he became a cloud solution architect, a technical advisor that helps close the gap between business needs and Microsoft technologies for big enterprises operating in the manufacturing, finance, and retail markets in Italy and across the globe.

I want to thank my whole family for always supporting me throughout my entire life: my father, Annibale, who has always been a role model for me; my mother, Rosa, whose unconditional love has always protected us; my sisters, Silvia and Federica, who always believed in me; and last, but not least, the love of my life, Giulia, who inspires me and bears with my bad temper every day.

Finally, I would like to thank Microsoft, for giving me the space to write this book, and the Packt team, for patiently guiding me and Giuseppe through this great journey.

About the reviewers

Gennady Shulman is an identity and access management architect specializing in single sign-on and multi-factor designs, implementations, and strategies. He has over 20 years of experience at Pfizer, eBay, and Guardian Life, covering the areas of architecture and pattern building for enterprises and external identities. During his tenure at Pfizer, he was able to identify multiple common vulnerabilities and exposures (CVE) related to implementations of federated services in multiple products, which required well-known vendors to re-architect or fix issues.

Gaurav Khullar obtained his B.E. (Honors) in information technology from Panjab University, India, in 2012. He currently works as a security consulting manager at Accenture UK&I, with a core focus on digital identity. He has been part of several digital transformations and has helped enterprises define and deliver their digital identity roadmaps. Gaurav is an expert in the field of identity and access management (IAM) and has been working in the industry for around 11 years. He started working in the industry as a full stack developer with an IAM vendor company headquartered in California, US. He has received several recognitions for delivering complex digital identity projects.

Table of Contents

Preface

Part 1: Impact of Digital Transformation

1

Walkthrough of Digital Identity in the Enterprise

Digital transformation – the impact on the market

Why an enterprise identity strategy?

The impact of identities on the UX

Digital identities – the duties of an enterprise

The challenges when defining an identity strategy

Single sign-on (SSO)

LDAP and Kerberos

Federation of identities

Federation terminology

Federation example

Cookies and tokens

WS-Federation

WS-Federation Passive Requestor Profile

WS-Federation Active Requestor Profile

Security Assertion Markup Language (SAML)

Summary

2

The Cloud Era and Identity

The cloud era

Identity in the cloud era

The pillars of a cloud company

The challenges of identity

The cloud identity

A hybrid identity

The future of identity

Summary

Part 2: OAuth Implementation and Patterns

3

OAuth 2.0 and OIDC

OAuth and OIDC basic concepts

How OAuth and OIDC work together

How the protocols are implemented in the real world

Technical background

Summary

4

Authentication Flows

The authorization code grant flow

The authorization code grant flow with PKCE

The implicit grant flow

The client credentials grant flow

The ROPC grant flow

The OBO flow

Hybrid flows

Summary

5

Exploring Identity Patterns

Understanding the basic terminology

Web applications

User authentication only pattern

Additional considerations

Native applications

Application authorization pattern

SPAs

Single-page authentication pattern

Additional considerations

Security considerations

Summary

Part 3: Real-World Scenarios

6

Trends in API Authentication

The complexity of defining standard guidance

The vertical API approach

API landscape complexity

The application frontend API flow

The application automation API

The multiple IdP dilemma

Defining enterprise standards for identity

The service mesh and identity management

Authentication implications in a service mesh

Common antipatterns

Summary

7

Identity Providers in the Real World

The technical aspects

The non-technical aspects

Azure Active Directory (AAD)

Azure Active Directory Domain Services (AD DS)

Azure Active Directory B2C (AD B2C)

Active Directory Federation Services (AD FS)

Customer Identity from SAP Customer Data Cloud

Okta (Auth0)

Summary

8

Real-World Identity Provider – A Zoom-In on Azure Active Directory

An overview of AAD

AAD basics

Supported authentication protocols

User provisioning

Authentication types

Registering and configuring applications

App registrations

Enterprise applications

Additional features

Conditional Access

Identity Protection

Privileged Identity Management

External identities

Verifiable credentials

Microsoft Graph

Summary

9

Exploring Real-World Scenarios

The identity features within an enterprise in the real world

The implications of the company’s structure

Frontend authentication challenges in the real world

Backend authentication challenges in the real world

Pattern 1 – multiple IDPs

Pattern 2 – a single IdP

Pattern 3 – domain-based registration

Pattern 4 – application-based registration

Authentication challenges for microservices integration

Summary

Index

Other Books You May Enjoy

Preface

The world around us is changing faster than ever before. Technology is leading this change in a multitude of ways:

Every company is a software companyBig companies are restructuring themselves to be able to deal with such a fast evolutionStart-ups are forging themselves around technology, building organigrams optimized to put technology at the centerArchitectural paradigms are evolving to produce cloud-ready scalable designs

All in all, enterprises that aim for an ambitious and sustainable time to market to stay ahead of the competition cannot deal with technology in the same way they would have done years ago.

This book leverages these concepts to focus on the impact of core technology that is paramount for an enterprise: its identity.

Focusing on how digital transformation is reflected in identities, with a broad view, this book will cover, among others, the following aspects:

Enterprise identities that have a direct impact on employees’ productivityCustomer identities, consumed by the client, and the service an enterprise offers Application identities and the new challenges related to cloud-born applications which are distributed with independent microservices that requires mutual authentications

Besides business understanding, part of the book will be technically oriented and you will be guided in understanding why an identity strategy is important, the importance of protocols such as OAuth, and the different flows needed according to the scenario, as well as recommended identity patterns for distributed applications.

Who this book is for

The recommended audience for this book is enterprise architects and people with technical profiles.

What this book covers

Chapter 1, Walkthrough of Digital Identity in the Enterprise, covers basic concepts to support you in understanding the main challenges around digital identity.

Chapter 2, The Cloud Era and Identity, explains how the cloud and the modern architectural pattern add further challenges around the topic of identity

Chapter 3, OAuth 2.0 and OIDC, describes the most widely used identity protocol in cloud applications.

Chapter 4, Authentication Flows, provides an overview of different ways to adopt OAuth according to the context.

Chapter 5, Exploring Identity Patterns, looks at some basic patterns to be used with OAuth and also maps typical identity requirements with the related impact on application design.

Chapter 6, Trends in API Authentication, covers identity design from a high-level point of view: how an API portfolio of a company may look and how identity patterns can be implemented. It describes how new trends such as service meshes map with identity strategies.

Chapter 7, Identity Providers in the Real World, provides an overview of the various choices we have for IdPs by mentioning the most common ones in enterprise and high-level specifications.

Chapter 8, Real-World Identity Provider – A Zoom-In on Azure Active Directory, provides a zoom-in on the capabilities of a specific identity provider (Azure Active Directory). This will help you to understand the typical customizations and features available and how to leverage them to facilitate an identity strategy.

Chapter 9, Exploring Real-World Scenarios, focuses on the experience we have collected in the real world. The chapter covers the 360-degree impact of identity within an organization. It will also help you to understand how enterprise structure can affect strategic choices and how important it is to have the technical team connected with the business team for a long-term winning strategy within a company.

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/U2PwD.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “The client application (a public client specifically, since a confidential client must specify the client_secret parameter too) requests an access token from the /token endpoint by sending the authorization code.”

A block of code is set as follows:

GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=openid%20resource_server_id

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

POST /token HTTP/1.1 Host: authzserver.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Cloud Identity Patterns and Strategies, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781801810845

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Impact of Digital Transformation

This part will give an overview from the identity origin until the challenges that need to be tackled in a cloud design solution and why OAuth is needed in the cloud era.

This section contains the following chapters:

Chapter 1, Walkthrough of Digital Identity in the EnterpriseChapter 2, The Cloud Era and Identity

1

Walkthrough of Digital Identity in the Enterprise

Business and the technology to support it are moving at a faster pace than ever before.

Digital transformation has disrupted the technology we used to deal with until recently. It is still occurring, and the evolution is not finished. The reason why this is happening can be summarized as follows: new technologies, trends, and tools supplied by the major cloud providers are helping companies to focus on business value rather than the surrounding complexity of an in-house data center.

Cloud and digital transformation cannot be seen anymore as the next step of information technology (IT) transformation; it is the present, and it is occurring right now. Many companies have already embraced this evolution and have transformed their data centers into cloud assets, and we need to expect most of the remaining companies’ assets to leave on-premises data centers soon.

In other words, most companies are in the process of reinventing themselves. They are revisiting how they produce software assets, they are caring more about time to market, and they are understanding how much this can be directly proportional to the success of the company.

In this chapter, we are going to cover the following topics:

Impacts of digital transformation on the marketWhy it is important to think about an identity strategy, what items an enterprise should not underestimate, and what the challenges areThe importance of the UX and how it maps to the digital identityCommon technical protocols for identity in the enterprise

Digital transformation – the impact on the market

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 trafficEncourage the users to access the service as much as possibleGet money:From advertising, if the business model of the application is ad-basedIncrease the transformation rate in e-commerce applicationsAny 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.

Why an enterprise identity strategy?

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.

The impact of identities on the UX

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 itAvoids 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 serviceAllows the user to spend their time using the service rather than on ancillary activities such as registering or completing their profile informationPrevents 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 passwordA 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.

Digital identities – the duties of an enterprise

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 credentialsMore 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 applicationUser information is not centralized, which might result in users wasting time enriching their profiling information for each applicationIdentity 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.

The challenges when defining an identity strategy

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 developmentThe 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 architectsThe 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.

Single sign-on (SSO)

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 serverThe 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.

LDAP and Kerberos

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.