AWS IAM Identity Center
Last updated
Last updated
AWS IAM Identity Center (previously known as AWS Single Sign On) offers a secure solution for the central management of workforce identities, allowing to establish or link user identities seamlessly across AWS accounts and applications. That means, if an organization have multiple AWS Accounts, across AWS Organizations, a single sign on to all AWS accounts can be enabled. AWS recommends Identity center as the method for implementing workforce authentication and authorization within AWS, catering to organisations of diverse sizes and types.
With IAM Identity Center, AWS customers gain the ability to efficiently create and oversee user identities within the AWS ecosystem. It can be used to integrate existing identity sources, including but not limited to Microsoft Active Directory, Okta, Ping Identity, JumpCloud, Google Workspace, and Microsoft Entra ID (Azure AD).
Enable multi-account access to AWS accounts: IAM Identity Center simplifies multi-account access management by allowing users to employ their directory credentials for seamless single sign-on access to various AWS accounts. Through their personalised web user portal, users can conveniently view and access their assigned roles across multiple AWS accounts from one centralised location. This streamlined authentication experience extends to AWS CLI, SDKs, and the AWS Console Mobile Application, ensuring a uniform and secure authentication process.
Enable single sign-on access to AWS Apps: IAM Identity Center offers integrated access to AWS applications such as Amazon SageMaker Studio, AWS Systems Manager Change Manager, and AWS IoT SiteWise, enabling zero-configuration authentication and authorization. These applications seamlessly interact with IAM Identity Center to provide a unified view of users and groups, enhancing resource sharing and collaboration within the application environment. This integration ensures an efficient and consistent user experience for accessing AWS applications.
Access EC2 instances running Windows using IAM Identity Center
Other Use cases include Logon to M365 applications, Salesforce and SAML based applications, etc. It can also work with multiple Identity Providers such as Active Directory, Okta, IAM stores etc.
A web-based portal where users can sign in to access their assigned AWS accounts and applications is generally used as shown above. Organizations can customize the portal with their branding for a cohesive user experience.
By default, access to the AWS portal can be obtained via a URL following this format: ‘d-xxxxxxxxxx.awsapps.com/start.’ But most organizations customize it as per company branding.
When setting up IAM Identity Center, AWS account will typically create an SSO instance. It serves as the centralized management point for user identities, access controls, and authentication across multiple AWS accounts and applications. Here are the main components:
AWS Accounts
AWS consumers can link multiple AWS accounts to your AWS Identity Center instance, allowing centralized management of access across those accounts.
Individual identities or collection of such identities that can be created and managed within AWS Identity Center or imported from an external identity provider (IdP).
Internal Users: Users can be created directly in AWS Identity Center. Custom attributes can be created to store additional information about users, for finetuned access control and management
External Identity Providers: Integration with external IdPs like Microsoft Active Directory, Okta, or SAML 2.0 providers for user authentication and management.
A permission set is a collection of IAM policies that define what actions users can take and which resources they can access within an AWS account.
It can include AWS managed policies, customer-managed policies, or custom policies.
Permission sets are assigned to users or groups for specific AWS accounts, determining what resources and actions they can access.
When creating a permission set, AWS consumers can define how long a user’s session remains active before requiring re-authentication, adding an extra layer of security.
Sample Policy example:
AWS SSO Admin refers to the AWS service that allows you to manage AWS Single Sign-On (SSO) features programmatically through the AWS CLI (Command Line Interface) or SDKs.
There is something called as the device code flow (The device code grant type) which is generally used on embedded devices. Example: While setting up Google Chromecast, it shows the pin and then one has to enter the same in Android's Home App, so that it reflects there. It works by starting the flow on the device (think apple TV, etc) and then providing the user a URL and 'user code' to access on a more powerful endpoint. The user will navigate to this URL in a full featured browser and provides auth and the user code. Meanwhile, the device, without a browser, is polling a specific endpoint with that same 'user code'. When the user completes authentication, the endpoint will return an access token or other authentication information to the embedded device.
Similar is the case with AWS and Azure as Cloud providers when it wants user to authenticate with AWS CLI. Following are the steps:
The user 'registers their device' (creates an app) using the /client/register endpoint i.e., the client application (AWS CLI) registers an OIDC client by calling sso-oidc:RegisterClient. It does not need authentication to do it. It will return an OIDC Client ID and Secret
The user 'authorizes their device' (starts Device Authorization Flow) using the /device_authorization endpoint. This endpoint takes the client ID, client secret, and start_url (provided by AWS). The result will be a DeviceCode, UserCode, and VerificationUrl. The client application calls sso-oidc:StartDeviceAuthorization. This generates an URL that looks like https://device.sso.<region-name>.amazonaws.com/?user_code=ABCD-DCBA
The user is asked to visit the verification URL and enter the code. Because this is typically all completed on the same machine, the code can be prefilled. Once the user visits the verification URL, they'll be asked to allow access to the device (this is an OIDC consent screen). Upon clicking allow they'll be redirected via the SP-initiated SAML Flow for authentication (if configured). Upon successfully completing authentication they'll be told they can close the window.
In the back end AWS is recording when the user code associated with the specific AWS SSO start url (and thereby account) has authenticated successfully. Meanwhile the CLI code has been polling the /token endpoint at 1 second intervals (or there abouts) with the deviceCode, UserCode, ClientId, and ClientSecret. Once AWS records the success, this endpoint will return an Access Token (OIDC compliant). Once the end user has accepted the prompt, the client applications calls sso-oidc:CreateToken to retrieve an AWS SSO access token.
The access token provided by AWS can be used in conjunction with many AWS endpoints including sts.assumeRole(), sso.listAccounts, and sso.listRoles. using sts.assumeRole, a CLI can request a short lived access key and secret for a provided role.
With this access token, the client application can use the AWS SSO API, and in particular:
List all the AWS accounts to which the end user has access (sso:ListAccounts)
List all the roles available to the end user in every AWS account (sso:ListAccountRoles)
Assume any of these roles to retrieve temporary STS credentials (sso:GetRoleCredentials)
Once authenticated, it looks something like this:
