How policies are evaluated when assuming a RAM role-Resource Access Management(RAM)-阿里云帮助中心

When a principal attempts to assume a Resource Access Management (RAM) role, RAM evaluates a set of policies to determine whether to allow or deny the request. This topic explains the evaluation logic that applies specifically to the sts:AssumeRole action.

Assuming a RAM role is a special action where two sets of permissions must be checked simultaneously:

The principal's permissions: The principal (a RAM user or another role) that is trying to assume the role must have an identity-based policy that grants it permission to call the sts:AssumeRole action on the target role.
The role's trust policy: The role being assumed must have a trust policy (a resource-based policy) that specifies the requester as a trusted principal.

Both of these conditions must be met for the request to be successful. The evaluation process is illustrated below.

RAM角色信任策略判定流程

The process for evaluating policies when assuming a RAM role follows the standard evaluation logic, with one key exception: the decision combination step (Step 4).

Therefore, if you are already familiar with the standard process, you only need to review Step 4 of this topic. For a complete overview of the standard rules, see How RAM evaluates policies.

Step 1: Evaluate Resource Directory control policies (if applicable)

If the account is a member of a resource directory, RAM evaluates the applicable control policies. Control policies serve as permission guardrails for the account.

If the control policy does not allow the requested action, the request is denied and the evaluation stops.
If allowed, evaluation proceeds to the next step.
If no control policies exist, this step is skipped.

Important

Control policies apply to all RAM principals (users and roles) within a member account but do not apply to the owner of that account or any principals in the management account of the Resource Directory.

Step 2: Evaluate RAM role session policies (if applicable)

If the principal is a RAM role assumed with a session policy (such as via the AssumeRole operation), RAM evaluates that policy.

If the session policy does not allow the requested action, the request is denied and the evaluation stops.
If allowed, evaluation proceeds.

Note

This step is skipped for RAM user requests and federated SSO, as session policies do not apply.

Step 3: Evaluate identity-based and resource-based policies

RAM evaluates identity-based policies (attached to the requesting RAM user or role) and resource-based policies (attached to the target resource).

Identity-based policy: RAM evaluates all policies attached to the requesting principal. If any policy explicitly denies the request, the result is an explicit deny. If at least one policy allows the request, the result is an allow. Otherwise, the result is an implicit deny.

Note
During IdP-initiated SSO, the user has not yet assumed an identity, so no identity-based policy is evaluated. Only the RAM role's trust policy is checked.
Resource-based policy: If the target resource has a resource-based policy (such as an OSS bucket policy or a RAM role trust policy), RAM evaluates it with the same logic: the result is an allow, an explicit deny, or an implicit deny. If no resource-based policy exists, this check is skipped.

Step 4: Combine decisions and determine final outcome

Finally, RAM combines the results from Step 3 to make a final decision. The logic for assuming a role is stricter than for other actions:

The request is ALLOWED only if both the identity-based policy and the RAM role's trust policy result in an Allow.
In all other cases—including if either policy results in an implicit deny or an explicit deny—the request is DENIED.