STS temporary access authorization

Last Updated: Mar 19, 2018

In the previous documents, we used only the RAM user functions. These user accounts are for long-term normal use. This poses as a serious risk if the RAM user permissions cannot be promptly revoked in case of information leakage.

In the previous example, assume that our developer’s app allows users to upload data to the OSS bucket am-test-app and currently, the number of app users is large. In this case, how can the app securely grant data upload permissions to many users and how can it be certain of storage isolation among multiple users?

In such scenarios, we need to grant users temporary access using STS. STS can be used to specify a complex policy that restricts specified users by only granting them the minimum necessary permissions.

Create a role

The basic concept of a role is explained in previous documents. The following is the actual example provided by using the role.

Based on the example in the previous document, the app user has a bucket, ram-test-app, to store personal data. A role can be created as follows:

Create a RAM user account named ram_test_app using the process illustrated in the previous documents. Do not grant this account any permissions, because it inherits the permissions of a role which it assumes.

Create roles. Here you must create two roles for users to perform read operations and to upload files respectively.

Enter the role type information, because this role has been used by its own Alibaba Cloud account. Use the default setting.

Configure basic role information.

When the role was created, it did not have any permissions. Therefore, we must create a custom authorization policy using the process described earlier. The following is the authorization policy:

{

"Version":"1",

"Statement":[

{

"Effect":"Allow",

"Action":[

"oss:ListObjects",

"oss:GetObject"

],

"Resource":[

"acs:oss:*:*:ram-test-app",

"acs:oss:*:*:ram-test-app/*"

]

}

]

}

This indicates read-only permission for ram-test-app.

After the policy is established, give the role RamTestAppReadOnly the ram-test-app read-only permission on the role management page.

Perform the same procedure to create the role RamTestAppWrite and use a custom authorization policy to grant ram-test-app write permission. The authorization policy is as follows:

{

"Version":"1",

"Statement":[

{

"Effect":"Allow",

"Action":[

"oss:DeleteObject",

"oss:ListParts",

"oss:AbortMultipartUpload",

"oss:PutObject"

],

"Resource":[

"acs:oss:*:*:ram-test-app",

"acs:oss:*:*:ram-test-app/*"

]

}

]

}

Now we have created two roles, RamTestAppReadOnly and RamTestAppWrite, with read-only and write permissions for ram-test-app, respectively.

Temporary access authorization

After creating roles, we can use them to grant temporary access to OSS.

Preparation

Authorization is required for assuming roles. Otherwise, any RAM user could assume these roles, which can lead to unpredictable risks. Therefore, to assume corresponding roles, a RAM user needs to have explicitly configured permissions.

RoleArn: indicates the ID of a role to be assumed. Role IDs can be found in Roles > Role Details.

RoleSessionName: indicates the name of the temporary credentials. Generally, we recommend that you separate this using different application users.

Policy: indicates a permission restriction, which is added when the role is assumed.

DurationSeconds: indicate the validity time of the temporary credentials in seconds. The minimum value is 900, and the maximum value is 3600.

id and secret: indicate the AccessKey of the RAM user to assume a role.

Here, we need to explain what is meant by “Policy”. The policy mentioned here is used to restrict the temporary credential permissions after a role is assumed. Ultimately, the permissions obtained by means of temporary credentials are overlapping permissions of the role and the policy passed in.

When a role is assumed, a policy can be entered to increase the flexibility. For example, when uploading the files, we can add different upload path restrictions for different users. This is shown in the following example.

Now, let’s test the STS function. To test the bucket, first use the console to put the file test.txt in ram-test-app, with the content ststest.

First, use the RAM user account ram_test_app to directly access the file. Next, replace AccessKey with your own AccessKey used in the test.

Here, a problem occurs. The test.txt upload fails. We have formatted the entered policy discussed at the beginning of this document, which is as follows:

{

"Version":"1",

"Statement":[

{

"Effect":"Allow",

"Action":[

"oss:PutObject"

],

"Resource":[

"acs:oss:*:*:ram-test-app/usr001/*"

]

}

]

}

This policy indicates that users are only allowed to upload files like usr001/ to the ram-test-app bucket. If the app user is usr002, the policy can be changed to only allow for the uploading of files like usr002/. By setting different policies for different app users, we can isolate the storage space of different app users.

Retry the test and specify the upload destination as ram-test-app/usr001/test.txt.

Summary

This document describes how to grant users temporary access authorization for OSS using STS. In typical mobile development scenarios, STS can be used to grant temporary authorizations to access OSS when different app users need to access the app.

The temporary authorization can be configured with expiration time to greatly reduce the hazards caused by leakages. When obtaining temporary authorization, we can enter different authorization policies for different app users to restrict their access permissions. For example, to restrict the object paths accessible to users. This isolates the storage space of different app users.