Use RAM roles to control temporary authorization access

Last Updated: Sep 15, 2017

Assume that an enterprise A has developed a mobile app and has bought OSS for it. The mobile app must upload and download data to and from OSS. Because the mobile app runs on user devices, these devices are out of A’s control.

  • Enterprise A does not want to allow all apps to use the AppServer to transmit data. Instead, enterprise A wants the apps to directly upload and download data to and from OSS.

  • For security reasons, enterprise A cannot save the AccessKey in the app.

  • Enterprise A also wants to minimize its security risks by, for example, giving each app an access token with the minimum permissions that the app needs to connect to OSS and restricting the access duration to a specified period of time (such as 30 minutes).

Requirements

  • The mobile app needs to directly transmit data to OSS, without using a data proxy.

  • Enterprise A cannot give an AccessKey to the mobile app because the mobile devices are under the control of A’s users.

  • The access permissions of each mobile app must be restricted to OSS object granularity.

Solution: Use RAM STS-Tokens

1. Create a role, a user and grant the necessary permissions

Step 1. Enterprise A creates a role.

  1. A logs on to the RAM console and goes to Roles > Create Role.

  2. In the Create Role window, A selects Current Alibaba Cloud Account as the trusted account to assume this role and enters “oss-readonly” as the role name.

    After creating the role, A can view the basic role information on the role details page. For example, the global name ARN of the role is:

    1. acs:ram::11223344:role/oss-readonly

    The policy of the role is (only Enterprise A can assume this role):

    1. {
    2. "Statement": [
    3. {
    4. "Action": "sts:AssumeRole",
    5. "Effect": "Allow",
    6. "Principal": {
    7. "RAM": [
    8. "acs:ram::11223344:root"
    9. ]
    10. }
    11. }
    12. ],
    13. "Version": "1"
    14. }

Step 2: Enterprise A grants permissions to the role by attaching a suitable authorization policy to it.

After creating a role as described in the previous step, A follows the dialog box to attach authorization policies to the role. Or A goes to the role details page and then clicks Edit Authorization Policy to attach authorization policies to the role.

In the authorization window, A adds the system authorization policy AliyunOSSReadOnlyAccess, and then click OK.

Step 3: Enterprise A creates a RAM-User for the AppServer and authorizes this user to assume the newly created role.

  1. A logs on to the RAM console and goes to Users > Create User.

  2. In the Create User window, A specifies a username such as “appserver” and checks the Automatically generate an AccessKey for this user box to create an AccessKey.

  3. In the user list, A clicks the just created user to open the User Details page and then clicks User Authentication Policies > Edit Authentication Policy.

  4. In the Edit Individual Authorization Policy window, A adds the system authorization policy AliyunSTSAssumeRoleAccess for this user, and then clicks OK.

2. AppServer issues STS-Tokens for resource access

RAM-Role Identity Access

Step 1: The AppServer uses the RAM-User appserver’s AccessKey to call the STS AssumeRole API.

For example, the AppServer uses aliyuncli to call AssumeRole.

Note: An AccessKey must be configured for appserver. The appserver is not allowed to use the AccessKey of A (that is, the primary account).

  1. $ aliyuncli sts AssumeRole --RoleArn acs:ram::11223344:role/oss-readonly --RoleSessionName client-001
  2. {
  3. "AssumedRoleUser": {
  4. "AssumedRoleId": "391578752573972854:client-001",
  5. "Arn": "acs:ram::11223344:role/oss-readonly/client-001"
  6. },
  7. "Credentials": {
  8. "AccessKeySecret": "93ci2umK1QKNEja6WGqi1Ba7Q2Fv9PwxZqtVF2VynUvz",
  9. "SecurityToken": "CAES6AIIARKAAUiwSHpkD3GXRMQk9stDr3YSVbyGqanqkS+fPlEEkjZ+dlgFnGdCI2PV93jksole8ijH8dHJrHRA5JA1YCGsfX5hrzcNM37Vr4eVdWFVQhoCw0DXBpHv//ZcITp+ELRr4MHsnyGiErnDsXLkI7q/sbuWg6PACZ/jzQfEWQb/f7Y1Gh1TVFMuRjEzR2pza1hUamszOGRCWTZZeEp0WEFaayISMzkxNTc4NzUyNTczOTcyODU0KgpjbGllbnQtMDAxMKT+lIHBKjoGUnNhTUQ1QkoKATEaRQoFQWxsb3cSGwoMQWN0aW9uRXF1YWxzEgZBY3Rpb24aAwoBKhIfCg5SZXNvdXJjZUVxdWFscxIIUmVzb3VyY2UaAwoBKkoFNDMyNzRSBTI2ODQyWg9Bc3N1bWVkUm9sZVVzZXJgAGoSMzkxNTc4NzUyNTczOTcyODU0cgllY3MtYWRtaW544Mbewo/26AE=",
  10. "Expiration": "2016-01-13T15:02:37Z",
  11. "AccessKeyId": "STS.F13GjskXTjk38dBY6YxJtXAZk"
  12. },
  13. "RequestId": "E1779AAB-E7AF-47D6-A9A4-53128708B6CE"
  14. }
Restrict the STS-Token permissions

If no policy parameters are specified during calling the AssumeRole API, this STS-Token has all oss-readonly permissions.

If you need to restrict the permissions of the STS-Token, for example, to only allow access to sample-bucket/2015/01/01/*.jpg, you can use the policy parameters to further restrict the STS-Token’s permissions.

For example,

  1. $ aliyuncli sts AssumeRole --RoleArn acs:ram::11223344:role/oss-readonly --RoleSessionName client-002 --Policy "{\"Version\":\"1\", \"Statement\": [{\"Effect\":\"Allow\", \"Action\":\"oss:GetObject\", \"Resource\":\"acs:oss:*:*:sample-bucket/2015/01/01/*.jpg\"}]}"
  2. {
  3. "AssumedRoleUser": {
  4. "AssumedRoleId": "391578752573972854:client-002",
  5. "Arn": "acs:ram::11223344:role/oss-readonly/client-002"
  6. },
  7. "Credentials": {
  8. "AccessKeySecret": "28Co5Vyx2XhtTqj3RJgdud4ntyzrSNdUvNygAj7xEMow",
  9. "SecurityToken": "CAESnQMIARKAASJgnzMzlXVyJn4KI+FsysaIpTGm8ns8Y74HVEj0pOevO8ZWXrnnkz4a4rBEPBAdFkh3197GUsprujsiU78FkszxhnQPKkQKcyvPihoXqKvuukrQ/Uoudk31KAJEz5o2EjlNUREcxWjRDRSISMzkxNTc4NzUyNTczOTcyODU0KgpjbGllbnQtMDAxMKmZxIHBKjoGUnNhTUQ1Qn8KATEaegoFQWxsb3cSJwoMQWN0aW9uRXF1YWxzEgZBY3Rpb24aDwoNb3NzOkdldE9iamVjdBJICg5SZXNvdXJjZUVxdWFscxIIUmVzb3VyY2UaLAoqYWNzOm9zczoqOio6c2FtcGxlLWJ1Y2tldC8yMDE1LzAxLzAxLyouanBnSgU0MzI3NFIFMjY4NDJaD0Fzc3VtZWRSb2xlVXNlcmAAahIzOTE1Nzg3NTI1NzM5NzI4NTRyCWVjcy1hZG1pbnjgxt7Cj/boAQ==",
  10. "Expiration": "2016-01-13T15:03:39Z",
  11. "AccessKeyId": "STS.FJ6EMcS1JLZgAcBJSTDG1Z4CE"
  12. },
  13. "RequestId": "98835D9B-86E5-4BB5-A6DF-9D3156ABA567"
  14. }

Additionally, the default validity period of the preceding STS-Token is 3600 seconds. You can use the DurationSeconds parameter to limit the STS-Token expiration time (the expiration time cannot exceed 3600 seconds).

Step 2: The AppServer retrieves and parses the credentials.

The AppServer retrieves the AccessKeyId, AccessKeySecret and SecurityToken from the credentials returned by the AssumeRole API.

Because the STS-Token validity period is relatively short, if the application requires a longer validity period, AppServer must re-issue a new STS-Token (for example, issue one STS-Token every other 1800 seconds).

Step 3: The AppServer securely transmits an STS-Token to the AppClient.

Step 4: The AppClient uses the STS-Token to directly access a cloud service API (such as OSS).

The operation commands for aliyuncli to use an STS-Token to access an OSS object are as follows (a STS-Token is issued to client-002):

  1. Configure STS-Token syntax: aliyuncli oss Config --host <OssEndPoint> --accessid <AccessKeyId> --accesskey <AccessKeySecret> --sts_token <SecurityToken>
  2. $ aliyuncli oss Config --host oss.aliyuncs.com --accessid STS.FJ6EMcS1JLZgAcBJSTDG1Z4CE --accesskey 28Co5Vyx2XhtTqj3RJgdud4ntyzrSNdUvNygAj7xEMow --sts_token CAESnQMIARKAASJgnzMzlXVyJn4KI+FsysaIpTGm8ns8Y74HVEj0pOevO8ZWXrnnkz4a4rBEPBAdFkh3197GUsprujsiU78FkszxhnQPKkQKcyvPihoXqKvuukrQ/Uoudk31KAJEz5o2EjlNUREcxWjRDRSISMzkxNTc4NzUyNTczOTcyODU0KgpjbGllbnQtMDAxMKmZxIHBKjoGUnNhTUQ1Qn8KATEaegoFQWxsb3cSJwoMQWN0aW9uRXF1YWxzEgZBY3Rpb24aDwoNb3NzOkdldE9iamVjdBJICg5SZXNvdXJjZUVxdWFscxIIUmVzb3VyY2UaLAoqYWNzOm9zczoqOio6c2FtcGxlLWJ1Y2tldC8yMDE1LzAxLzAxLyouanBnSgU0MzI3NFIFMjY4NDJaD0Fzc3VtZWRSb2xlVXNlcmAAahIzOTE1Nzg3NTI1NzM5NzI4NTRyCWVjcy1hZG1pbnjgxt7Cj/boAQ==
  3. Access OSS object
  4. $ aliyuncli oss Get oss://sample-bucket/2015/01/01/grass.jpg grass.jpg

More references

More references to mobile app access include:

Thank you! We've received your feedback.