Help Center/ Identity and Access Management_Identity and Access Management (New Edition)/ API Reference/ Permissions and Supported Actions/ STS Identity Policy-based Authorization Reference
Updated on 2026-07-22 GMT+08:00
View PDF
Share

STS Identity Policy-based Authorization Reference

IAM provides system-defined identity policies to define typical cloud service permissions. You can also create custom identity policies using the actions supported by cloud services for more refined access control.

In addition to IAM, the Organizations service also provides Service Control Policies (SCPs) to set access control policies.

SCPs do not actually grant any permissions to an entity. They only set the permissions boundary for the entity. When SCPs are attached to an organizational unit (OU) or a member account, the SCPs do not directly grant permissions to that OU or member account. Instead, the SCPs only determine what permissions are available for that member account or those member accounts under that OU. The granted permissions can be applied only if they are allowed by the SCPs.

To learn more about how IAM is different from Organizations for access control, see How IAM Is Different from Organizations for Access Control?.

This section describes the elements used by IAM custom identity policies and Organizations SCPs. The elements include actions, resources, and conditions.

Actions

Actions are specific operations that are allowed or denied in an identity policy.

  • The Access Level column describes how the action is classified (List, Read, or Write). This classification helps you understand the level of access that an action grants when you use it in an identity policy.
  • The Resource Type column indicates whether the action supports resource-level permissions.
    • You can use a wildcard (*) to indicate all resource types. If this column is empty (-), the action does not support resource-level permissions and you must specify all resources ("*") in your identity policy statements.
    • If this column includes a resource type, you must specify the URN in the Resource element of your identity policy statements.
    • Required resources are marked with asterisks (*) in the table. If you specify a resource in a statement using this action, then it must be of this type.

    For details about the resource types defined by STS, see Resources.

  • The Condition Key column contains keys that you can specify in the Condition element of an identity policy statement.
    • If the Resource Type column has values for an action, the condition key takes effect only for the listed resource types.
    • If the Resource Type column is empty (-) for an action, the condition key takes effect for all resources that action supports.
    • If the Condition Key column is empty (-) for an action, the action does not support any condition keys.

    For details about the condition keys defined by STS, see Conditions.

  • The Alias column lists the policy actions that are configured in identity policies. With these actions, you can use APIs for policy-based authorization. For details, see Policies and Identity Policies.

The following table lists the actions that you can define in identity policy statements for STS.

Table 1 Actions supported by STS

Action

Description

Access Level

Resource Type (*: required)

Condition Key

Alias

sts:agencies:assume

Grants permission to obtain a set of temporary security credentials that you can use to access resources that you might not normally have access to.

Write

agency *

g:ResourceTag/<tag-key>

-

-

sts:agencies:assumeWithSAML

Grants permission to obtain a set of temporary security credentials for users who have been authenticated via a SAML authentication response.

Write

agency *

g:ResourceTag/<tag-key>

-

-

sts:agencies:assumeWithOIDC

Grants permission to obtain a set of temporary security credentials for users who have been authenticated with a OIDC provider token.

Write

agency *

g:ResourceTag/<tag-key>

-

-

sts::setContext

Grants permission to set trusted context on a STS session.

Write

agency *

g:ResourceTag/<tag-key>

-

-

sts::createContextAssertion

Grants permission to create a context assertion.

Write

contextProvider *

-

-

sts::decodeAuthorizationMessage

Grants permission to decode additional information about the authorization status of a request from an encoded message returned in response to a request.

Write

-

-

-

sts::setSourceIdentity

Grants permission to set a source identity on a STS session.

Write

agency *

g:ResourceTag/<tag-key>

-

-

sts:SourceIdentity

sts::tagSession

Grants permission to add tags to a STS session.

Tagging

agency *

g:ResourceTag/<tag-key>

-

-

sts::createServiceBearerToken

Grants permission to get the service bearer token.

Write

-

-

Each API of STS usually supports one or more actions. Table 2 lists the supported actions and dependencies.

Table 2 Actions and dependencies supported by STS APIs

API

Action

Dependencies

POST /v5/agencies/assume

sts:agencies:assume
  • sts::tagSession
  • sts::setSourceIdentity

POST /v5/agencies/assume-with-saml

sts:agencies:assumeWithSAML
  • sts::tagSession
  • sts::setSourceIdentity

POST /v5/agencies/assume-with-oidc

sts:agencies:assumeWithOIDC
  • sts::tagSession
  • sts::setSourceIdentity

POST /v5/decode-authorization-message

sts::decodeAuthorizationMessage

-

Resources

A resource type (Resource) defines the resources on which an identity policy takes effect. In Table 3, if a specific operation has an associated resource type, then in the identity policy statement containing that operation, the policy will only take effect on the specified resource when the corresponding resource URN is provided. If no resource URN is specified, the policy will apply to all resources under the designated resource type. If no resource type is defined, the default value of Resource is *, meaning the policy applies to all resources. In addition, you can set conditions in the identity policy to further refine and restrict the resource type.

The following table lists the resource types that you can define in identity policy statements for STS.

Table 3 Resource types supported by STS

Resource Type

URN

agency

iam::<account-id>:agency:<agency-name-with-path>

assumed-agency

sts::<account-id>:assumed-agency:<agency-name>/<session-name>

contextProvider

iam::<account-id>:contextProvider:<provider-name>

Conditions

Condition Key Overview

A Condition element lets you specify conditions for when an identity policy is in effect. It contains condition keys and operators.

  • The condition key that you specify can be a global condition key or a service-specific condition key.
    • Global condition keys (with the g: prefix) apply to all actions. Cloud services do not need to provide user identity information. Instead, the system automatically obtains such information and authenticates users. For details, see Global Condition Keys.
    • Service-specific condition keys (with the abbreviation of a service name plus a colon as the prefix, for example, sts) apply only to operations of the xx service. For details, see Table 4.
    • The number of values associated with a condition key in the request context of an API call makes the condition key single-valued or multivalued. Single-valued condition keys have at most one value in the request context of an API call. Multivalued condition keys can have multiple values in the request context of an API call. For example, a request can originate from at most one VPC endpoint, so g:SourceVpce is a single-valued condition key. You can tag resources and include multiple tag key-value pairs in a request, so g:TagKeys is a multivalued condition key.
  • A condition operator, condition key, and a condition value together constitute a complete condition statement. An identity policy can be applied only when its request conditions are met. For supported condition operators, see operators.

Service-specific condition keys supported by STS

The following table lists the condition keys that you can define in identity policies for STS. You can include these condition keys to specify conditions for when your identity policy is in effect.

Table 4 Service-specific condition keys supported by STS

Service-specific Condition Key

Type

Single-valued/Multivalued

Description

sts:RequestContextProviders

string

Multivalued

Filters access by the context provider URNs.

sts:RequestContext/<context-key>

string

Single-valued

Filters access by the session context key-value pairs embedded in the signed context assertion.

sts:ExternalId

string

Single-valued

Filters access by the external ID that is passed in the request.

sts:SourceIdentity

string

Single-valued

Filters access by the source identity that is passed in the request.

sts:TransitiveTagKeys

string

Multivalued

Filters access by the transitive tag keys that are passed in the request.

sts:AgencySessionName

string

Single-valued

Filters access by the agency session name required when you assume an agency.

sts:DurationTime

numeric

Single-valued

Filters access by the duration times when you create a bearer token.

sts:ServiceName

string

Single-valued

Filters access by the service name when you create a bearer token.

saml:namequalifier

string

Single-valued

Filters access by the hash value of the issuer, account ID, and friendly name.

saml:sub

string

Single-valued

Filters access by the subject of the claim (the SAML user ID).

saml:sub_type

string

Single-valued

Filters access by the value persistent, transient, or the full Format URI.

saml:aud

string

Single-valued

Filters access by the endpoint URL to which SAML assertions are presented.

saml:iss

string

Single-valued

Filters access by on the issuer, which is represented by a URN.

oidc:amr

string

Multivalued

Filters access by the amr claim.

oidc:aud

string

Single-valued

Filters access by the azp claim if it is present; otherwise, filters by the aud claim.

oidc:sub

string

Single-valued

Filters access by the sub claim.

oidc:iss

string

Single-valued

Filters access by the iss claim.