To help you better understand the authorization policy, this document describes the authorization model and rules.

Basic model

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

Access From The Access is Permitted Only When
A primary account The user is the resource owner. Exception: A few cloud products, such as SLS, directly support cross-account ACL authorization. If the ACL authorization check is passed, access is permitted.
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.

Authorization policy check logic 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). 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.

The following figure details the authorization policy check logic.

Figure 1. Authorization policy check logic


When  a RAM user accesses resources, the authorization policy check 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.

Authorization policy check logic 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 authorization policy check 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 check logic described in the preceding section is implemented.
    • If the result is Deny, access is denied.
    • Otherwise, the system proceeds with the next stage.

    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.