A complete hands-on handbook — architecture, setup, real command examples, and interview Q&A

1. Architecture Overview

The integration follows a simple identity federation chain:

Okta (Users & Groups)       |  SAML 2.0 (authentication) + SCIM 2.0 (provisioning)       v AWS IAM Identity Center       |  Permission Sets       v AWS Accounts (via AWS Organizations)

Okta acts as the external Identity Provider (IdP) and the single source of truth for users and groups. SAML handles federated sign-in, while SCIM keeps users and groups automatically synced into Identity Center. Permission Sets translate group membership into least-privilege IAM roles inside each target AWS account.

Note: All CLI examples in this handbook use a sample AWS Organization management account ID of 267714372000. Replace it with your own account ID when you follow along.

2. Prerequisites

• AWS account with AdministratorAccess (management account of an AWS Organization, e.g. 267714372222)
• Okta Developer account (free tier is enough for a lab setup)
• AWS CLI v2 installed and on PATH (aws –version should show 2.x)
• At least one additional member AWS account if you want to test multi-account access

3. Step-by-Step Setup

Step 1 — Enable IAM Identity Center

1. Open the AWS Console → search for IAM Identity Center → click Enable.
2. Choose the region that will host Identity Center (this becomes your identity region).
3. Wait for the service to finish initializing (usually under a minute).

Example — verifying via CLI once enabled:

aws sso-admin list-instances # Sample output {     “Instances”: [         {             “InstanceArn”: “arn:aws:sso:::instance/ssoins-8442abcd1234ef56”,             “IdentityStoreId”: “d-9a1234abcd”,             “OwnerAccountId”: “267714372222”         }     ] }

Step 2 — Configure External Identity Provider

• IAM Identity Center → Settings → Identity source → Change identity source.
• Select External Identity Provider (this is what enables SAML federation with Okta).
• Leave this browser tab open — you will need the AWS ACS URL and Audience URI (Entity ID) it displays for Step 4.

Step 3 — Create SAML App in Okta

• Okta Admin Console → Applications → Applications → Create App Integration.
• Choose SAML 2.0 as the sign-in method.
• Application name: “AWS IAM Identity Center”.
• Click Next to move to SAML Settings.

Step 4 — Configure SAML Settings

1. In the AWS IAM Identity Center tab, copy the AWS ACS URL and the AWS SSO Audience URI (Entity ID).
2. In Okta, paste the ACS URL into Single sign-on URL, and the Audience URI into Audience URI (SP Entity ID).
3. Set Name ID format to EmailAddress.
4. Set Application username to “Email” so Okta usernames map cleanly to AWS user emails.

Example values you would paste (yours will differ — these come from your own Identity Center tenant):

ACS URL:      https://us-east-1.signin.aws.amazon.com/platform/saml/acs/abcdef12-3456-7890-abcd-ef1234567890 Audience URI: https://us-east-1.signin.aws.amazon.com/platform/saml/d-9a1234abcd Name ID format: EmailAddress

Step 5 — Exchange Metadata

1. In Okta, on the Sign On tab of the new app, download the Identity Provider metadata (XML file).
2. Back in IAM Identity Center, under Identity source settings, upload that metadata XML.
3. Save. Identity Center now trusts Okta as its SAML IdP.

Note: Once you change the identity source to External Identity Provider, existing Identity Center users must be re-provisioned through SCIM — they are not migrated automatically.

Step 6 — Configure SCIM Provisioning

1. In IAM Identity Center → Settings, enable Automatic provisioning.
2. This generates a SCIM endpoint URL and an Access token — copy both immediately (the token is shown only once).
3. In Okta, open the AWS IAM Identity Center app → Provisioning tab → Configure API Integration.
4. Enable API integration, paste the SCIM Base URL and the token, then Test API Credentials.
5. Enable Create Users, Update User Attributes, and Deactivate Users under Provisioning to App.

Example SCIM endpoint format:

SCIM endpoint: https://scim.us-east-1.amazonaws.com/d-9a1234abcd/scim/v2/ Access token:  (one-time secret shown by Identity Center, store in a secrets manager)

Step 7 — User and Group Sync

• In Okta, create a group, e.g. AWS-Developers, and add test users to it.
• Assign the AWS IAM Identity Center app to that group (Applications → Assign to Groups).
• In AWS, go to IAM Identity Center → Groups and confirm AWS-Developers and its members appear automatically within a few minutes.

Step 8 — Create Permission Sets

• IAM Identity Center → Permission sets → Create permission set.
• Choose a predefined set (e.g. ReadOnlyAccess, PowerUserAccess) or Custom permission set with your own policy.
• Under AWS accounts, select the target account(s) and assign the permission set to the AWS-Developers group.

Example — assigning a permission set to account 267714372000:

aws sso-admin create-account-assignment \   –instance-arn arn:aws:sso:::instance/ssoins-8442abcd1234ef56 \   –target-aws sso-admin create-account-assignment \   –instance-arn arn:aws:sso:::instance/ssoins-8442abcd1234ef56 \   –target-id 267714372222 \   –target-type AWS_ACCOUNT \   –permission-set-arn arn:aws:sso:::permissionSet/ssoins-8442abcd1234ef56/ps-0a1b2c3d4e5f6789 \   –principal-type GROUP \   –principal-id 11111111-2222-3333-4444-555555555555

4. AWS CLI SSO — Day to Day Use

Configure and Log In

aws configure sso SSO session name: my-org-sso SSO start URL: https://my-company.awsapps.com/start SSO region: us-east-1 SSO registration scopes: sso:account:access   # CLI lists available accounts, pick 267714372000 (or your account) then a role, e.g. Developer CLI default client Region: ap-south-1 CLI default output format: json CLI profile name: dev-sso

aws sso login –profiaws configure sso SSO session name: my-org-sso SSO start URL: https://my-company.awsapps.com/start SSO region: us-east-1 SSO registration scopes: sso:account:access   # CLI lists available accounts, pick 267714372222 (or your account) then a role, e.g. Developer CLI default client Region: ap-south-1 CLI default output format: json CLI profile name: dev-sso aws sso login –profile dev-sso # opens the browser for Okta authentication, then AWS device authorization   aws sts get-caller-identity –profile dev-sso {     “UserId”: “AROAEXAMPLEID:jane.doe@company.com”,     “Account”: “267714372222”,     “Arn”: “arn:aws:sts::267714372222:assumed-role/AWSReservedSSO_Developer_a1b2c3d4e5f6/jane.doe@company.com” }

5. Use Case A — S3 Access via Permission Sets

• Create a customer-managed IAM policy scoped to a specific bucket.
• Create a permission set and attach that policy to it.
• Assign the permission set to the Developers group on the target account.
• Validate access using the CLI profile created via SSO.

Example customer-managed policy (scoped to a single bucket):

{   “Version”: “2012-10-17”,   “Statement”: [     {       “Sid”: “ListBucket”,       “Effect”: “Allow”,       “Action”: [“s3:ListBucket”],       “Resource”: [“arn:aws:s3:::company-app-data-267714372222”]     },     {       “Sid”: “ReadWriteObjects”,       “Effect”: “Allow”,       “Action”: [“s3:GetObject”, “s3:PutObject”],       “Resource”: [“arn:aws:s3:::company-app-data-267714372222/*”]     }   ] }

Validate:

aws s3 ls s3://company-app-data-267714372222 –profile dev-sso aws s3 cp ./report.csv s3://company-app-data-267714372222/reports/report.csv –profile dev-sso

6. Use Case B — EKS Access via Permission Sets

• Create an EKS-focused permission set (or reuse an existing developer permission set).
• Identify the AWSReservedSSO role that Identity Center created in the target account for that permission set.
• Create an EKS access entry for that role ARN against the target cluster.
• Associate an EKS access policy such as AmazonEKSViewPolicy (read-only) or AmazonEKSClusterAdminPolicy (full admin).
• Update the local kubeconfig and confirm access with kubectl.

Example — locating the reserved role and wiring up access:

aws iam list-roles –query “Roles[?contains(RoleName, ‘AWSReservedSSO_Developer’)].Arn” –output table # arn:aws:iam::267714372222:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Developer_a1b2c3d4e5f6   aws eks create-access-entry \   –cluster-name prod-app-cluster \   –principal-arn arn:aws:iam::267714372222:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Developer_a1b2c3d4e5f6 \   –type STANDARD   aws eks associate-access-policy \   –cluster-name prod-app-cluster \   –principal-arn arn:aws:iam::267714372222:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Developer_a1b2c3d4e5f6 \   –policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \   –access-scope type=cluster

aws eks update-kubeconfig –name prod-app-cluster –region ap-south-1 –profile dev-sso kubectl get pods -A kubectl get nodes

7. Production Architecture Recommendations

• Use Okta (or Microsoft Entra ID) as the single source of truth for identity — never create users directly inside Identity Center.
• Assign permission sets to groups, not individual users — this keeps access auditable and easy to revoke in bulk.
• Rely on temporary, short-lived credentials from SSO sessions — avoid long-lived IAM access keys entirely.
• Separate permission sets by blast radius: ReadOnly, Developer, and Break-glass Admin, each with its own approval process.
• Enable CloudTrail logging on account assignments and permission-set changes for audit trails.
• Rotate the SCIM token periodically and store it in a secrets manager rather than in plaintext.

8. Troubleshooting Guide

Symptom	Likely Cause	Fix
User not syncing to Identity Center	SCIM token expired/invalid, or user not assigned to the Okta app	Regenerate SCIM token in Identity Center, re-test API credentials in Okta, confirm app assignment
Login failure at Okta/AWS redirect	SAML metadata mismatch or wrong NameID format	Re-download and re-upload IdP metadata; confirm NameID format is EmailAddress
No AWS accounts visible after login	No permission set assigned to the user’s group for that account	Check Identity Center → AWS accounts → account assignments
CLI commands fail with SSO errors	AWS CLI v1 installed instead of v2, or stale SSO cache	Run aws –version to confirm v2; run aws sso login again to refresh the session

9. Interview Questions & Answers

Q1. Why use IAM Identity Center instead of individual IAM users?

IAM Identity Center centralizes authentication through a single external IdP (Okta), issues short-lived temporary credentials instead of long-lived access keys, and lets you manage access across many AWS accounts from one place using groups and permission sets — rather than creating and rotating IAM users/keys separately in every account.

Q2. What is the difference between SAML and SCIM?

SAML is the authentication protocol — it is what lets a user sign in to AWS using their Okta identity via a browser redirect and a signed assertion. SCIM is the provisioning protocol — it is what keeps user and group records themselves in sync between Okta and Identity Center (creating, updating, and deactivating them), independent of any individual sign-in event.

Q3. What is a Permission Set?

A Permission Set is a template that IAM Identity Center uses to create an IAM role (named AWSReservedSSO_<name>_<hash>) inside each AWS account it’s assigned to. It bundles managed and/or customer-managed policies plus optional session duration and boundary settings, and is the mechanism that translates “this Okta group” into “this exact set of AWS permissions” in a given account.

Q4. How do you give EKS access using IAM Identity Center?

You assign a permission set to the user’s group as usual, which creates an AWSReservedSSO IAM role in the account that owns the cluster. Then, on the EKS side, you create an EKS access entry for that specific role ARN and associate an access policy (e.g. AmazonEKSViewPolicy or AmazonEKSClusterAdminPolicy) to define what the role can do inside the cluster. Kubernetes-level access is therefore controlled in two layers: IAM (who can assume the role) and EKS access entries (what the role can do once inside).

10. Senior-Level Production Summary

“We integrated Okta with AWS IAM Identity Center using SAML for authentication and SCIM for provisioning. Permission Sets created AWSReservedSSO roles across accounts — including our management account (267714372000) and member accounts. Users authenticated through Okta and received temporary credentials instead of static keys. EKS and S3 access were granted using group-based permission sets: S3 through scoped customer-managed policies, and EKS through access entries mapped to the AWSReservedSSO roles. This gave us a single, auditable identity source with least-privilege, time-limited access across the entire AWS Organization