This topic describes permission check models and rules when you access resources as different identities in RAM to help you better understand policies.

Basic model

In RAM, you can access resources by using an account, a RAM user account, or a player account that assumes a RAM role. Authorization judgment conditions vary with the account type you use. The following table describes the details.

Account type Access condition (must be met at the same time)
Account The account 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.
RAM user account
  • The account to which the RAM user belongs has the access permission for the resource.
  • The account has attached an explicit Allow policy to the RAM user.
Player account that assumes a RAM role
  • The account to which the RAM role belongs has the access permission for the resource.
  • The account has attached an explicit Allow policy to the RAM role.
  • The role's secure access token (STS-Token) has been explicitly authorized.

Policy check logic for RAM users

By default, RAM users do not have resource access permissions unless they have been explicitly authorized by their accounts (that is, they have been attached to a policy). Authorization statements support two types of authorization: Allow and Deny. When multiple authorization statements grant Allow and Deny permissions of the same resource, Deny prevails.

The following figure describes the policy check logic.

Figure 1. Policy check logic


When a RAM user accesses resources, the policy check goes according to the following logic:

  1. The system checks whether a RAM user is authorized according to the policy attached to the user.
    • If the result is Deny, access is denied.
    • Otherwise, the system proceeds with the next stage.
  2. The system checks whether the account of the RAM user has the 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.

Policy check logic for RAM roles

When a RAM role accesses resources (by using the role access token), the policy check goes according to the following logic:

  1. If the current token has a specified policy (the policy parameters entered when the AssumeRole API is called), the policy check goes according to the logic described in the preceding section.
    • If the result is Deny, access is denied.
    • Otherwise, the system proceeds with the next stage.

    If the current token does not has a specified policy, the system automatically goes to the next stage.

  2. The system checks whether the RAM role is authorized according to the policy attached to the role.
    • If the result is Deny, access is denied.
    • Otherwise, the system proceeds with the next stage.
  3. The system checks whether the account of the RAM role has the 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.