All Notes
AWS
AWS
  • AIM
  • General Stuff about AWS
  • AWS Global Infrastructure
  • Interacting with AWS
  • AWS Identity and Access Management
    • AWS Organizations
    • Users
    • Policies and Permissions
    • Groups and Roles
    • Federation
    • Access Control (via available tools)
    • AWS Cognito
    • AWS IAM Identity Center
  • Networking and Content Delivery in AWS
    • AWS VPC
    • AWS Route 53
    • Elastic Load Balancing
    • AWS CloudFront
    • Amazon API Gateway
  • AWS Storage Services
    • Amazon EBS
    • Amazon EFS
    • Amazon FSx
    • S3
    • AWS Databases Services
      • Amazon RDS
      • Amazon DymanoDB
      • Amazon Elasticache
      • Amazon RedShift
      • Amazon DocumentDB
  • AWS Compute Services
    • EC2
    • Elastic BeanStalk
    • AWS Lambda
    • Container Services
      • ECR and ECS
      • EKS
      • AppRunner
  • Other AWS Services
    • CloudFormation
    • AWS Key Management Services (KMS)
    • AWS Secrets Manager
    • AWS Certificate Manager (ACM)
    • AWS Messaging Services
      • AWS SNS (Simple Notification Service)
      • AWS Simple Queue Service (SQS)
    • AWS Systems Manager
      • Application Management
      • Node Management
    • Logging and Monitoring
      • AWS CloudTrail
      • AWS CloudWatch
    • AWS Macie
    • AWS Inspector
    • AWS GuardDuty
Powered by GitBook
On this page
  • Features
  • Use-Cases
  • Components
  • Device Code Authorization
  1. AWS Identity and Access Management

AWS IAM Identity Center

PreviousAWS CognitoNextNetworking and Content Delivery in AWS

Last updated 6 months ago

Features

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

Use-Cases

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.

Components

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.

Identity Sources

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.

Permission Sets

  • 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:

// Created by ChatGPT 
// Role that has read only permissions for Account A: 123456789012 and Account B: 210987654321

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances",
        "ec2:StartInstances",
        "s3:PutObject",
        "s3:GetObject",
        "lambda:InvokeFunction"
      ],
      "Resource": [
        "arn:aws:ec2:us-east-1:123456789012:*",
        "arn:aws:s3:::example-bucket-account-a/*",
        "arn:aws:lambda:us-east-1:123456789012:function:*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

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.

Device Code Authorization

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:

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

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:

Demonstration

// Copy the below command to configure sso

aws configure sso 

SSO session name (Recommended): session1
SSO start URL [None]: https://radifine.awsapps.com/start
SSO region [None]: ap-south-1
SSO registration scopes [sso:account:access]:
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:

https://device.sso.ap-south-1.amazonaws.com/

Then enter the code:

ABCD-DCBA

Once authenticated, it looks something like this:

The only AWS account available to you is: 123456789012
Using the account ID 123456789012
The only role available to you is: Reader
Using the role name "Reader"
CLI default client Region [None]: ap-south-1
CLI default output format [None]:
CLI profile name [Reader-123456789012]: radisession

To use this profile, specify the profile name using --profile, as shown:

aws s3 ls --profile radisession

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 . 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 . This generates an URL that looks like https://device.sso.<region-name>.amazonaws.com/?user_code=ABCD-DCBA

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 to retrieve an AWS SSO access token.

List all the AWS accounts to which the end user has access ()

List all the roles available to the end user in every AWS account ()

Assume any of these roles to retrieve temporary STS credentials ()

sso-oidc:RegisterClient
sso-oidc:StartDeviceAuthorization
sso-oidc:CreateToken
sso:ListAccounts
sso:ListAccountRoles
sso:GetRoleCredentials
Source:
https://cdn.hashnode.com/res/hashnode/image/upload/v1684949549669/df98e960-5aed-49fc-9e1c-f8e4f804eaaa.png?auto=compress,format&format=webp