Federated Identity, Roles, and Cross-Account Access

Authenticate in one place, act as a role

Federation exists so that people do not need an AWS identity of their own. They already have a corporate one; the job is to turn that into AWS permissions for a limited time.

Federated human users authenticate with an identity provider and assume roles that provide temporary AWS credentials.

Two distinct things happen, and scenario questions almost always hinge on telling them apart:

So the reading order for any federation question is fixed: identify the authentication source first and the AWS permission-bearing identity second.

Notice what federation deliberately avoids. Nobody receives permanent root credentials, and nobody needs a long-term access key created in each account. The credentials are temporary and their reach is exactly the role's, no wider.

An organization-level permissions ceiling is also not part of this path. A ceiling limits what an identity may do; it never authenticates anybody and never hands out access.

IAM Identity Center as one point of federation

When workforce access spans several accounts, doing federation separately per account becomes the problem. IAM Identity Center provides one point of federation for access to AWS accounts and applications.

Choose IAM Identity Center when workforce access to multiple AWS accounts needs one centrally managed point of federation. That sentence is the selection rule: many accounts, one workforce, one place to manage the mapping.

Identity Center does not force a company to abandon the directory it already runs. IAM Identity Center can connect an existing identity provider and synchronize directory users and groups, or it can create and manage users directly.

A directory can be federated through IAM Identity Center by connecting the external identity provider and synchronizing its users and groups. The existing users and groups become the basis of AWS access assignments instead of being re-created by hand.

What is not a federation path: turning directory groups into account root users, naming a directory group as the principal in a policy attached to a resource, or expecting a permissions ceiling to issue credentials.

Two instance types, two scopes

Identity Center comes in two shapes, and the difference is entirely about how far an assignment can reach.

An organization instance is the IAM Identity Center instance type that can manage access to AWS accounts. An account instance is bound to one AWS account and supports isolated deployments of selected AWS managed applications.

Let the required assignment scope decide. If the requirement says "assign access across our accounts", only the organization instance reaches that far; an account instance is confined to the single account it lives in.

Adding Identity Center without disturbing what works

Adoption rarely happens on a clean slate, and it does not have to. Existing IAM federation workflows can continue to provide AWS account access when IAM Identity Center is introduced for AWS managed applications.

An existing IAM federation workflow can remain in place when the requirement is to preserve current AWS account access while adding Identity Center application access.

That gives a staged path: application access moves to Identity Center now, account sign-in stays exactly as it is, and nothing has to be cut over in one quarter.

Temporary sessions and what bounds them

Roles are not only for people. AWS STS AssumeRole returns temporary credentials whose actions are limited to the permissions of the assumed role.

Both halves matter. The credentials are temporary, so nothing long-lived has to be stored, and their reach is the role's permissions, so the caller's own privileges are irrelevant during the session.

What AssumeRole does not return is just as testable: not a permanent access key for the caller, not a policy attached to the destination resource, and not a new user in the account that owns the role.

Switching replaces, it never accumulates

The most common misconception about roles is that a switched role adds to what you already had. It does not.

A console user who switches to a role gives up the original permissions and receives them back after exiting the role. Only one permission set is effective while a user is operating through a switched role.

This single-set behavior is what makes role switching useful for risky work. An operator who switches into a production role for one narrow task is not carrying development privileges into that session, so a mistake cannot reach beyond the role. And because the change is temporary, the original privileges come back on exit rather than being lost.

Rule out the two tempting misreadings: permissions are not combined for the duration, and the original set is not deleted permanently.

Cross-account access has two halves

Reaching into another account is never a one-sided configuration. Both accounts have to agree, and each does it differently.

For cross-account role access, the destination account creates a role that trusts the originating account and grants permissions to destination resources. The originating account must grant its identity permission to call sts:AssumeRole on the destination role.

Cross-account role access avoids creating an individual IAM user in every destination account — one role, trusted once, instead of a user per person per account.

Because the origin-side grant is separate, it doubles as a filter. Suppose developers in one account need temporary write access to a single bucket in another account, analysts in the same account must not get it, and no duplicate users may be created in the destination.

The design writes itself from the two halves: create a role in the destination limited to that bucket, trust the originating account in it, and on the origin side allow only the developers to call sts:AssumeRole on it. Analysts are excluded precisely because they never receive that grant.

The failure modes are the mirror image. A shared user with long-term keys creates the duplicate identity the constraint forbids and separates nobody. Trusting the origin while granting no sts:AssumeRole permission leaves a role that nobody can use. And expecting original permissions to survive the switch contradicts how role sessions work.

Interactive or programmatic

The last choice is about who is doing the assuming. Use console role switching for an interactive user and AssumeRole for programmatic access that needs temporary credentials.

An application should never be built around a console session, and a permissions ceiling is not a credential source for either caller.

Key takeaways

• Separate the two steps: the identity provider authenticates federated users, and the assumed role supplies temporary AWS credentials.
• One point of federation: Identity Center centralizes workforce access to AWS accounts and applications, using a connected identity provider with synchronized users and groups, or users it manages itself.
• Match the instance to the scope: an organization instance manages access to AWS accounts; an account instance is bound to one account for isolated deployments of selected managed applications.
• Adopt without a cutover: existing IAM federation can keep providing account access while Identity Center is added for applications.
• Sessions replace, not accumulate: AssumeRole returns temporary credentials limited to the role, and only one permission set is effective while a user operates through a switched role.
• Configure both sides: the destination account creates the trusting role with its permissions, and the originating account allows its identity to call sts:AssumeRole.