本文主要介绍如何基于STS Policy的使用规则进行权限控制。
本文基于
快速搭建移动应用直传服务中提到的应用服务器，以上海的Bucket app-base-oss 为例，讲解如何配置不同的Policy实现不同的权限控制。
说明
- 本文提到的 Policy 是指快速搭建移动应用直传服务提到的config.json中指定的Policy文件内容。
- 以下讲述的获取STS Token 后对OSS的操作是指为应用服务器指定Policy。从STS获取临时凭证后，应用通过临时凭证访问OSS。
常见Policy
- 完全授权的Policy
完全授权的Policy表示允许应用可以对OSS进行任何操作。
警告 完全授权的Policy对移动应用来说是不安全的授权，不推荐使用。{ "Statement": [ { "Action": [ "oss:*" ], "Effect": "Allow", "Resource": ["acs:oss:*:*:*"] } ], "Version": "1" }获取STS Token后对OSS的操作 结果 列举所有创建的Bucket 成功 上传不带前缀的Object，test.txt 成功 下载不带前缀的Object，test.txt 成功 上传带前缀的Object，user1/test.txt 成功 下载带前缀的Object，user1/test.txt 成功 列举Object，test.txt 成功 带前缀的Object，user1/test.txt 成功 - 不限制前缀的只读不写Policy
此Policy表示应用对Bucket
app-base-oss下所有的Object可列举，可下载。{ "Statement": [ { "Action": [ "oss:GetObject", "oss:ListObjects" ], "Effect": "Allow", "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"] } ], "Version": "1" }获取STS Token后对OSS的操作 结果 列举所有创建的Bucket 失败 上传不带前缀的Object，test.txt 失败 下载不带前缀的Object，test.txt 成功 上传带前缀的Object，user1/test.txt 失败 下载带前缀的Object，user1/test.txt 成功 列举不带前缀的Object，test.txt 成功 列举带前缀的Object，user1/test.txt 成功 - 限制前缀的只读不写Policy
此Policy表示应用对Bucket
app-base-oss下带有前缀user1/的Object可列举、可下载，但无法下载其他前缀的Object。采用此种Policy，如果不同的应用对应不同的前缀，就可以达到在同一个Bucket中空间隔离的效果。{ "Statement": [ { "Action": [ "oss:GetObject", "oss:ListObjects" ], "Effect": "Allow", "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"] } ], "Version": "1" }获取STS Token后对OSS的操作 结果 列举所有创建的Bucket 失败 上传不带前缀的Object，test.txt 失败 下载不带前缀的Object，test.txt 失败 上传带前缀的Object，user1/test.txt 失败 下载带前缀的Object，user1/test.txt 成功 列举Object，test.txt 成功 带前缀的Object，user1/test.txt 成功 - 不限制前缀的只写不读Policy
此Policy表示应用可以对Bucket
app-base-oss下所有的Object进行上传。{ "Statement": [ { "Action": [ "oss:PutObject" ], "Effect": "Allow", "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"] } ], "Version": "1" }获取STS Token后对OSS操作 结果 列举所有创建的Bucket 失败 上传不带前缀的Object，test.txt 成功 下载不带前缀的Object，test.txt 失败 上传带前缀的Object，user1/test.txt 成功 下载带前缀的Object，user1/test.txt 成功 列举Object，test.txt 成功 带前缀的Object，user1/test.txt 成功 - 限制前缀的只写不读Policy
此Policy表示应用可以对Bucket
app-base-oss下带有前缀user1/的Object进行上传。但无法上传其他前缀的Object。采用此种Policy，如果不同的应用对应不同的前缀，就可以达到在同一个Bucket中空间隔离的效果。{ "Statement": [ { "Action": [ "oss:PutObject" ], "Effect": "Allow", "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"] } ], "Version": "1" }获取STS Token后对OSS的操作 结果 列举所有创建的Bucket 失败 上传不带前缀的Object，test.txt 失败 下载不带前缀的Object，test.txt 失败 上传带前缀的Object，user1/test.txt 成功 下载带前缀的Object，user1/test.txt 失败 列举Object，test.txt 失败 带前缀的Object，user1/test.txt 失败 - 不限制前缀的读写Policy
此Policy表示应用可以对Bucket
app-base-oss下所有的Object进行列举、下载、上传和删除。{ "Statement": [ { "Action": [ "oss:GetObject", "oss:PutObject", "oss:DeleteObject", "oss:ListParts", "oss:AbortMultipartUpload", "oss:ListObjects" ], "Effect": "Allow", "Resource": ["acs:oss:*:*:app-base-oss/*", "acs:oss:*:*:app-base-oss"] } ], "Version": "1" }获取STS Token后对OSS的操作 结果 列举所有创建的Bucket 失败 上传不带前缀的Object，test.txt 成功 下载不带前缀的Object，test.txt 成功 上传带前缀的Object，user1/test.txt 成功 下载带前缀的Object，user1/test.txt 成功 列举Object，test.txt 成功 带前缀的Object，user1/test.txt 成功 - 限制前缀的读写Policy
此Policy表示应用可以对Bucket
app-base-oss下带有前缀user1/的Object进行列举、下载、上传和删除，但无法对其他前缀的Object进行读写。采用此种Policy，如果不同的应用对应不同的前缀，就可以达到在同一个Bucket中空间隔离的效果。{ "Statement": [ { "Action": [ "oss:GetObject", "oss:PutObject", "oss:DeleteObject", "oss:ListParts", "oss:AbortMultipartUpload", "oss:ListObjects" ], "Effect": "Allow", "Resource": ["acs:oss:*:*:app-base-oss/user1/*", "acs:oss:*:*:app-base-oss"] } ], "Version": "1" }获取STS Token后对OSS的操作 结果 列举所有创建的Bucket 失败 上传不带前缀的Object，test.txt 失败 下载不带前缀的Object，test.txt 失败 上传带前缀的Object，user1/test.txt 成功 下载带前缀的Object，user1/test.txt 成功 列举Object，test.txt 成功 带前缀的Object，user1/test.txt 成功
总结
从上面的例子可以看出：
- 可以根据不同的应用场景制定不同的Policy，然后对应用服务器稍作修改就可以实现对不同的用户实现不同的权限控制。
- 可以在应用端做优化，使得STS Token过期之前不需要向应用服务器再次请求。
- Token由STS颁发。应用服务器只是定制了Policy，向STS请求Token，然后将Token转发给应用。这里的Token包含了AccessKeyId、AccessKeySecret、Expiration、SecurityToken，这些参数在OSS提供给应用的SDK中会用到。详情请参见各语言SDK参考中的授权访问章节。