Evaluation rules

Last Updated: Oct 16, 2017

To help you better understand the authorization policy, this article explains the access control evaluation logic and the policy evaluation logic in RAM.

Access control evaluation logic

When a user attempts to access a resource by using different identities, RAM evaluates the access with corresponding logics.

Access From The Access is Permitted Only When
A primary account The user is the resource owner.
A RAM-User identity
  • The primary account to which the RAM-User belongs has the access permission for the resource.
  • The primary account has attached an explicit Allow authorization policy to the RAM-User.
A RAM-Role identity
  • The primary account to which the RAM-Role belongs has the access permission for the resource.
  • The primary account has attached an explicit Allow authorization policy to the RAM-Role.
  • The role’s STS-Token is explicitly authorized.

Policy evaluation logic

Authorization policy statements support two types of authorization: Allow and Deny. When multiple authorization policy statements grant Allow and Deny permissions for the same resource, Deny takes priority.

For a RAM-User identity

By default, RAM-Users do not have resource access permissions unless they have been explicitly authorized by the primary account (that is, they have been attached with an authorization policy).

The following figure details the logic of an authorization policy evaluation:

Authorization Policy Evaluation Logic

If a RAM-User attempts to access a resource, the policy evaluation logic is as follows:

  1. The system checks whether a RAM-User identity is authorized according to the authorization policy attached with the RAM-User identity.

    • If the result is Deny, access is denied.

    • Otherwise, the system proceeds with the next stage.

  2. The system checks whether the primary account of the RAM-User has access permission for the resource.

    • If the account is the resource owner, access is permitted.

    • If the account is not the resource owner, the system checks whether the resource supports cross-account ACL authorization.

      • If yes, access is permitted.

      • Otherwise, access is denied.

For a RAM-Role identity

If a user attempts to access a resource by using a RAM-Role (that is, using an STS-Token), the policy evaluation logic is as follows:

  1. If the current STS-Token specifies an authorization policy (the authorization policy parameters entered when the AssumeRole API is called), the authorization policy evaluation logic described in the preceding section is implemented.

    • If the result is Deny, access is denied.

    • Otherwise, the system proceeds with the next stage.

    Note: If the STS-Token does not specify an authorization policy, the system automatically goes to the next stage.

  2. The system checks whether the RAM-Role identity is authorized according to the authorization policy attached with the RAM-Role identity.

    • If the result is Deny, access is denied.

    • Otherwise, the system proceeds with the next stage.

  3. The system checks whether the primary account of the RAM-User has access permission for the resource.

    • If the account is the resource owner, access is permitted.

    • If the account is not the resource owner, the system checks whether the resource supports cross-account ACL authorization.

      • If yes, access is permitted.

      • Otherwise, access is denied.

Thank you! We've received your feedback.