Permission control

Last Updated: Nov 07, 2017

This document elaborates how to configure different policies to implement different permission controls 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.

Note:

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

  • The policies mentioned in the following content 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 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 OSS.

Common policies

  • Full authorization policy

    For the ease of demonstration, the default policy is shown as follows. This policy indicates that the app is allowed to perform any operation on OSS. This policy is neither secured nor recommended to use for mobile apps.

    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 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. ```
  16. <table>
  17. <tbady>
  18. <tr>
  19. <th>Operations on OSS upon retrieving STS token</th>
  20. <th>Result</th>
  21. </tr>
  22. <tr>
  23. <td>List all created buckets.</td>
  24. <td>Failed</td>
  25. </tr>
  26. <tr>
  27. <td>Upload objects without a prefix, test.txt.</td>
  28. <td>Failed</td>
  29. </tr><tr>
  30. <td>Download objects without a prefix, test.txt.</td>
  31. <td>Failed</td>
  32. </tr><tr>
  33. <td>Upload objects with a prefix, user1/test.txt.</td>
  34. <td>Failed</td>
  35. </tr><tr>
  36. <td>Download objects with a prefix, user1/test.txt.</td>
  37. <td>Failed</td>
  38. </tr><tr>
  39. <td>List all objects, test.txt.</td>
  40. <td>Failed</td>
  41. </tr><tr>
  42. <td>List objects with a prefix, user1/test.txt.</td>
  43. <td>Failed</td>
  44. </tr>
  45. </tbady>
  46. </table>
  • Read-only policies with a specified prefix

    This policy indicates the app can list and download all objects with the prefix of user1/ in the bucket app-base-oss. However, the policy does not specify to download any objects with another prefix. By 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 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
    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 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

With the help of preceding examples, we can understand that:

  • You can create different policies for various 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 only a shorthand expression. However, 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 more information, see the implementation of the respective SDK.

More references:

Thank you! We've received your feedback.