All Products
Search
Document Center

Object Storage Service:Authentication

Last Updated:Nov 06, 2023

For security reasons, all Object Storage Service (OSS) resources (buckets and objects) are private by default. This means that only owners and authorized users have access to the resources. OSS allows you to use a variety of access control policies to grant other users specific permissions to access or use your OSS resources. An access request is allowed only after the access to the resources is authenticated based on all your access control policies.

Request types

Requests are divided into non-anonymous and anonymous requests.

  • Non-anonymous requests

    Non-anonymous requests include signature information in the request headers or request URLs for identity verification.

  • Anonymous requests

    Anonymous requests do not include signature information in the request headers or request URLs.

Authentication of non-anonymous requests

Overview

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

image

The preceding figure shows the possible authentication results:

  • 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 no policy exists. 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.

    OSS compares the signature included in the request with the signature calculated by the OSS server.

    • If the signatures are inconsistent, the request is denied.

    • If the 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 result is Explicit Deny or Implicit Deny, OSS denies the request.

    • If the result is Allow, OSS continues to check the 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 identity-based access control policies. You can configure RAM policies to manage user access to your resources 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 Security Token Service (STS) credentials to access a bucket that does not belong to the RAM user or the owner of the RAM user, OSS implicitly denies the request.

    • OSS calls the authentication operation provided by RAM to authenticate requests. OSS supports authentication based on accounts and the resource groups of buckets. OSS determines whether to allow, explicitly deny, or implicitly deny the request based on the authentication result.

    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 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.

    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 object ACL or bucket ACL.

      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 requested object and bucket.

    When OSS authenticates the request based on the object ACL, OSS checks whether the requester is the bucket owner and whether the request is a read request or a write request. For more information, 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, OSS authenticates the request based on the ACL of the bucket in which the object is stored.

    When OSS authenticates the request based on the bucket ACL, OSS checks whether the requester is the bucket owner. For more information, 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

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

image

Process

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 allows the request.

    • If the authentication result is Ignore, OSS continues to authenticate the request based on the ACL of the object.

  2. OSS authenticates the request based on the ACLs of the requested object and bucket.

    • 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, OSS authenticates the request based on the ACL of the bucket in which the object is stored.

      • 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.