Permission evaluation rules

Last Updated: Aug 02, 2017

Basic model

  • When a user attempts to access a resource by using a primary account, if the user is the resource owner, access is permitted. Otherwise, access to the resource is denied.
  • When a user attempts to access a resource by using the RAM-User identity, if the primary account to which the RAM-User belongs has the access permission for the resource and the primary account has bound to an explicit Allow authorization policy to the RAM-User, access is permitted. Otherwise, access to the resource is denied.
  • When a user attempts to access a resource by using the RAM-Role identity, access is permitted if the primary account to which the RAM-Role belongs has the access permission for the resource, the primary account has been used to bind an explicit Allow authorization policy to the RAM-Role, and the role’s STS-Token is explicitly authorized. Otherwise, access to the resource is denied.

Logic of authorization policy inspection for 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 bound to an authorization policy). Authorization policy statements support two types of authorization: Allow and Deny. When there are multiple authorization policy statements that grant Allow and Deny permissions for the same resource, Deny takes priority.

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 following occurs in the permission inspection logic:

  1. The system checks whether a RAM-User identity is authorized according to the authorization policy bound to the RAM-User identity. If the result is Deny, access is denied. Otherwise, the system proceeds with the next inspection.

  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.

Logic of authorization policy inspection for RAM-Role identity

If a user attempts to access a resource by using a RAM-Role (that is, using an STS-Token), the following occurs in the permission inspection logic:

  1. If the current STS-Token specifies an authorization policy (the authorization policy parameters entered when the AssumeRole API is called), the authorization policy inspection logic described in the preceding section is implemented. If the result is Deny, access is denied. Otherwise, the system proceeds with the next inspection. Note that if the STS-Token does not specify an authorization policy, the system automatically continues to the next inspection.

  2. The system then checks whether the RAM-Role identity is authorized according to the authorization policy bound to the RAM-Role identity. If the result is Deny, access is forbidden. Otherwise, the system proceeds with the next inspection.

  3. The system then 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.