AWS IAM Identity Center: Basic to Advanced

1. AWS IAM Identity Center Overview

1.1 What is it?

• Single Sign-On (SSO) : Users log in through a single portal and have access to multiple accounts and applications (AWS and SaaS).
• Centralized Identity Management : Creation and management of users and groups in an internal directory or with integration with an external identity provider (IdP), such as Azure AD, Okta, etc.
• Permission Assignment : Associates permission profiles (IAM Roles and policies) with users or groups, controlling exactly what each person can do in each AWS account.

1.2 Differentiation from Other IAM Services

• IAM (Identity and Access Management) is the core service for managing policies, roles, users, and groups in your AWS account.
• IAM Identity Center expands on this functionality by offering SSO across multiple AWS accounts and applications, with a simplified authentication experience.
• It also allows federation configurations with external IdPs and use of standards such as SAML 2.0 and SCIM (for automated user and group provisioning).

1.3 Use Cases

• Multi-account environments : Many companies use AWS Organizations to manage multiple accounts. IAM Identity Center allows you to centrally manage who accesses each account and with what permissions.
• Integration with Corporate Directories : Companies that already have a user directory (e.g. Active Directory, Okta, Azure AD) can synchronize identities and groups to grant or revoke access centrally.
• Simplified Access to SaaS Applications : In addition to AWS accounts, IAM Identity Center can provide access to third-party services (Salesforce, Office 365, etc.) using SAML or OpenID Connect (OIDC).

2. Basic Settings

2.1 Enabling IAM Identity Center

1. Go to the AWS Management Console .
2. Go to IAM Identity Center (it may be listed as “AWS Single Sign-On” in some older regions).
3. If this is your first time, click Enable IAM Identity Center .
4. Choose directory mode:
   • IAM Identity Center directory (default) – manages users/groups within the service itself.
   • External Identity Provider – Integrates with an existing IdP via SAML 2.0 or via AWS Directory Service (for on-premises Active Directory, for example).

2.2 Creating Users and Groups (internal mode)

• Users : Enter name, email, MFA configuration (if desired), etc.
• Groups : Define groups like “DevOps”, “Finance”, “Security” and add users.
• Manual Provisioning : If you don't have an external IdP, you can create users directly in IAM Identity Center.

2.3 Assigning Access to AWS Accounts

1. Vá em AWS Accounts no IAM Identity Center.
2. Select the account you want to configure.
3. Clique em Assign Users or Groups.
4. Select the user or group and choose a role (or create a new one) to determine permissions.
   • Example: “PowerUserAccess” for DevOps teams; “ReadOnlyAccess” for auditing, etc.

2.4 Access Portal

• Once configured, each user uses an SSO Portal (for example, https://<yourcompany>.awsapps.com/start) to log in.
• In this portal, the user sees the AWS accounts and available applications. With one click, the user can access the consoles without having to re-enter credentials or keys.

3. Integration with Identity Providers (IdP)

3.1 Benefits

• Automated Provisioning (SCIM): When a new employee joins the organization (created in the IdP), it is automatically propagated to the IAM Identity Center, avoiding manual rework.
• Single Sign-On with Central MFA : Strong authentication occurs at the IdP (e.g., Azure AD with MFA). Users do not need to have separate passwords for IAM Identity Center.
• Immediate Revocation : If the user is removed from the IdP (e.g., termination), their AWS access is also revoked.

3.2 Integration Methods

1. SAML 2.0 : Most IdPs like Okta, Ping, Azure AD, ADFS support SAML.
2. SCIM : For automatic provisioning of users and groups.
3. Azure AD : Native integration allows you to configure single sign-on and provisioning without additional scripts, following official AWS and Microsoft tutorials.
4. Okta : Similar to Azure AD, with official guides for SAML + SCIM.

3.3 Simplified Step-by-Step (Azure AD Example)

1. In AWS IAM Identity Center, choose “External identity provider” and select SAML 2.0.
2. In Azure AD, configure a SAML enterprise application pointing to the IAM Identity Center endpoint.
3. Export metadata and import into IAM Identity Center.
4. Enable SCIM for automatic provisioning by copying the provisioning token from IAM Identity Center to Azure AD.
5. Test with a test user in Azure AD, and verify that it appears in the IAM Identity Center.

4. Advanced Features

4.1 Customizing Permission Assignment

• Permission Sets : These are collections of IAM policies that define permissions. You associate them with users/groups for certain accounts.
  • Ex.: “DevOpsProdPermissionSet” with the ability to create and manage resources, but without the ability to delete logs.
• Advanced Policies : CombineAWS managed policies withcustom policies for extra granularity (e.g., restricting access to specific buckets in S3).

4.2 Enhanced MFA Configuration

• MFA at the External IdP : If you are using Okta or Azure AD, the IdP's MFA solution manages authenticity.
• Internal MFA : If you are using the internal IAM Identity Center directory, you can configure MFA based on authentication apps (Google Authenticator, Authy, etc.).
• Adaptive/Contextual MFA : Some IdPs support adaptive MFA — prompting for MFA only if the user is outside the corporate network or in suspicious locations.

4.3 Auditing and Logs

• AWS CloudTrail : Records events related to IAM Identity Center, such as permission set creation, group assignment, login attempts, etc.
• AWS CloudWatch Metrics/Logs : Can be used to monitor activity and create alarms, for example, if login failure occurs repeatedly.
• IdP Logs : In SAML integrations, part of the auditing also occurs at the IdP, recording who accessed which applications.

4.4 Credential Rotation and Management

• Temporary Credentials : When a user accesses an account via IAM Identity Center, IAM roles with temporary credentials (STS) are used.
• Session Policies : It is possible to limit the session duration, forcing re-authentication after a period.
• Access Keys : IAM Identity Center can also provide programmatic (CLI) access by generating temporary credentials for users, ensuring that long-term credentials are not required.

4.5 Provisioning and Deprovisioning (SCIM)

• If your organization uses a SCIM 2.0- compatible IdP, you can automate:
  • User Creation : Whenever a user is created in the IdP, it is entered into the IAM Identity Center.
  • Group Assignment : If the user is added to a “DevOps” group in the IdP, he or she automatically gains corresponding access in AWS.
  • Removal : If you leave the company or group, access is revoked.

5. Best Practices

1. Least Privilege : Create specific permission sets for each job function, avoiding granting “AdministratorAccess” indiscriminately.
2. Environment Separation : Use different permission sets for development, staging, and production, ensuring that unrestricted access does not leak into production.
3. Force MFA : If your IdP is not using MFA, enable MFA at least in the IAM Identity Center for sensitive accounts.
4. Routine Access Policy : Periodically review who has access to which accounts/permission sets and remove obsolete privileges.
5. Provisioning Automation : Whenever possible, use SCIM to synchronize users, reducing manual errors.
6. Multi-account governance : If you are using AWS Organizations, enable delegation so that IAM Identity Center manages all member accounts.

6. Conclusion

Additional Resources

• Official IAM Identity Center (AWS SSO) Documentation
• Integrating AWS SSO with Azure AD
• Okta Integration Guide
• IAM Identity Center e AWS Organizations