Assume Role Policy Generator

Role assumption in AWS IAM always has two separate, independently-configured halves, and mixing them up is one of the most common sources of "Access denied" confusion when setting up cross-account access. Assume Role Policy Generator builds the half that is easy to forget: the permissions statement attached to the calling user or role, granting it the ability to attempt an assume-role call against one or more specific target roles.

The other half — deciding who is allowed to assume a given role — is a trust policy attached to the target role itself, and this site has a separate, dedicated IAM Trust Policy Generator for exactly that. The two are not interchangeable and neither one alone is sufficient: a user can have this tool's permission statement attached and still be denied if the target role's trust policy does not name them, and a role's trust policy can name a caller perfectly and that caller will still be denied if it lacks permission to call sts:AssumeRole in the first place. This tool exists specifically to fill the gap most people forget: it is entirely possible to configure a role's trust relationship correctly and still get "not authorized to perform sts:AssumeRole" because the calling identity was never actually granted permission to call it.

Enter one or more target role ARNs, one per line — a common case is a single operator role needing access to the same-named role across several member accounts in an organization, so multiple targets in one statement is a first-class, expected use, not an edge case. Every line is trimmed, de-duplicated, and validated as a structurally well-formed ARN before a statement is built; an invalid line is rejected with a specific error rather than silently dropped or silently included.

The action defaults to the standard sts:AssumeRole, but two federated variants are available and must be chosen deliberately rather than guessed: sts:AssumeRoleWithSAML when the calling identity authenticates through a SAML identity provider before assuming the role, and sts:AssumeRoleWithWebIdentity when it authenticates through an OIDC provider. Which variant is correct depends entirely on how the calling identity itself authenticates, not on anything about the target role, so this tool leaves the choice explicit rather than trying to infer it.

An optional External ID field adds the standard sts:ExternalId condition, the same confused-deputy mitigation used in the Trust Policy Generator — but note it only does half the job here too: for the external ID to actually protect anything, the target role's trust policy on the other side needs the matching condition as well. This tool cannot see or verify that; it can only build its own side correctly.

As with the other tools in this category, validation is structural: the same policy-document validator checks Version, a non-empty Statement array, and the required Effect/Action/Resource fields. Nothing about whether the target roles actually exist, whether their trust policies actually permit this caller, or whether an external ID actually matches on both sides is something this tool — running entirely in your browser, with no AWS API access — can confirm. It builds one correct, well-formed half of the relationship; the target role's trust policy remains a separate, required piece of configuration.

• Builds the permission side of role assumption — explicitly distinguished from the resource-side Trust Policy Generator.
• Multiple target role ARNs in one statement, one per line, deduplicated automatically.
• Every target ARN validated before a statement is built.
• Action variant selector — sts:AssumeRole, sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity.
• Optional External ID condition for confused-deputy mitigation.
• Structural policy validation before you copy the result.
• Sample statement preloads a realistic multi-account example.
• Copy as JSON and Download .json.
• One-click clear.
• 100% client-side — nothing typed here is uploaded.

1. Enter one or more target role ARNs, one per line.
2. Pick the action variant matching how this caller authenticates — standard, SAML, or OIDC.
3. Optionally enter an External ID, matching what the target role's trust policy expects.
4. Click Build statement.
5. Review any ARN validation errors and fix the flagged lines.
6. Copy or download the JSON.
7. Attach it to the calling user or role as a permissions policy — not to the target role.
8. Separately configure the target role's trust policy using the Trust Policy Generator, if you have not already.

Example 1 — single target role. Target ARN arn:aws:iam::444455556666:role/PartnerAccess, action sts:AssumeRole, no External ID — a minimal permission statement to assume one role.

Example 2 — multi-account operator access. Three target ARNs, one per line, for the same-named OpsRole in three different member accounts — one statement grants assume permission to all three.

Example 3 — cross-account with External ID. Target ARN arn:aws:iam::999999999999:role/VendorRole, External ID partner-42 — the resulting statement only satisfies the target's trust policy if that role's trust policy requires the same External ID.

Example 4 — SAML-federated caller. Target ARN arn:aws:iam::123456789012:role/AnalystRole, action sts:AssumeRoleWithSAML — used when the calling identity itself federates in via SAML before it can assume this role.

Example 5 — invalid ARN caught. Entering role/Ops instead of a full ARN produces a specific validation error naming that line, and no statement is built.

• Fills the gap most people forget — permission to call AssumeRole, distinct from the target role's trust policy.
• Every target ARN validated before you copy anything.
• Correct action variant for federated callers, chosen explicitly rather than guessed.
• Multi-target statements for common multi-account operator patterns.
• Structural validation before you attach the policy.
• Private — target ARNs and external IDs never leave your browser.