Federation Defined

A federation consists of two components: identity provider and identity consumer.

Each component plays a different role in the process of federation. An identity provider stores identities, provides a mechanism for authentication, and provides a course level of authorization. An identity consumer stores a reference to the identity, providing authorization at a greater granularity than the identity provider.

An identity provider and an identity consumer work together to create a federation. The identity provider and the identity consumer establish a trust relationship between each other. They agree on the type of information to exchange, what information to exchange, in what format, and what security methods and measures they will use.

An identity provider answers the question “Who are you?” Because a prior trust relationship has been established between the identity provider and the identity consumer, the identity consumer trusts the answer supplied by the identity provider and grants access.

There is no expectation that there will be either a synchronization or replication of data between an identity provider and an identity consumer or that an identity provider and an identity consumer are operated by the same organization or entity.

Federation with AWS

Federation with AWS allows for two things. First, it allows you to use AWS as an IdP to gain access to both AWS and non-AWS resources. Amazon Cognito is an AWS service that acts as an IdP. Second, you can use non-AWS resources like Security Assertion Markup Language (SAML) 2.0, OpenID Connect (OIDC), or Microsoft Active Directory as the IdP to facilitate single sign-on (SSO).

Federation enables you to manage access to your AWS resources centrally. With federation, you can use SSO to access your AWS accounts with credentials from your corporate directory. Federation uses open standards, such as SAML or OIDC, to exchange identity and security information between an IdP and an application.

The five mechanisms that the AWS federation can facilitate are as follows:

• Custom-built IdP
• Cross-account access
• SAML
• OIDC
• Microsoft Active Directory

Custom Build an Identity Provider

Custom builds were the original method of federation within AWS, but they have since been supplanted by SAML, OIDC, and Microsoft Active Directory. With SAML, you can build a custom IdP that verifies users and their identities. Though building a custom IdP offers a high degree of customization, it is a complex process, and most customers now use standard solutions.

Cross-Account Access

When you need to access resources across multiple AWS accounts, cross-account access enables you to do so by using only one set of credentials. You can grant users access to resources in company accounts without having to maintain multiple user entities, and your users do not have to remember multiple passwords. Users can access the resources they need in AWS accounts by switching AWS roles. Access is permitted by the policies attached to each role. There are two accounts in cross-account access: the account in which the user resides, or source account, and the account with the resources to which the user wants access, or target account.

The target account has an IAM role that includes two components: a permissions policy and a trust policy. The permissions policy controls access to AWS services and resources, while the trust policy specifies who can assume the role and their external ID.

The source account is given an IAM role (AssumeRole) with a permissions policy that allows you to assume this role. The target account issues short-term credentials to the AssumeRole, which allows access to AWS services and the resources you specify in this credential.

Use cross-account access when you own either the target account or the source account and require no more than coordination between the owners of the source account and the target account. Cross-account access allows users to access the AWS Management Console, AWS APIs (control plane APIs and data plane APIs), and the AWS CLI.

Security Assertion Markup Language

Security Assertion Markup Language (SAML) provides federation between an IdP and a service provider (SP) when you are in an AWS account and a trust relationship has been established between the IdP and the SP. The IdP and the SP exchange metadata in an .xml file that contains both the certificates and attributes that form the basis of the trust relationship between the IdP and the SP.

You interact only with the IdP, and all authentication and authorization occurs between you and the IdP. Based on a successful authentication and authorization, the IdP makes an assertion to the service provider. Based on the previously established trust relationship, the service provider accepts this assertion and provides access.

Use SAML to provide access to the AWS Management Console, AWS APIs (control plane APIs and data plane APIs), and the AWS CLI. SAML can also access Amazon Cognito to control access to cloud services that exist outside AWS, such as software as a solution (SaaS) applications.

OpenID Connect

OpenID Connect (OIDC) is the successor to SAML. OIDC is easier to configure than SAML and uses tokens rather than assertions to provide access. Most use cases for OIDC involve external versus internal users.

With OIDC, OpenID provider (OP) uses a relying party (RP) trust to track the service provider. OP and RP exchange metadata by focusing on the OP providing information to the RP about the location of its endpoints. The RP must register with the OP and then receive a client ID and a client secret. This exchange establishes a trust relationship between the OP and the RP.

Because you interact solitarily with the OP, all authentication and authorization occur only between you and the OP. The OP issues a token to the service provider, which accepts this token and provides access. OIDC includes three different types of tokens.

• ID token establishes a user’s identity.
• Access token provides access to APIs.
• Refresh token allows you to acquire a new access token when the previous one expires.

Companies such as Google, Twitter, Facebook, and Amazon can also establish their own OpenID provider.

After authentication and authorization occur, you can access numerous services, including the AWS Management Console, AWS APIs, and AWS CLIs. You can use OIDC to grant access to AWS services, including Amazon Cognito, Amazon AppStream 2.0, and Amazon Redshift. You can also use OIDC to grant access to SaaS applications outside of AWS.

AWS Single Sign-On

AWS Single Sign-On (AWS SSO) is an AWS service that manages SSO access. AWS SSO allows users to sign in to a user portal with their existing corporate credentials and access both AWS accounts and business accounts. You can have multiple permission sets, allowing for greater granularity and control over access.

AWS CLI Access

You can sign in to the AWS SSO user portal with your existing corporate credentials and receive all AWS CLI credentials for your AWS accounts from a central location. These AWS CLI credentials automatically expire after 60 minutes to prevent unauthorized access to AWS accounts.

Management with AWS Organizations

AWS SSO enables management of SSO access and user permissions for your AWS accounts managed through AWS Organizations. Additional setup in the individual accounts is not required. AWS SSO automatically configures and maintains the necessary permissions in your accounts. You can assign user permissions based on common job functions and customize these permissions to meet your specific security requirements.

AWS SSO records all user portal sign-in activities in AWS CloudTrail, providing visibility into data, such as which users accessed specific accounts and applications from the user portal. AWS SSO records details, including IP address, user name, date, and time of the sign-in request. Changes made by administrators in the AWS SSO console are also recorded in CloudTrail.

Integration with Microsoft Active Directory

AWS SSO integrates with Microsoft Active Directory through the Directory Service, enabling you to sign in to the user portal using your Active Directory credentials. With the Active Directory integration, you can manage SSO access to your accounts and applications for users and groups in your corporate directory. For instance, when you add DevOps Active Directory users to your production AWS group, you are granted access to your production AWS accounts automatically. This makes it easier to onboard new users and gives existing users SSO access so that they can quickly access new accounts and applications.

Figure 10.1 shows the various AWS SSO options.

Microsoft Active Directory as Identity Provider

Many enterprises already use Microsoft Active Directory as their identity store. Integrating Active Directory, rather than configuring a new identity store, simplifies administrative overhead. AWS Managed Microsoft AD provides multiple ways to use Amazon Cloud Directory and Microsoft Active Directory with other AWS services.

Directories store information about users, groups, and devices, which administrators use to manage access to information and resources. AWS Directory Service provides multiple directory choices for customers who want to use an existing Microsoft Active Directory or Lightweight Directory Access Protocol (LDAP)–aware applications in the cloud. It also offers those same choices to developers who need a directory to manage users, groups, devices, and access.

There are four different ways to implement Microsoft Active Directory in an AWS infrastructure.

• Run Microsoft Active Directory on Amazon EC2 with an AWS account.
• Use Active Directory Connector (AD Connector) to connect AWS services with an on-premises Microsoft Active Directory.
• Create a Simple Active Directory (Simple AD) that provides basic Active Directory compatibility.
• Deploy AWS Managed Microsoft AD.

Microsoft Active Directory on Amazon EC2 with AWS Account

AWS provides a comprehensive set of services and tools for deploying Microsoft Windows–based workloads in its secure cloud infrastructure. Active Directory Domain Services (AD DS) and Domain Name System (DNS) are core Windows services that provide the foundation for many enterprise-class Microsoft-based solutions, including Microsoft SharePoint, Microsoft Exchange, and .NET applications.

When deploying AD DS on Amazon EC2, you are responsible for deploying in a highly available configuration. You are also responsible for verifying that AD DS is backed up and configured in a fault-tolerant mode. Microsoft Active Directory deploys either as a primary or secondary domain controller, and you can choose to use Amazon Machine Images (AMI) or import your own virtual machine images.

Active Directory Connector

Active Directory Connector (AD Connector) connects your existing on-premises Microsoft Active Directory with compatible AWS applications. AWS-compatible applications include Amazon WorkSpaces, Amazon QuickSight, Amazon WorkMail, and Amazon EC2 for Windows Server instances, among others. With AD Connector acting as a proxy service, you can add a service account to your Active Directory, and AD Connector eliminates the need for directory synchronization or the cost and complexity of hosting a federation infrastructure.

When you add users to AWS applications, AD Connector reads your existing Active Directory to create lists of users and groups from which to select. When users sign in to the AWS applications, AD Connector forwards sign-in requests to your on-premises Active Directory domain controllers for authentication.

Management of your Active Directory does not change; you add new users and groups and update passwords using the standard Active Directory administration tools in your on-premises Active Directory. This helps you to consistently enforce your security policies, such as password expiration, password history, and account lockouts, regardless of whether users are accessing resources on-premises or on the AWS Cloud.

AD Connector enables you to access the AWS Management Console and manage AWS resources by signing in with your existing Active Directory credentials. AD Connector is not compatible with Amazon RDS for SQL Server.

You can use the AD Connector to enable MFA for your AWS application users by connecting it to your existing RADIUS-based MFA infrastructure. This provides an additional layer of security when users access AWS applications.

Simple Active Directory

Simple Active Directory (Simple AD) is a Microsoft Active Directory that is compatible with AWS Directory Service and is powered by Samba 4. Simple AD is a standalone directory in the cloud, where you create and manage identities and manage access to applications. You can use many familiar Active Directory–aware applications and tools that require basic Active Directory features.

Simple AD supports basic Active Directory features such as user accounts, group memberships, memberships for a Linux domain or Windows-based Amazon EC2 instances, Kerberos-based SSO, and group policies. However, Simple AD does not support trust relationships, DNS dynamic update, schema extensions, MFA, communication over LDAPs, PowerShell Active Directory cmdlets, or Flexible Single Master Operation (FSMO) role transfer. In addition, Simple AD is not compatible with RDS SQL Server.

Simple AD is compatible with the following AWS applications: Amazon WorkSpaces, WorkDocs, Amazon QuickSight, and WorkMail. You can sign in to the AWS Management Console and manage AWS resources with Simple AD user accounts.

AWS Managed Microsoft AD

AWS Managed Microsoft AD is an actual Microsoft Windows Server Active Directory, managed by AWS in the AWS Cloud. It enables you to migrate a broad range of Active Directory–aware applications to the AWS Cloud. AWS Managed Microsoft AD works with Microsoft SharePoint, Microsoft SQL Server Always-On Availability Groups, and many .NET applications.

Figure 10.2 illustrates Directory Service and its relation to AWS applications and services: Amazon EC2, Active Directory–aware workloads, cloud applications, and on-premises Active Directory.

Directory Service includes key features that enable you to extend your schema, manage password policies, and enable secure LDAP communications through Secure Socket Layer (SSL)/Transport Layer Security (TLS). The service is approved for applications in the AWS Cloud that are subject to the United States Health Insurance Portability and Accountability Act (HIPAA) or Payment Card Industry Data Security Standard (PCI DSS) compliance when you enable compliance for your directory.

You can add users and groups to AWS Managed Microsoft AD and administration to group policies using familiar Active Directory tools. You scale the directory by deploying additional domain controllers and improve performance by distributing requests across a larger number of domain controllers.

AWS provides monitoring, daily snapshots, and recovery as part of the service. You can connect AWS Managed Microsoft AD with a trust and use credentials to an Active Directory running on-premises. Trust relationship support includes one-way (both in and out) and two-way.

AWS Managed Microsoft AD can support AWS managed applications and services, including Amazon WorkSpaces, WorkDocs, Amazon QuickSight, Amazon Chime, Amazon Connect, and Amazon RDS for SQL Server.