Object Storage Service:Authorization process

When OSS receives a non-anonymous request, it evaluates the request against the authentication result, role-based session policies, identity-based policies (RAM policies), bucket policies, object access control lists (ACLs), and bucket ACLs to decide whether to allow or deny the request.

The flowchart shows three possible outcomes:

• Allow: the request is permitted by the applicable policy.

• Explicit Deny: the request is explicitly rejected by the applicable policy.

• Implicit Deny: no applicable policy exists, or no policy produces an Allow or Explicit Deny result.

OSS evaluates a non-anonymous request in the following order:

1. OSS verifies the request identity.

   OSS compares the signature in the request against the signature computed by the OSS server.

   • Signatures do not match: OSS denies the request.

   • Signatures match: OSS checks whether the request is subject to role-based session policies.

2. OSS checks whether role-based session policies apply.

   Yes: OSS evaluates the request against the session policies.

   • Explicit Deny or Implicit Deny: OSS denies the request.

   • Allow: OSS continues to check RAM policies and bucket policies.

   No: OSS skips session policy evaluation and proceeds to RAM policies and bucket policies.

3. OSS evaluates RAM policies and bucket policies.

   RAM policies are identity-based access control policies that control which identities can access your OSS resources. OSS determines the outcome based on who sent the request:

   • AccessKey pair of an Alibaba Cloud account: OSS implicitly denies the request.

   • AccessKey pair of a RAM user or Security Token Service (STS) credentials used to access a bucket not owned by the Alibaba Cloud account or the RAM user's owner: OSS implicitly denies the request.

   • For other cases, OSS calls RAM to authenticate the request. OSS supports authentication by account and by resource group of the bucket, and determines whether to allow, explicitly deny, or implicitly deny the request based on the result.

   Bucket policies are resource-based authorization policies. The bucket owner can use bucket policies to grant RAM users or other Alibaba Cloud accounts permission to perform operations on the bucket or specific resources within it.

   • No bucket policy configured: OSS implicitly denies the request.

   • Bucket policy exists: OSS checks whether the request matches the policy and returns Allow, Explicit Deny, or Implicit Deny.

4. OSS checks the combined result for an Explicit Deny.

   If any policy produces an Explicit Deny, OSS denies the request. Otherwise, OSS checks whether any policy produces an Allow.

   1. OSS checks RAM policies and bucket policies for an Allow result.

      If any policy produces an Allow, OSS permits the request. Otherwise, OSS checks the request source.

   2. OSS checks the request source.

      Management API requests are denied. Data API requests proceed to ACL evaluation.

      Management API operations include service operations such as GetService (ListBuckets), bucket operations such as PutBucket and GetBucketLifecycle, and LiveChannel operations such as PutLiveChannel and DeleteLiveChannel.

      Data API operations include object operations such as PutObject and GetObject.

5. OSS evaluates the object ACL and bucket ACL.

   When checking the object ACL, OSS determines whether the requester is the bucket owner and whether the request is a read or write operation. For more information, see PutBucketAcl.

   • Allow: OSS permits the request.

   • Deny: OSS denies the request.

   If the object ACL is set to inherit from the bucket, OSS falls back to the bucket ACL.

   When checking the bucket ACL, OSS determines whether the requester is the bucket owner. For more information, see PutBucketAcl.

   • Allow: OSS permits the request.

   • Deny: OSS denies the request.

For anonymous requests, OSS skips authentication, role-based session policies, and RAM policies entirely. The decision is based solely on bucket policies, object ACLs, and bucket ACLs.

OSS evaluates an anonymous request in the following order:

1. OSS evaluates bucket policies.

   • Deny: OSS denies the request.

   • Allow: OSS permits the request.

   • Ignore (no matching policy): OSS proceeds to ACL evaluation.

2. OSS evaluates the object ACL and bucket ACL.

   • Object ACL is private: OSS denies the request.

   • Object ACL is public-read or public-read-write: OSS permits the request.

   • Object ACL is set to inherit from the bucket: OSS checks the bucket ACL.

     • Bucket ACL is public-read or public-read-write: OSS permits the request.

     • Bucket ACL is private: OSS denies the request.