归档存储通过使用AccessKeyID/AccessKeySecret对称加密的方法来验证某个请求的发送者身份。AccessKeyID用于标识用户,AccessKeySecret是用户用于加密签名字符串和归档存储用来验证签名字符串的密钥,请勿将其泄露给第三方。每个AccessKey对(AccessKeyID和AccessKeySecret)有两种状态,分别为active和inactive。

背景信息

  • active表明用户可以用此AccessKey对签名验证请求
  • inactive表明用户暂停此AccessKey对签名验证的功能

当用户向归档存储发送请求时,需要首先将发送的请求按照归档存储指定的格式生成签名字符串;然后使用AccessKeySecret对签名字符串进行加密产生验证码。归档存储收到请求以后,会通过AccessKeyID找到对应的AccessKeySecret,以同样的方法提取签名字符串和验证码,如果计算出来的验证码和提供的一样即认为该请求是有效的;否则,归档存储将拒绝处理这次请求,并返回HTTP 403错误。

用户签名计算方法

用户需要在HTTP请求中增加Authorization(授权)的HTTP头部字段来包含Signature(签名)信息,表明这个消息已被授权。

Authorization字段计算方法

"Authorization: OAS " + [ Access Key Id ] + ":" + Signature
Signature = base64(hmac-sha1(VERB + "\n"
                           + DATE + "\n"
                           + CanonicalizedOASHeaders
                           + CanonicalizedResource))
  • VERB表示HTTP方法,如GET/POST

  • DATE表示此次操作的时间,必须为HTTP/1.1中支持的GMT格式

  • CanonicalizedOASHeaders表示所有前缀为”x-oas-“的HTTPHeader

  • CanonicalizedResource表示用户想要访问的归档存储资源,即URI

其中,DATE和CanonicalizedResource不能为空;如果请求中的DATE时间和归档存储的服务器时间差正负15分钟以上,归档存储将拒绝该请求,并返回HTTP 403错误。

构建CanonicalizedOASHeaders的方法

所有以”x-oas-“为前缀的HTTP Header被称为CanonicalizedOASHeaders,它的构建方法如下:

操作步骤

  1. 将所有以”x-oas-“为前缀的HTTP请求头的名字转换成小写字母。如”X-OASPart-Size: 67108864”转换成”x-oas-part-size: 67108864”。
  2. 将上一步得到的所有HTTP请求头按照字典序进行升序排列。
  3. 删除请求头和内容之间分隔符两端出现的任何空格。如”x-oas-part-size: 67108864”转换成”x-oas-part-size:67108864”。
  4. 将所有的头和内容用”\n”分隔符分隔拼成最后的CanonicalizedOASHeader。

执行结果

构建CanonicalizedResource的方法

用户发送请求中想访问的归档存储目标资源被称为CanonicalizedResource。它的构建方法如下:

  1. 将CanonicalizedResource置成空字符串(””)。

  2. 放入要访问的归档存储资源,如:”/vaults/[ VaultId ]” 。

  3. 如果请求的资源包括子资源(sub-resource),将所有的子资源按照字典序,从小到大排列,以”&”为分隔符生成子资源字符串。在CanonicalizedResource字符串尾添加”?”和子资源字符串。如:/vaults/[ VaultId ]/multipart-uploads。

  4. 如果请求含参数,将参数及值按照字典序,从小到大排列,以”&”为分隔符,添加到CanonicalizedResource中。如:/vaults/[ VaultId ]/multipartuploads?limit=1&marker=30DF64484BD34B4C44BB261A02DF89BA。参数值为空的时候,请不要传递此参数。如marker为空串(””)时,参数列表中不要包含该参数。

用户签名示例

Access Key ID:ckdwpp7o2l2rhxf3d5j7dzzm

Access Key Secret:gUWY5b687iv0d+LJLHRJW1PzhZY=

待签名内容如下:

GET /vaults/[ VaultId ]/multipart-uploads HTTP/1.1
Date: Wed, 16 Apr 2014 05:51:14 GMT
Host: cn-hangzhou.oas.aliyuncs.com
import base64
import hmac
import sha
h = hmac.new("gUWY5b687iv0d+LJLHRJW1PzhZY=",
             "GET\nWed, 16 Apr 2014 05:51:14 GMT\n/vaults/30DF64484BD34B4C44BB261A02DF89BA/multipart-uploads",
             sha)
base64.encodestring(h.digest()).strip()

签名计算结果为”dZpCvvKgxiFw6wvMHHj5g3W6STM=”,加上其他信息组成Authorization字段:

GET /vaults/30DF64484BD34B4C44BB261A02DF89BA/multipart-uploads HTTP/1.1
Host: cn-hangzhou.oas.aliyuncs.com
Date: Wed, 16 Apr 2014 05:51:14 GMT
Authorization: OAS ckdwpp7o2l2rhxf3d5j7dzzm:dZpCvvKgxiFw6wvMHHj5g3W6STM=

在计算签名的时候请遵循如下规则:

  1. 用来签名的字符串必须为UTF-8格式。含有中文字符的签名字符串必须先进行UTF-8编码,再与Access Key Secret计算最终签名。

  2. 签名的方法用RFC 2104中定义的HMAC-SHA1方法,其中Key为Access Key Secret。

  3. 在所有非HTTP标准定义的Header中,只有以”x-oas-“开头的Header,需要加入签名字符串;其他非HTTP标准Header将被归档存储忽略。

  4. 以”x-oas-“开头的Header在签名验证前需要符合以下规范:

    a. Header的名字需要变成小写。

    b. Header按字典序自小到大排序。

    c. 分割Header Name和Value的冒号前后不能有空格。

    d. 每个Header之后都有一个换行符”\n”。

    e. 如果没有符合要求的Header,CanonicalizedOASHeaders应置为空。

异常说明

  1. 传入的Access Key ID不存在或inactive,返回 403 Forbidden。错误码:InvalidAccessKeyId。

  2. Authorization字段值格式不对,返回 400 Bad Request。错误码:InvalidArgument。

  3. 没有传入Date或者格式不正确,返回 403 Forbidden错误。错误码:AccessDenied。

  4. 传入的Date必须在归档存储的服务器当前时间前后15分钟以内,否则返回 403 Forbidden,错误码:RequestTimeTooSkewed。