By default, the access control list (ACL) of Object Storage Service (OSS) resources, including buckets and objects, is set to private to ensure data security. Only the owners of the resources and authorized users can access these resources. OSS allows you to use a variety of policies to grant other users specific permissions to access or use your OSS resources. A user can access authorized OSS resources only after the user is authenticated by OSS based on all policies.

Request types

Requests can be divided into non-anonymous and anonymous requests.

  • Non-anonymous requests

    Signature information that can be used for identity verification is included in the headers or URLs of the requests.

  • Anonymous requests

    Signature information that can be used for identity verification is not included in the headers or URLs of the requests.

Authentication of non-anonymous requests

Overview

When OSS receives a non-anonymous request, OSS determines whether to allow or deny the request based on identity verification, role-based session policies, identity-based policies (RAM policies), bucket policies, object ACLs, and bucket ACLs.

process

In the preceding figure, the following states are used to indicate whether a request is authenticated successfully:

  • Allow: The request matches an Allow rule specified in a policy. In this case, OSS allows the request.
  • Explicit Deny: The request matches a Deny rule specified in a policy. In this case, OSS explicitly denies the request.
  • Implicit Deny: The request does not match the Allow or Deny rules specified in a policy or the policy that OSS uses to authenticate the request does not exist. In this case, OSS implicitly denies the request.

Process

OSS performs the following steps to authenticate a non-anonymous request:

  1. OSS checks whether the request passes identity verification.

    After OSS receives a request, OSS compares the signature contained in the request with the signature calculated by the OSS server.

    • If the two signatures are inconsistent, the request is denied.
    • If the two signatures are consistent, OSS checks whether the request needs to be authenticated based on role-based session policies.
  2. OSS checks whether the request needs to be authenticated based on role-based session policies.
    If the request needs to be authenticated based on role-based session policies, OSS checks whether the request matches the session policies.
    • If the matching result of the request is Explicit Deny or Implicit Deny, the request is denied.
    • If the matching result of the request is Allow, OSS continues to authenticate the request based on RAM policies and bucket policies.

    If the request does not need to be authenticated based on role-based session policies, OSS proceeds to authenticate the request based on RAM policies and bucket policies.

  3. OSS checks whether the request matches RAM policies and bucket policies.

    RAM policies are configured based on identities. You can configure RAM policies to manage user access to your resources stored in OSS. When OSS authenticates a request based on RAM policies, OSS determines whether to allow or deny the request based on the account used to send the request.

    • If the request is sent by using the AccessKey pair of an Alibaba Cloud account, OSS implicitly denies the request.
    • If the request is sent by using the AccessKey pair of a RAM user or STS credentials to access a bucket that does not belong to the RAM user or the Alibaba Cloud account, OSS implicitly denies the request.
    • OSS calls the authentication operation provided by RAM to authenticate requests. Authentication based on accounts and the resource groups of buckets is supported. After authentication, OSS determines whether to allow, explicitly deny, or implicitly deny the request.

    Bucket policies are resource-based authorization policies. The owner of a bucket can configure bucket policies to authorize RAM users or other Alibaba Cloud accounts to perform operations on the bucket or specific resources in the bucket.

    • If no bucket policy is configured for the bucket, OSS implicitly denies the request.
    • If bucket policies are configured for the bucket, OSS checks whether the request matches the bucket policies and then determines whether to allow, explicitly deny, or implicitly deny the request.
  4. OSS checks whether the request matches an Explicit Deny rule specified in all policies described in the preceding three steps.

    If the request matches an Explicit Deny rule, OSS denies the request. If the request does not match an Explicit Deny rule, OSS checks whether the request matches an Allow rule specified in all policies described in the preceding three steps.

    1. OSS checks whether the request matches an Allow rule specified in RAM policies and bucket policies.

      If the request matches an Allow rule, OSS allows the request. If the request does not match an Allow rule, OSS checks the source of the request.

    2. OSS checks the source of the request.

      If the request is sent by calling a management API operation, OSS denies the request. If the request is sent by calling a data API operation, OSS checks the ACLs of the object and bucket that the request is sent to access.

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

      Data API operations include object-related operations, such as PutObject and GetObject.

  5. OSS authenticates the request based on the ACLs of the object and bucket that the request is sent to access.
    When OSS authenticates the request based on the object ACL, OSS checks whether the user that sends the request is the bucket owner and whether the request is a read request or a write request. For more information about object ACLs, see PutObjectACL.
    • If the authentication result is Allow, OSS allows the request.
    • If the authentication result is Deny, OSS denies the request.

    If the ACL of the object is inherited from the bucket in which the object is stored, OSS authenticates the request based on the ACL of the bucket.

    When OSS authenticates the request based on the bucket ACL, OSS checks whether the user that sends the request is the bucket owner. For more information about bucket ACLs, see PutBucketAcl.
    • If the authentication result is Allow, OSS allows the request.
    • If the authentication result is Deny, OSS denies the request.

Authentication of anonymous requests

Overview

When OSS receives an anonymous request, OSS determines whether to allow or deny the request only based on bucket policies, object ACLs, and bucket ACLs. OSS does not verify the identity of the user or authenticate the user based on role-based session policies or RAM policies.

Process

acl

OSS performs the following steps to authenticate an anonymous request:

  1. OSS authenticates the request based on bucket policies.
    • If the authentication result is Deny, OSS denies the request.
    • If the authentication result is Allow, OSS continues to authenticate the request based on the ACL of the bucket that the request is sent to access.
  2. OSS authenticates the request based on the ACLs of the object and bucket that the request is sent to access.
    • If the ACL of the object is private, the authentication result is Deny and OSS denies the request.
    • If the ACL of the object is public read or public read/write, the authentication result is Allow and OSS allows the request.
    • If the ACL of the object is inherited from the bucket in which the object is stored, OSS authenticates the request based on the ACL of the bucket.
      • If the ACL of the bucket is public read or public read/write, the authentication result is Allow and OSS allows the request.
      • If the ACL of the bucket is private, the authentication result is Deny and OSS denies the request.