SAML and OIDC federated trust policies share the same overall shape as any other IAM trust policy — a Principal naming the identity provider, and no Resource — but they add a layer most trust-policy tooling glosses over: condition keys whose exact name depends on which specific provider issued the token. Federated Identity Policy Generator is built specifically around that detail, going further than the generic IAM Trust Policy Generator's federated option, which only handles the Principal and the SAML/OIDC action branch.
Pick an identity type, SAML or OIDC, and supply the provider's ARN — for SAML, something like arn:aws:iam::123456789012:saml-provider/CorpOkta; for OIDC, something like arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com. The action is set automatically from the identity type rather than asked as a separate question, because it is not really an independent choice: SAML federation always uses sts:AssumeRoleWithSAML, and OIDC federation always uses sts:AssumeRoleWithWebIdentity.
The part that actually differs meaningfully by provider is the condition block, and this is where the tool does real work rather than cosmetic labeling. SAML has one fixed, provider-agnostic condition key for the assertion's audience claim: SAML:aud, typically restricted to https://signin.aws.amazon.com/saml for console federation. OIDC does not have a fixed key at all — because AWS supports many independent OIDC providers issuing tokens with their own claim namespaces, every OIDC condition key must be prefixed with that specific provider's own hostname, giving keys like token.actions.githubusercontent.com:aud and token.actions.githubusercontent.com:sub. Typing that hostname by hand a second time, separately from the provider ARN you already entered, is exactly the kind of manual step that drifts out of sync — a typo in the hostname portion of a condition key means the condition simply never matches, and the trust policy silently fails to work as intended. This tool eliminates that risk structurally: it parses the OIDC provider ARN you supplied, extracts the hostname from the part after oidc-provider/, and uses that extracted value to build both the audience and subject condition keys, so they can never diverge from the provider ARN itself.
The audience and subject fields are both optional in the form, but leaving them empty in a real trust policy is a meaningful security decision, not a convenience default: without a subject restriction, any workload the identity provider will issue a token for can potentially assume the role, not just the one you intended. The worked example this tool leads with — GitHub Actions OIDC — makes the stakes concrete: restricting the sub claim to repo:my-org/my-repo:ref:refs/heads/main means only workflow runs from that exact repository and branch can assume the role, versus leaving it unset and trusting every GitHub Actions workflow anywhere that can obtain a token from GitHub's OIDC provider for your account.
As with any trust policy, Resource is deliberately absent — the role being assumed is the implicit resource, and the statement builder's default wildcard Resource is actively removed after the statement is assembled, the same approach used by the general-purpose Trust Policy Generator. Validation is structural only: the provider ARN is checked for well-formedness, and for OIDC specifically, that it actually has the oidc-provider/ shape the hostname-extraction logic depends on. This tool cannot confirm the identity provider is actually registered in IAM, that the audience/subject values match what the provider really issues, or that the SAML/OIDC integration is otherwise correctly configured outside of this one trust statement. Everything — ARN parsing, hostname extraction, condition assembly, and validation — runs locally in your browser.