Object Storage Service (OSS) authorization verifies requests to grant or deny access. To make a decision, OSS evaluates the request type, identity information, and applicable permission policies.
How it works
Request types
OSS classifies access requests into two types based on whether they carry identity information:
Request type | Description |
non-anonymous request | Contains identity-related information, such as a signature, in the request header or URL. |
anonymous request | Does not contain any identity-related information in the request header or URL. |
Authorization principles
OSS authorization follows the principle that an explicit deny takes precedence. Requests are evaluated in the following order of priority:
Explicit Deny (Highest priority): If a request matches a deny rule, OSS immediately denies it.
Allow: If no deny rule matches and an allow rule matches, OSS allows the request.
Implicit Deny (Default): If no rule matches, OSS denies the request by default.
Authorization flow for non-anonymous requests
A non-anonymous request undergoes multi-layer authorization, including a Control Policy (if applicable), authentication, a session policy, a RAM policy, a bucket policy, and ACLs.
The detailed steps of the authorization flow are as follows:
Authentication: OSS authenticates the request by comparing the signature in the request with the signature calculated by the OSS server.
Mismatch: The request is denied.
Match: The process continues to the next step.
Check Control Policy: OSS checks if the resource owner's Alibaba Cloud account belongs to a resource directory (RD) and has Control Policy enabled.
No (The account is not an RD member, or it is an RD member but Control Policy is not enabled): The process continues to the next step.
Yes (The account is an RD member and Control Policy is enabled): OSS evaluates the Control Policy. If the result is an explicit deny or implicit deny, the request is denied. If the result is allow, the process continues.
Check session policy: OSS determines if the request uses a role-based session policy.
Yes: OSS evaluates the session policy. If the result is an explicit deny or implicit deny, the request is denied. If the result is allow, the process continues.
No: This step is skipped, and the process continues.
Check RAM policy and bucket policy: OSS evaluates both policy types separately and combines the results.
RAM policy: An identity-based policy that controls which resources a RAM user can access. For user-level access, OSS determines the authorization result based on the type of account that sends the request:
Alibaba Cloud account AccessKey: The result is an implicit deny.
RAM user AccessKey or STS AccessKey: If the bucket does not belong to the Alibaba Cloud account that owns the RAM user or RAM role, the result is an implicit deny. Otherwise, RAM authorizes the request and returns allow, explicit deny, or implicit deny.
bucket policy: This is a resource-based policy that controls access to a bucket or the resources within it.
No policy is configured: The result is an implicit deny.
A policy is configured: The result is allow, explicit deny, or implicit deny.
Evaluate the combined result: OSS makes a decision based on the combined results from the RAM policy and bucket policy.
If the combined result contains an explicit deny, the request is denied.
If the combined result contains an allow, the request is allowed.
If both results are implicit denies, the process continues to the next step.
Check the API type: The API type determines the next step.
Management API (such as
GetService,PutBucket, andPutLiveChannel): The request is denied.Data API (such as
PutObjectandGetObject): The process continues to ACL evaluation.
Check object ACL and bucket ACL: OSS allows or denies the request based on the evaluation result.
When evaluating the object ACL, OSS considers whether the requester is the bucket owner and the request type (read or write).
If the object ACL is set to inherit from bucket, OSS proceeds to evaluate the bucket ACL. When evaluating the bucket ACL, OSS also considers whether the requester is the bucket owner.
Authorization flow for anonymous requests
Anonymous requests skip checks for a Control Policy (if applicable), authentication, and a RAM policy. OSS authorizes them based only on the bucket policy and ACLs.
The detailed steps of the authorization flow are as follows:
Check bucket policy:
Deny: The request is denied.
Allow: The request is allowed.
Ignore (no policy is configured or no rule matches): The process continues to the next step.
Check object ACL and bucket ACL:
If the object ACL is private: The request is denied.
If the object ACL is public-read or public-read-write: The request is allowed.
If the object ACL is set to inherit from bucket: OSS proceeds to evaluate the bucket ACL.
If the bucket ACL is public-read or public-read-write: The request is allowed.
If the bucket ACL is private: The request is denied.