Implementing Identity Management on AWS E-Book

Jon Lehtinen

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

Seitenzahl: 457

Veröffentlichungsjahr: 2021

Beschreibung

AWS identity management offers a powerful yet complex array of native capabilities and connections to existing enterprise identity systems for administrative and application identity use cases. This book breaks down the complexities involved by adopting a use-case-driven approach that helps identity and cloud engineers understand how to use the right mix of native AWS capabilities and external IAM components to achieve the business and security outcomes they want.
You will begin by learning about the IAM toolsets and paradigms within AWS. This will allow you to determine how to best leverage them for administrative control, extending workforce identities to the cloud, and using IAM toolsets and paradigms on an app deployed on AWS. Next, the book demonstrates how to extend your on-premise administrative IAM capabilities to the AWS backplane, as well as how to make your workforce identities available for AWS-deployed applications. In the concluding chapters, you’ll learn how to use the native identity services with applications deployed on AWS.
By the end of this IAM Amazon Web Services book, you will be able to build enterprise-class solutions for administrative and application identity using AWS IAM tools and external identity systems.

Leseprobe

Implementing Identity Management on AWS

A real-world guide to solving customer and workforce IAM challenges in your AWS cloud environments

Jon Lehtinen

BIRMINGHAM—MUMBAI

Implementing Identity Management on AWS

Copyright © 2021 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 author, 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: Wilson Dsouza

Publishing Product Manager: Yogesh Deokar

Senior Editor: Athikho Sapuni Rishana

Content Development Editor: Sayali Pingale

Technical Editor: Sarvesh Jaywant

Copy Editor: Safis Editing

Project Coordinator: Neil Dmello

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Alishon Mendonca

First published: August 2021

Production reference: 1120821

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

978-1-80056-228-8

www.packt.com

A big thank you to everyone who encouraged me to take this on, had to deal with me while I was doing it, and kept me going when major life events made me think that I had finally stretched myself too far. To my family, Aleeta, Calvin, Annabelle, and Syd, and to the Hombres, Hutch, Sean, Anthony, and Pat, I am dead serious when I say I could not have done this without you.

– Jon Lehtinen

Foreword

"Is it okay if I share your table?"

I first met Jon Lehtinen in Napa, California as we were both attending our first-ever Cloud Identity Summit. This simple meeting turned out to be one of the few key moments in my life when an act of pure serendipity caused my career to ricochet in a direction I could not have foreseen. An exchange of pleasantries turned into a couple of hours of conversation, an exchange of business cards, and me urging Jon to apply for one of the open positions on our IAM Operations team. Soon after, Jon packed up his family in Arizona and moved out to Virginia to join our team at GE's Information Security Technology Center. 

Jon's guiding star has always been in designing his identity services to better serve the communities of developers and practitioners who consumed them. Early on, my role at GE was SSO service leader in charge of an engineering team tasked with aiding the business in integrating their applications with our IAM services. An important lesson I learned from Jon early on is that it's not enough to say that "the business is our customer." Jon has always known that the real customers were those that were building products around our services, administrators within those businesses, and the end users trying to get their work done. When I moved into a principal architect role, Jon was promoted into my old role and he quickly transformed it into one of servant leadership to support those communities. He established open office hours, built on the foundations of an online forum, and took all of the input from those communication streams to build a self-service portal where developers were expertly guided in the implementation of our IAM services in their applications in minutes and hours instead of days and weeks. Jon was truly the voice of the identity practitioners and their champion on the engineering side of the house.   

Jon also wrote extensive developer and end user documentation on how the services worked, how to request them, and best practices for integrating them in different application scenarios. He continued to maintain that focus on the practitioner after leaving GE and moving on to roles at Thomson Reuters and at Okta, where today he is responsible for maximizing the value of their identity products through the internal utilization of those same services. It comes as no surprise to me that when Jon decided to make his foray into writing a book, he would choose to once again shine his light of expertise into a field that can be difficult to traverse, even for the most experienced users.  

The Amazon Web Services (AWS) team deserves high praise for building such an extensive identity and access management service at the heart of AWS security. It gives developers and administrators the ability to control access by creating users and groups, designing centralized policies based on both RBAC and ABAC models, assigning those policies to specific populations, integrating existing users via federation, setting up additional controls such as multi-factor authentication, and numerous other features. Because AWS recognizes that identity services are the foundation of any security service, it offers the IAM services for free.

These services allow organizations to overcome the many security hurdles to cloud adoption but, even with Amazon's extensive documentation, the sheer number and granular nature of IAM services available can make that adoption difficult to navigate. The same wide array of authentication and authorization controls that make it possible to deploy highly secure environments using AWS can also frustrate administrators and security professionals alike.    

In this book, Jon does what he has always done best: take the mystery out of a complicated service and provide practical guidance on and examples of its utilization. In the pages that follow, Jon provides a complete overview of IAM, shares details of each of the services, demonstrates the benefits of various combinations, and teaches you best practices on how to protect your AWS accounts. He will also guide you through the latest services and coach you through the configuration of important controls such as MFA.

Jon has once again provided me with knowledge and expert guidance on a service I still periodically struggle with. It's always rewarding, and comforting, to be shown the way by a professional who has been there before and has worked out the best avenue to success. I wish you well on your own journey, both through this book and on your successful path to securing your cloud workloads with AWS identity services.

Steve "Hutch" Hutchinson VP for Security Architecture, MUFG Board Member, IDPro

Contributors

About the author

Jon Lehtinen has 16 years of enterprise identity and access management experience and specializes in both the strategy and execution of IAM transformation in global-scale organizations such as Thomson Reuters, General Electric, and Apollo Education Group. In addition to his work in the enterprise space, he has held positions on Ping Identity's Customer Advisory Board and as an advisor to identity verification start-up EvidentID. He currently owns the workforce and customer identity implementations at Okta.

Jon is dedicated to the growth and maturity of IAM as a profession and serves on the Board of Directors for IDPro.org. He is also a member of the Kantara Initiative, ISC2, OpenID Foundation, and Women in Identity. Jon has presented his work at several conferences, including RSA, Identiverse, and KuppingerCole's European Identity and Cloud Conference.

Currently, he owns Okta's workforce and customer IAM implementations as their Director of Okta on Okta.

About the reviewers

Surendra Singh Khatana is a seasoned Identity and Access Management (IAM) professional with more than a decade of experience in building security solutions using public clouds, container technologies, and IAM tools.

He has worked in the past with TCS and Accenture as a security specialist and currently works as a digital identity senior consultant at Nixu, Finland. At Nixu, he helps customers embrace digitalization securely.

Punit Kumar (an open source lover), is a Certified Cloud Solution Architect – Professional (AWS) with 9 years of experience in the IT industry and an understanding of both public and private clouds.

He has spent a major part of his time on AWS in the areas of infrastructure design and architecting, DevOps automation, infrastructure as code, security frameworks, operations and cloud governance, and private cloud to public cloud transformations.

Punit has worked and helped various industry start-ups in their cloud adoption journey, right from inception. He is a qualified AWS Well-Architecture reviewer and cost-optimizer. Punit is an ambivert and likes socializing with his large circle of friends. All his decisions in life are based on deep thinking and analysis and, of course, his friends' support.

The completion of this book is the very first milestone in my journey as a technical reviewer.

I am very grateful to my colleagues and mentors who really helped me through my learning journey, encouraging me to start work.

Also, I would like to acknowledge my gratitude to family members – my parents and my wife, Kajal Behl, for their support and trust, which really encouraged me during this work.

Maurício Harley is doing a master's in computer science with cyber Security at the University of York, UK. He holds a BSc in electrical engineering from Universidade Federal do Ceará, Brazil and a telematics degree from Faculdade Integrada do Ceará, Brazil.

On his blog (itHarley), he writes about security, the cloud, and networks. He also writes about offensive security for PenTest Magazine and Hakin9. He is also the founder of an OWASP chapter.

He has more than 25 years of experience in IT. He holds industry certifications such as (ISC)2 CISSP, CCIE Routing and Switching, CCIE Service Provider, AWS Certified Solutions Architect Associate, and AWS Certified Security Specialty.

He has given talks at Latin American conferences such as RootDay and OWASP LATAM@Home. He works as a senior consultant at Amazon Web Services in France.

His research is split between cloud security, threat intelligence, and malware analysis.

To my wife, Paula, for the never-ending support and belief in all my career endeavors.

To my parents, Bartolomeu and Leuzete, who went out of their way to build a healthy home and to give us all education resources.

To my siblings, Raquel and Robson, for the friendship, partnership, and love.

Table of Contents

Preface

Section 1: IAM and AWS – Critical Concepts, Definitions, and Tools

Chapter 1: An Introduction to IAM and AWS IAM Concepts

Technical requirements

Understanding IAM

IAM applied to real-world use cases

Exploring AWS IAM

IAM for AWS and IAM on AWS

The AWS IAM dashboard

Principals, users, roles, and groups – getting to know the building blocks of AWS IAM

Authentication – proving you are who you say you are

Authorization – what you are allowed to do and why you are allowed to do it

Putting it all together

Signing in with the root user

Summary

Questions

Chapter 2: An Introduction to the AWS CLI

Technical requirements

Exploring the AWS CLI basics

What is the AWS CLI?

Installing the AWS CLI

AWS CLI configuration

Testing out the CLI

Profiles

Using the AWS CLI

Discovering command syntax

Putting it all together – creating a functional IAM user with the AWS CLI

Attaching an administrator policy

Creating and attaching a password

Creating and attaching the programmatic credentials

Using the new profile

Scripting

Summary

Questions

Further reading

Chapter 3: IAM User Management

Technical requirements

What is an IAM user account?

Principals

Managing and securing root IAM user accounts

Differences between root user account and IAM user accounts

Managing and securing IAM user accounts

IAM user lifecycle management

Password management

Access key management

MFA credential management

Managing federated user accounts

AWS Single Sign-On and federated users

Summary

Questions

Chapter 4: Access Management, Policies, and Permissions

Technical requirements

What is access management?

Introducing the AWS access policy types

The anatomy of an AWS JSON policy document

Defining JSON policy document elements

Exploring the AWS policy types

Identity-based policies

Resource-based policies

IAM permissions boundaries

Service control policies

Access control lists

Session policies

Policy evaluation

Governance

Access Analyzer

AWS CloudTrail

Summary

Questions

Further reading

Chapter 5: Introducing Amazon Cognito

Technical requirements

What is Amazon Cognito?

Amazon Cognito user pools

Amazon Cognito identity pools

Amazon Cognito use cases

User authentication for application access

User authentication and authorization for access to application resources

User authentication and access to AWS services exposed through an application

Federated user authentication and access to AWS services exposed through an application

Creating an Amazon Cognito user pool

Populating users in a user pool

Bulk importing with CSV files

Creating a user pool using the AWS CLI

Exploring the hosted UI

Creating an Amazon Cognito identity pool

Creating an identity pool with the CLI

Summary

Questions

Chapter 6: Introduction to AWS Organizations and AWS Single Sign-On

Technical requirements

What is AWS SSO?

Requirements to use AWS SSO

AWS Organizations

Configuring AWS Organizations using the Management Console

AWS organizations in the AWS CLI

Configuring AWS SSO in the Management Console

AWS SSO settings

Creating and managing users

Connecting AWS accounts to AWS SSO

Configuring AWS SSO from the CLI

Summary

Questions

Further reading

Chapter 7: Other AWS Identity Services

Technical requirements

Understanding AWS Directory Service

AWS Managed Microsoft AD

Active Directory Connector

Simple Active Directory

Amazon Cognito

Encryption and secrets management

AWS Key Management Service

AWS Secrets Manager

Logging and auditing

AWS CloudTrail

Amazon CloudWatch

Summary

Questions

Further reading

Section 2: Implementing IAM on AWS for Administrative Use Cases

Chapter 8: An Ounce of Prevention – Planning Your Administrative Model

Technical requirements

Evaluating the organization's current IAM capabilities

Evaluating the business structure and account schema

Designing the AWS organizational structure

Mapping business functions to OUs

Designing and applying organizational service control policies

Summary

Questions

Further reading

Chapter 9: Bringing Your Admins into the AWS Administrative Backplane

Technical requirements

Defining our organization's identity source

Connecting our IDP to AWS SSO

Provisioning administrative accounts in AWS – account linking

Limitations of manual provisioning and account linking

Provisioning administrative accounts in AWS – SCIM provisioning

How SCIM works

Enabling automatic provisioning in AWS SSO

SCIM in action

Summary

Questions

Further reading

Code samples

Chapter 10: Administrative Single Sign-On to the AWS Backplane

Technical requirements

Why use federation for AWS administrators?

Federated sign-in using an external IDP

Assigning access to AWS accounts

Signing in to the administrative console

Implementing fine-grained access management for administrators

Permission sets and managed authorization policies

Permission sets and custom authorization policies for fine-grained access control

Putting it all together for administrative authorization

Administrative SSO using the AWS CLI

Summary

Questions

Further reading

Section 3: Implementing IAM on AWS for Application Use Cases

Chapter 11: Bringing Your Users into AWS

Technical requirements

Distinguishing administrative users from non-administrative users

Solutions to non-administrative user use cases for apps on AWS

Using Managed AD and trusts

Creating a Managed Microsoft AD instance

Preparing the on-premises AD for a trust – conditional forwarders

Creating the trusts between on-premises and AWS Managed AD

Preparing the Managed AD for a trust – conditional forwarders

Creating the trust between AWS Managed AD and on-premises AD

Summary

Questions

Further reading

Chapter 12: AWS-Hosted Application Single Sign-On Using an Existing Identity Provider

Technical requirements

Defining the use case and solution architecture

Creating a user pool

Connecting Amazon Cognito to an external IdP – SAML

Restricting application access to just the external IdP

Populating the Amazon Cognito user pool through JIT provisioning

Connecting Amazon Cognito to an external IdP – OIDC

Restricting application access to just the external IdP

Populating the Amazon Cognito user pool through JIT provisioning

Assuming roles with identity pools

Summary

Questions

Further reading

Why subscribe?

Other Books You May Enjoy

Preface

Amazon Web Services (AWS) is the largest cloud platform in the world. It was also the first modern cloud services provider and the first to achieve broad enterprise penetration. Whereas being the successful first mover in a market has its advantages, it can also limit a service’s flexibility. Compared to its biggest peers, which logically extend enterprise identity architectures (in part because they came to market years later), AWS’ IAM capabilities can appear slightly alien. Like an archaeologist examining a dig site, we can see artifacts that suggest the service had a history of differing access mechanisms and strategies over the years. Given the success of the service, perhaps it was deemed too great a risk to the growing user base to make sweeping, foundational changes to align more with the familiar IAM patterns found in other organizations.

As AWS predates many enterprise identity best practices and reference architectures, bridging the paradigms of modern enterprise IAM and AWS’ custom approach to IAM is often a difficult leap. Fortunately, with the advent of services such as AWS Organizations, AWS SSO, and Amazon Cognito, the service has never been more approachable. In this book, we will begin by examining the core services and components of identity on AWS in a manner designed to take the rough edges off its more eccentric components. Once we have built up our foundational knowledge, we will then apply what we have learned by solving familiar enterprise use cases.

Who this book is for

Identity on AWS may be well-trodden ground, but that doesn’t make it any more inviting for the uninitiated. AWS’ own documentation, while comprehensive, can be abstruse to those who are not approaching the platform or their own use case from a developer’s perspective. The experience of many enterprise IAM practitioners is being thrown into the deep end to figure out how to solve a business identity problem on AWS through an implementation. With so many services appearing to offer such similar capabilities for similar use cases, getting up to speed, especially under a deadline, can be daunting.

This book was written to introduce IAM practitioners to identity on AWS with a use case-driven perspective. By using the language, patterns, and perspective of an enterprise identity practitioner, I aim to make this topic much more approachable.

What this book covers

Chapter 1, An Introduction to IAM and AWS IAM Concepts, introduces essential IAM concepts and AWS IAM as a suite of capabilities that provides user management and access control to AWS resources.

Chapter 2, An Introduction to the AWS CLI, introduces the AWS CLI, which is the primary programmatic method to interact with AWS resources.

Chapter 3, IAM User Management, addresses best practices around AWS user account security, life cycle management, governance, and authentication/password policies.

Chapter 4, Access Management, Policies, and Permissions, provides an overview of the authorization framework of AWS.

Chapter 5, Introducing Amazon Cognito, introduces Cognito and explores what it can do as an application identity service.

Chapter 6, Introduction to AWS Organizations and AWS Single Sign-On, explores the tools for applying organizational policies and managing access to multiple AWS accounts.

Chapter 7, Other AWS Identity Services, provides an overview of a few other identity and identity-adjacent services that, while important, did not get their own chapter.

Chapter 8, An Ounce of Prevention – Planning Your Administrative Model, provides guidance on designing an administrative and authorization policy model that addresses an organization’s use cases.

Chapter 9, Bringing Your Admins into the AWS Administrative Backplane, walks through methods for bringing existing administrative accounts into AWS.

Chapter 10, Administrative Single Sign-On to the AWS Backplane, walks through federated authentication into the AWS console for administrative accounts and methods for applying fine-grained access control.

Chapter 11, Bringing Your Users into AWS, examines the distinction between administrative and standard user accounts, explores solution architectures for bringing user accounts into AWS, and demonstrates how to extend an on-premises AD forest into AWS using a trust.

Chapter 12, AWS-Hosted Application Single Sign-On Using an Existing Identity Provider, addresses configuring an application with Cognito user pools against a federated provider and using identity pools to authorize users to interact with AWS services on behalf of the application.

To get the most out of this book

To get the most out of this book, we expect familiarity with some basic IAM concepts and tools. Strictly speaking, there are no significant prerequisites to follow along with most of the exercises as they leverage existing AWS services and tools. As we look at some enterprise use cases in the later chapters, you will benefit from either setting up or using an existing non-production enterprise-grade identity provider and Active Directory domain controller.

Most cloud-based identity providers offer developer accounts and/or basic functionality free of charge that are more than sufficient for the examples in this book. Some chapters include references to guides for configuring a test environment for low or no cost in AWS, such as building a domain controller using Amazon EC2.

It would be impossible to cover every use case or scenario of AWS in a single book. However, we believe those who read it will not only be ready to contribute their identity expertise to most enterprise use cases but will be armed with the foundational knowledge and experience needed to solve increasingly complex ones as well.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Implementing-Identity-Management-on-AWS. In case there's an update to the code, it will be updated on the existing GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: http://www.packtpub.com/sites/default/files/downloads/9781800562288_ColorImages.pdf.

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: “We can use resource tags and the ec2:ResourceTag variable to enforce this.”

A block of code is set as follows:

{

“Version”: “2012-10-17”,

“Statement”:

Any command-line input or output is written as follows:

$ aws iam delete-virtual-mfa-device --serial-number arn:aws:iam::451339973440:mfa/rbis3

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: “Let’s start with the IAM_NonProd AWS account. We tick the box next to that account and hit the Assign users button.”

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, mention the book title in the subject of your message and email us at [email protected].

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, selecting your book, clicking on the Errata Submission Form link, and entering the details.

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 Implementing Identity Management on AWS, 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.

Section 1: IAM and AWS – Critical Concepts, Definitions, and Tools

Identity is the most granular unit of security. To ensure the confidentiality, integrity, and availability of a system, that system's infrastructure, applications, APIs, and endpoints must all be identifiable, authenticated, and authorized in order to perform its functions. The AWS platform operates under a rigid identity-centric model. Bridging that model with your own organization's identity implementation can be daunting. At the end of this section, you will understand the industry-standard and AWS-specific IAM terminology that will be referenced throughout this book. You will also learn about best-practice access management patterns and the tools available to implement said patterns within AWS.

This part of the book comprises the following chapters:

Chapter 1, An Introduction to IAM and AWS IAM ConceptsChapter 2, An Introduction to the AWS CLIChapter 3, IAM User ManagementChapter 4, Access Management, Policies, and PermissionsChapter 5, Introducing Amazon CognitoChapter 6, Introduction to AWS Organizations and AWS Single Sign-OnChapter 7, Other AWS Identity Services

Chapter 1: An Introduction to IAM and AWS IAM Concepts

Identity is the perimeter of security, and every transaction, capability, administrative event, and infrastructure component of cloud providers such as Amazon Web Services (AWS) ultimately depends upon identity services to govern all its capabilities. If that scope wasn't large enough already, tying AWS' native capabilities to an existing enterprise, customer, administrative, or infrastructure identity deployment can seem so complex as to make it difficult for cloud identity administrators to know how or where to start. This book will help you overcome the paralysis caused by the capabilities of the platform by approaching the implementation of AWS IAM (IAM) in a use case driven fashion, informed by real experiences working in large enterprise AWS environments.

By the end of this chapter, you will be familiar with the foundational concepts of IAM and see how they are applied within an organization. You will learn the purpose of the AWS IAM service, its components, and how they all work together to secure access to AWS resources. Finally, you'll use the AWS Management Console to create and manage AWS IAM resources, including IAM users, groups, and policies.

This chapter will cover the following topics:

Understanding IAMExploring AWS IAMPutting it all together

Technical requirements

To get the most out of this chapter, you will need the following:

A web browserAn AWS account

Understanding IAM

Identity is the most granular unit of security. The users, services, and systems that interact with infrastructure, applications, APIs, and endpoints must all be identified, authenticated, and authorized in order to perform their functions. The AWS platform operates under a rigid identity-centric model. Bridging that model with your own organization's identity implementation can be daunting.

Identity practitioners can (and do) argue about the minutiae and nuances of the terminology used within IAM. However, for our purposes, we can afford to use a broad definition of IAM in AWS:

''Identity & Access Management is the discipline of managing the life cycle of digital accounts that correspond to and are under the control of a person and ensuring that only the correct resources are accessed by the correct actor under the correct context.''

For something purported as a simple definition, that sure is a mouthful. However, if we break the statement down into its constituent components and consider a typical use case, it affords us an opportunity to see how many technical disciplines you may already be familiar with that relate to IAM:

''Managing the life cycle of digital accounts that correspond to and are under the control of a person…''

In layman's terms, we have these digital accounts that can be used to access computer systems. These accounts either directly or indirectly map to a person. This means that the account is either a digital representation of that person or the person owns and controls those accounts. That person can demonstrate proof of control of those accounts and is accountable for actions taken with those accounts. And those accounts have a life cycle, meaning under certain conditions they are created, under other conditions they may change, and at some point, they may eventually cease to be.

This is called identity management. Identity management is responsible for the following:

Keeping accounts up to date Keeping downstream consumers of those accounts synchronized with the authoritative sources that define the account Provisioning and deprovisioning accounts entirely from various data stores

In short, it's a collection of processes responsible for managing account life cycle events in accordance with business, legal, or technical controls. These controls trigger life cycle events for accounts, such as account creation, modification, and disablement. What those life cycle events are will vary depending upon the event, type of account, business, and requirements of the system using those identities.

Now, let's look at the rest of the definition:

''…and ensuring that only the correct resources are accessed by the correct actor under the correct context.''

Those accounts, having been created, can be used to execute specific activities. What they can do is determined by rules and policies. In order to do anything, the account must first provide proof that whoever or whatever is using it to perform an activity is actually allowed to do so. That proof comes through a shared secret that validates the authenticity of the actor behind the account. This second part of our IAM definition addresses something called access management. Access management addresses the authentication of the account (proving you are who you say you are) and the authorization of that account (proving that you are allowed to do what you are trying to do with that account) to access resources or to perform certain tasks in accordance with established policies.

IAM applied to real-world use cases

To understand this better, and to provide a flimsy pretext to introduce some additional concepts that are not so easily derived from that definition of IAM, let's imagine what happens when someone joins a new company. To help visualize all the actors, systems, and life cycle events in play, take a look at the diagram in Figure 1.1.

In this example, Bob has applied for a sales role at a large identity services organization called Redbeard Identity, which has a reasonably mature internal IAM program, application portfolio, and cloud platform capabilities. Bob's identity experience actually began long before he got to the point where the hiring manager was prepared to make an offer, because in order to apply for the position, he had to create a profile inside of Redbeard Identity's candidate management system.

Important note

The Redbeard Identity organization will be the organization referenced for several use cases and scenarios throughout this book. Whereas real organizations typically have a fixed enterprise architecture, we will adjust the architecture, capabilities, services, user accounts, and other characteristics of the Redbeard Identity organization from chapter to chapter in whatever ways we need to best demonstrate the material of that chapter. Please don't be confused if our example organization's characteristics are not entirely consistent throughout the book.

This marks the first identity life cycle event in Bob's onboarding journey: user account creation. Bob, as a user of the candidate management system, is providing self-issued, unverified information about himself such as his name, contact information, and details about his work history. As there is neither external proof nor an outside source of control validating the information he enters into this system, his candidate account is considered a low-assurance record. As long as Bob remains merely a candidate for the sales role, that low level of assurance is sufficient for the purpose that the candidate record system account serves:

Figure 1.1 – Example of IAM life cycle events and flows

Bob knows his craft well, is an impressive salesman, and aces his interviews. After the details are agreed upon, the hiring manager sends Bob the offer letter confirming the details of his role, along with instructions for accepting the offer. Bob accepts by signing into the candidate portal and accepting the job offer. Now that Bob is more than just a candidate, the authenticity of the details that Bob provided when populating his candidate account must now be verified. To ensure that he is who he says he is, the HR representative will start a process called identity verification. This process is defined by the US Department of Commerce's National Institute of Standards and Technology as a process ''to ensure the applicant is who they claim to be to a stated level of certitude'' (NIST Special Publication 800-63A, Digital Identity Guidelines, Section 4, NIST).

The HR representative asks Bob to provide some identifying documents to facilitate his onboarding and help corroborate the information that he already entered as part of his candidate profile, such as a copy of his passport, a state-issued identification card, and his tax information. For the sake of argument, let's just say Bob hands the HR representative these documents in person to ensure that Bob himself has been compared against these artifacts. Thus, he sidesteps any concerns about him stealing valid credentials from someone else to use in his efforts to secure employment. The HR representative will finally validate these artifacts against their authoritative sources to ensure their authenticity, proving that Bob really is who he says he is. With the confidence that Bob is Bob and that the information Bob entered into the candidate management system is accurate, the HR system creates Bob's employee record and sets it to become active on Bob's start date.

As we said earlier, this organization has a reasonably mature IAM program. As part of a nightly process, the IAM system checks the HR system for any discrepancies in the data between the records stored there and its own corresponding identity records that it maintains in order to keep them in sync. When a change is made to an existing HR record that has a corresponding identity record, such as in the case of an employee changing departments, the department attribute on that employee's identity record also gets updated with the new department value. This is an example of attribute and metadata synchronization being used to ensure the consistency of identity data across data stores. In this case, the HR system is acting as an authoritative source for the IAM system, meaning that the records, attribute values, and other information from that system will overwrite any changes made directly against the records in downstream systems.

This organization uses business logic that tells the IAM system to create new identity records for new joiners one week from the start date listed on the new joiner's HR record. Once Bob's start date is less than a week away, that logic triggers the IAM system to provision, or create, his identity record. This will be the authoritative account record for all downstream systems, which in turn look to the IAM system as their own respective authoritative source. The IAM system will create Bob's identity record based upon an established pattern of attributes and characteristics, or a schema. It contains certain attribute types and values based upon the kind of account that Bob's identity record is. In Figure 1.1, we see a sample of (an admittedly spartan) schema for Bob's identity record. Let's pretend that we can actually take a look at the identity schema for Bob's record within the IAM system using Table 1.1:

Table 1.1 – Sample schema record for Bob within the IAM system

This shows us the attribute names, their current values, and the authoritative sources for each of the attributes in this schema. You'll notice that for the most part, the HR system provides the bulk of the authoritative data for the attributes, with the exception of ''mail,'' which is currently null (or without a value), and which also uses Azure Active Directory (AD) as its authoritative source.

You aren't constrained to a single authoritative source for your identity schema. In fact, you can have nearly infinite combinations of conditional clauses, secondary sources, and compound sources when defining your schema and the authoritative sources used to populate the schema's attributes. Beyond that complexity, you can also have several distinct schemas depending on the type of identity you are defining. We've only been examining Bob's identity journey as he gets onboarded at Redbeard Identity, and he is an employee as denoted by the emptype attribute. Contractors will likely have distinct schemas, as will bot process automation accounts, service accounts, business-to-business accounts, and customer accounts. But to keep things simple, we will stick with Bob the employee.

Bob works in sales, but it is doubtful that Redbeard Identity is a pure-sales organization given that they have enough technical wherewithal to run their own IAM infrastructure. Even if they were that operationally lean, there are regulations that demand evidence that some workers with certain job responsibilities cannot perform other, complementary responsibilities in order to reduce the risk of malfeasance. The go-to example for this is the protection control between accounts receivable and accounts payable in financial services organizations in order to prevent someone entitled to issue invoices from also approving their payment.

Separation of duties requires more than one person in order to complete a business task. Organizations implement separation of duties by applying technical controls that restrict or enable what a person can do based on business and regulatory requirements. Those rules, restrictions, and permissions are called policies, and a collection of policies that grants somebody the full range of access that they are entitled to depending upon their responsibilities is called a role. Aligning policies to roles, and roles to users through attributes or business logic is one part of access management. Providing evidence that those controls function as designed and comply with business and regulatory requirements is identity governance and audit. Identity governance and audit, access management, roles, and policy, all work to ensure that Bob will only be able to access the systems and resources that are appropriate for him to access, or in other words, that he is authorized to access.

This ''all or nothing'' approach to access is an example of coarse-grained authorization. Here, access is determined on a seemingly binary ''yes/no'' level based on the role that Bob was assigned provisioning him an account in the system. In Bob's case, he received the Sales role because, as we've said more than a few times now, he works in sales. However, there was no attribute labeled ''role'' that indicated which role he would be assigned. And there doesn't need to be. The logic that determines which entitlements get applied to an identity upon creation can vary wildly. In this scenario, Redbeard Identity's IAM system assigns roles based on the combination of the ''costcenter'' and ''department'' attributes. There could also be application-level roles and policies that provide fine-grained authorization to certain application-specific functions.

Now that Bob's identity has been provisioned and the IAM system has determined what role aligns to that identity, the next step is for the IAM system to begin provisioning Bob's accounts in the various downstream systems that he is entitled to access. Users with the Sales role get certain birthright entitlements, which are accounts and access that everyone gets just by being active employees within Redbeard Identity with that basic Sales role. Figure 1.2 shows the provisioning process from the IAM system into these account stores in greater detail, with information about the schema for each of the accounts that Bob will be getting:

Figure 1.2 – Different account schemas across different identity stores

The IAM system provisions the following:

Bob's Azure AD accountAn LDAP account in the company's directoryA user account in Redbeard Identity's customer relationship management system where Bob will be spending most of his workdaysAn account in the cloud directory used by Redbeard Identity's cloud-hosted applications

Each one of these account stores is an example of an identity store. This is the place where an application or system can store its own instance of Bob's account with all the application-specific attributes added on. Just like how the HR system was the authoritative source for the IAM system, the IAM system is the authoritative source for these accounts and for many of the attributes within these identity stores. Now that Bob has an Azure Active Directory Account, he can get a mailbox and email address. If you recall from Table 1.2, Bob's main identity record did not have a value under the mail attribute when it was first provisioned. It is only now that the IAM system will detect Bob's email address when checking Azure AD for any new account updates. Upon detecting the discrepancy between the null value for the mail attribute in the identity record it has for Bob and the email attribute it reads on Bob's Azure AD account, the IAM system imports that update into Bob's IAM record with the new information obtained from that authoritative source. But the updates don't stop there! Look at Figure 1.3:

Figure 1.3 – Account attribute synchronization across authoritative sources

Remember that the IAM record itself is an authoritative source for several of the attributes on the downstream accounts that were provisioned as part of Bob's Sales role. In this instance, Bob's LDAP, CRM, and Cloud Directory account will each get Bob's new email address value written to the attribute that each has mapped to correspond to the IAM record's mail attribute value. Now that Bob has all of his accounts provisioned and synchronized with their authoritative sources, Bob is poised to be productive on his first day on the job.

That is to say Bob could be productive, assuming he knew how to identify himself as the owner of the account in each of these systems. This takes us to the last life cycle event depicted in Figure 1.1, which is the issuance of Bob's credentials. Credentials are the evidence used to attest that the person accessing a resource is who they say they are.

When talking about user accounts, credentials most often take the form of a unique identifier (such as a username) and a shared secret. This shared secret is between the person attempting to access a resource and the system that is trying to validate the identity of the person attempting to access a resource (such as a password). Bob's username plus his account password are his credentials to access these Redbeard Identity systems. Let's take a look at how that credential was created and delivered to Bob, as well as how the downstream applications can also verify Bob's identity despite not necessarily needing to maintain a set of their own for Bob to use.

Within Redbeard Identity, the mechanics of creating Bob's credentials are fairly straightforward. As part of the initial account creation process, the IAM system generates a random password to use as the password value on Bob's account. As you can see in Figure 1.3, though the password was generated by the IAM system, the IAM system is not acting as the authoritative source for the password, nor is it even storing the password attribute in its main identity record for Bob. Looking more closely at the schemas on those downstream accounts, we see that the only system that stores Bob's password value (or some form of hash of this value) is the LDAP directory.

In addition to being the only place where that value is stored, there is another unique attribute on that LDAP account called changepwonlogon, which is currently set as true. When the changepwonlogon value is set to true, it will force the person who entered the username and password to enter a new value for the password. When changepwonlogon is false, the person who correctly enters the account's username and password will simply be permitted to access the system or resource they were attempting to access when challenged for their credentials.

Providing the credentials is how a user can authenticate themselves, or how they prove that they are who they say they are. As Bob can't receive that initial password directly from Redbeard Identity's systems since he does not have access to Redbeard Identity's network yet, the IAM system instead issues the first password for Bob's account to Bob's hiring manager.

So why isn't the password written into all of the other identity stores where Bob has an account? In the specific situation we are examining using Bob's onboarding into the Redbeard Identity organization, they are maintaining a single authoritative identity store for all of their application authentication. This means that Bob will use a single, centrally managed username and password to access the applications and systems he needs to use to perform his job. This is as opposed to a system where he would be required to memorize a unique username and password stored and managed by each individual application. This is single sign-on (SSO).

Applications maintain application-specific user records for each user that they use for their own purposes (such as authorization). However, the application delegates authentication to a central identity store using a directory services protocol such as LDAPS or Kerberos, or in the case of many modern web apps, a federated web-based protocol such as SAML or OpenID Connect. Using SSO reduces the number of credentials and the locations where those credentials are stored. This reduces the attack surface that a malicious actor can try to exploit to steal a credential. Using SSO also helps keep Redbeard Identity workers happy since they only have one password to manage.

Bob's first day at Redbeard Identity arrives. He shows up at the office for new hire orientation, receives his laptop, and his hiring manager shares the initial password for his account with him so he can sign into his account. After his credentials are validated, the changepwonlogon attribute triggers the life cycle event responsible for ensuring that the initial password gets changed. Bob enters a new password.

Once that is accepted and written to his LDAP account, the changepwonlogon value flips to false, and Bob becomes the sole owner of his account, which is essential for non-repudiation. From now on, any actions logged under emplid can be tied solely to him since he is the only one who can access resources and applications by authenticating using those credentials. And with that, Bob's identity onboarding experience is complete:

Figure 1.4 – Bob takes ownership of his account

Now that Bob has his account, he needs to sign into the applications he will use to perform the majority of his job duties. As we mentioned earlier, the Redbeard Identity organization maintains its users' passwords exclusively in its LDAP directory. Though Bob has accounts in the user stores of other systems and applications, those applications have delegated their user authentication to that LDAP directory. Applications can perform lookups and password validations directly against the LDAP using LDAPS, but that model has constraints that limit its usefulness as a modern authentication pattern.

Modern applications should rather use identity federation for user authentication, which is a model where the application looks to an external identity authority to receive trusted identity information. The CRM application that Bob will be spending most of his time in uses identity federation to authenticate its users. The process for the CRM app receiving an authentication token for Bob's identity from the identity provider is shown in Figure 1.5:

Figure 1.5 – Federated authentication transaction using an identity provider

Let's break down the steps:

From a browser, Bob goes to the CRM application.Since Bob doesn't have a session cookie, the CRM application redirects the browser to the Identity Provider that it uses for user authentication.The Identity Provider redirects Bob's browser to a logon form to collect Bob's username and password.Bob's username and password are posted to the Identity Provider.The Identity Provider performs the password validation on Bob's account against the authoritative source it uses for authentication – in this case, the LDAP directory where the Redbeard Identity organization stores its user credentials.The LDAP directory responds that the credentials are valid and may optionally send along some additional attributes that the CRM application may need to reference at authentication time.The Identity Provider creates a signed authentication token using its private signing certificate and posts that to the CRM application. The CRM application is assured that Bob has been authenticated by the external Identity Provider due to the unique cryptographic signature on the authentication token.The CRM application looks at the subject of the authentication token, which in this instance is the emplid from the LDAP directory, and matches it to its local account under that same username value. The CRM application examines its local user record for Bob for his jobcode value to determine what application role he can assume. Job code 66061 corresponds to a sales representative role. The CRM app establishes an application session for Bob under that authorization context, and Bob is now logged in.

Important note

It is important to remember that the example we just walked through was meant to highlight IAM concepts, not necessarily IAM architecture or engineering best practices. Organizations' IAM and security maturity can vary greatly as they balance the risk equation of facilitating their core business against the monetary and opportunity costs of identifying and remediating potential security threats.

The Redbeard Identity scenario has provided us with an example of IAM principles in action and shows how the various components of the IAM system combine to form a platform that facilitates business outcomes and secure organizational resources. Now that we have an idea of what an IAM is, let's begin our exploration of it within AWS.

Exploring AWS IAM

''Wait,'' you may be saying, ''I thought this book was supposed to be about AWS IAM? What's the deal with the overwrought organizational identity scenario I just spent the last several pages reading? When do we get to the AWS stuff?'' AWS is a cloud provider that is ultimately governed by identity. AWS environments are owned by Amazon accounts and organizations, and each of the resources created within those environments has life cycle events governing its creation, modification, and eventual termination.

Additionally, the scope and scale of what someone or something can do with those resources are governed by identity, access management policies, and delegated authorization models. Where organizations and technologists encounter difficulty is in understanding the how, what, and why of AWS in the context of identity in light of its rich, and seemingly overlapping, infrastructure-as-a-service and platform-as-a-service components.

Taking a moment to recontextualize your organization's use of AWS through the lens of identity, and especially in the context of the business, security, and governance challenges you may have already solved in on-premises infrastructure in ways similar to the Redbeard Identity scenario, will aid us as we demystify this seemingly complex topic.

According to Amazon (What is IAM?, at https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html),

''AWS IAM (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.''

This reads very similarly to our initial, high-level definition of IAM that we outlined in Understanding IAM. AWS IAM creates and manages the accounts used to sign in to the AWS Management Console and handles credential management and strong authentication capabilities for the accounts it manages.

Access management and authorization for users, services, and even resources, including fine-grained authorization to AWS resources, are managed through access policies that are defined, governed, and validated against AWS IAM. Governance, compliance, and audit are also reported through AWS IAM and presented through other AWS services. AWS IAM and its supporting identity security services offer a complex and feature-rich IAM capability for administrating and controlling who has access to what and under what context that access is authorized.

IAM for AWS and IAM on AWS

AWS IAM is not the only tool that is capable of providing IAM services inside of the AWS cloud. As we saw in the Redbeard Identity scenario, a comprehensive IAM solution at an organizational level is composed of several different systems and services. These fulfill the business and security use cases required for that business. There is not a monolithic ''Redbeard Identity IAM Service.'' Rather, it is a mix and match of various provisioning, governance, authentication, and directory services.

AWS IAM is the service to govern access to AWS services, but there are several other services that can be mixed and matched in pursuit of solutioning business IAM challenges. When speaking about AWS IAM, we are referring to IAM for AWS, specifically in the context of AWS as infrastructure-as-a-service. When we use other AWS services to solve IAM challenges, we are applying IAM on AWS and using those services in the context of AWS as a platform-as-a-service. We will address what some of those other services are and their use cases in later chapters.

Tip

AWS IAM provides identity services for AWS as an infrastructure-as-a-service platform. Other AWS identity services provide identity capabilities for AWS as a platform-as-a-service.

The AWS IAM dashboard

With so much capability, it can be difficult to see how all the pieces fit together, let alone figure out how to mash all of those pieces together in order to develop solutions to identity challenges in the cloud without first familiarizing yourself with the tool directly. Let's start by taking a quick look at the tool as it appears from inside of an AWS environment:

Figure 1.6 – AWS IAM dashboard

The center panel offers a single-pane-of-glass scoreboard for the counts of critical identity objects that are live in the environment. Already, you may recognize some of the IAM terms and concepts that we touched upon in the Redbeard Identity organization example earlier in this chapter, particularly roles, users, and policies. In the context of AWS, each of these terms has a specific definition, which we will discuss in more detail momentarily.

Links to the individual administrative panes for Groups, Users, Roles, Policies, Identityproviders, and Account settings are on the left side of the AWS IAM dashboard. Each one of those links will allow you to individually view and administrate the components.

Further down, we have some reports and analytics tools designed to facilitate policy administration and aid in the creation and audit of policy structures. They govern access to AWS resources in the environment. The Credential Report details the status and age of the credentials for every AWS IAM user managed by the environment. Finally, the Organization activity and Service control policies (SCPs) sections are special administrative sections. They are only activated when an AWS account is part of something called an AWS organization. This is a construct that allows large organizations to govern multiple AWS accounts in line with a single, centralized policy.

Principals, users, roles, and groups – getting to know the building blocks of AWS IAM

In case you couldn't tell, we