Permission control

Last Updated: Aug 08, 2017

This article elaborates on how to configure different policies to implement different permission control based on the app server mentioned in Set up direct data transfer for mobile apps by taking the app-base-oss bucket in the Shanghai region as an example.

Notice:

  • The following illustration assumes you have already activated STS and thoroughly read the previous article Set up direct data transfer for mobile apps.

  • The policies mentioned below are covered in the specified policy file in the config.json file mentioned in the previous section.

  • The operations on OSS upon retrieving the STS token described below refer to the process of specifying the policy for the app server, the app server retrieving a temporary credential from the STS and the app using the temporary credential to access the OSS.

Common policies

  • Full authorization policies

    For the ease of demonstration, the default policy is shown below. This policy indicates that the app is allowed to perform any operations on the OSS. This policy is not secure to use for mobile apps and is not recommended.

    1. ```json
    2. {
    3. "Statement": [
    4. {
    5. "Action": [
    6. "oss:*"
    7. ],
    8. "Effect": "Allow",
    9. "Resource": ["acs:oss:*:*:*"]
    10. }
    11. ],
    12. "Version": "1"
    13. }
    14. ```
    Operations on OSS upon retrieving STS token Result
    List all created buckets Successful
    Upload objects without a prefix, test.txt Successful
    Download objects without a prefix, test.txt Successful
    Upload objects with a prefix, user1/test.txt Successful
    Download objects with a prefix, user1/test.txt Successful
    List all objects, test.txt Successful
    List objects with a prefix, user1/test.txt Successful
  • Read-only policies with or without any prefixes

    This policy indicates that the app can list and download all objects in the bucket app-base-oss.

    1. ```json
    2. {
    3. "Statement": [
    4. {
    5. "Action": [
    6. "oss:GetObject",
    7. "oss:ListObjects"
    8. ],
    9. "Effect": "Allow",
    10. "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"]
    11. }
    12. ],
    13. "Version": "1"
    14. }
    15. ```
    Operations on OSS upon retrieving STS token Result
    List all created buckets Failed
    Upload objects without a prefix, test.txt Failed
    Download objects without a prefix, test.txt Failed
    Upload objects with a prefix, user1/test.txt Failed
    Download objects with a prefix, user1/test.txt Failed
    List all objects, test.txt Failed
    List objects with a prefix, user1/test.txt Failed
  • Read-only policies with a specified prefix

    This policy indicates that the app can list and download all objects with the prefix of user1/ in the bucket app-base-oss. But the policy does not specify to download any objects with another prefix. In this way, different apps corresponding to different prefixes are spatially isolated in the bucket.

    1. ```json
    2. {
    3. "Statement": [
    4. {
    5. "Action": [
    6. "oss:GetObject",
    7. "oss:ListObjects"
    8. ],
    9. "Effect": "Allow",
    10. "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"]
    11. }
    12. ],
    13. "Version": "1"
    14. }
    15. ```
    Operations on OSS upon retrieving STS token Result
    List all created buckets Failed
    Upload objects without a prefix, test.txt Failed
    Download objects without a prefix, test.txt Failed
    Upload objects with a prefix, user1/test.txt Failed
    Download objects with a prefix, user1/test.txt Successful
    List all objects, test.txt Successful
    List objects with a prefix, user1/test.txt Successful
  • Write-only policies with no specified prefixes

    This policy indicates that the app can upload all objects in the bucket app-base-oss.

    1. ```json
    2. {
    3. "Statement": [
    4. {
    5. "Action": [
    6. "oss:PutObject"
    7. ],
    8. "Effect": "Allow",
    9. "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"]
    10. }
    11. ],
    12. "Version": "1"
    13. }
    14. ```
    Operations on OSS upon retrieving STS token Result
    List all created buckets Failed
    Upload objects without a prefix, test.txt Successful
    Download objects without a prefix, test.txt Failed
    Upload objects with a prefix, user1/test.txt Successful
    Download objects with a prefix, user1/test.txt Successful
    List all objects, test.txt Successful
    List objects with a prefix, user1/test.txt Successful
  • Write-only policies with a specified prefix

    This policy indicates that the app can upload all objects with the user1/ prefix in the bucket app-base-oss. The app cannot upload any object with another prefix. In this way, different apps corresponding to different prefixes are spatially isolated in the bucket.

    1. ```json
    2. {
    3. "Statement": [
    4. {
    5. "Action": [
    6. "oss:PutObject"
    7. ],
    8. "Effect": "Allow",
    9. "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"]
    10. }
    11. ],
    12. "Version": "1"
    13. }
    14. ```
    Operations on OSS upon retrieving STS token Result
    List all created buckets Failed
    Upload objects without a prefix, test.txt Failed
    Download objects without a prefix, test.txt Failed
    Upload objects with a prefix, user1/test.txt Failed
    Download objects with a prefix, user1/test.txt Successful
    List all objects, test.txt Failed
    List objects with a prefix, user1/test.txt Failed
  • Read/write policies with or without any prefixes

    This policy indicates that the app can list, download, upload, and delete all objects in the bucket app-base-oss.

    1. ```json
    2. {
    3. "Statement": [
    4. {
    5. "Action": [
    6. "oss:GetObject",
    7. "oss:PutObject",
    8. "oss:DeleteObject",
    9. "oss:ListParts",
    10. "oss:AbortMultipartUpload",
    11. "oss:ListObjects"
    12. ],
    13. "Effect": "Allow",
    14. "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"]
    15. }
    16. ],
    17. "Version": "1"
    18. }
    19. ```
    Operations on OSS upon retrieving STS token Result
    List all created buckets Failed
    Upload objects without a prefix, test.txt Successful Successful
    Download objects without a prefix, test.txt Successful
    Upload objects with a prefix, user1/test.txt Successful
    Download objects with a prefix, user1/test.txt Successful
    List all objects, test.txt Successful
    List objects with a prefix, user1/test.txt Successful
  • Read/write policies with a specified prefix

    This policy indicates that the app can list, download, upload, and delete all objects with a prefix of user1/ in the bucket app-base-oss. The policy does not specify to read or write any objects with another prefix. In this way, different apps corresponding to different prefixes are spatially isolated in the bucket.

    1. {
    2. "Statement": [
    3. {
    4. "Action": [
    5. "oss:GetObject",
    6. "oss:PutObject",
    7. "oss:DeleteObject",
    8. "oss:ListParts",
    9. "oss:AbortMultipartUpload",
    10. "oss:ListObjects"
    11. ],
    12. "Effect": "Allow",
    13. "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"]
    14. }
    15. ],
    16. "Version": "1"
    17. }
    Operations on OSS upon retrieving STS token Result
    List all created buckets Failed
    Upload objects without a prefix, test.txt Failed
    Download objects without a prefix, test.txt Failed
    Upload objects with a prefix, user1/test.txt Successful
    Download objects with a prefix, user1/test.txt Successful
    List all objects, test.txt Successful
    List objects with a prefix, user1/test.txt Successful

Summary

The preceding examples show that:

  • You can create different policies for different app scenarios and then achieve differentiated permission control for different apps through slight modifications on the app server.

  • You can also optimize apps to save the process of making another request to the app server before the STS token expires.

  • Tokens are actually issued by the STS. An app server customizes a policy, requests for a token from the STS, and then delivers this token to the app. Here, token is just the shorthand. A “token” actually contains an “AccessKeyId”, an “AccessKeySecret”, an “Expiration” value, and a “SecurityToken”. These are used in the SDK provided by OSS to the app. For details, see the implementation of the respective SDK.

More references

Thank you! We've received your feedback.