Batch Compute:Signature

Batch Compute verifies the identity of a request sender by using the AccessKeyID/AccessKeySecret symmetric encryption method. The AccessKeyID identifies a user, whereas the AccessKeySecret is a key used by a user to encrypt the signature string and by Batch Compute to verify the signature string. The AccessKeySecret must be kept confidential and is only known by the user and Batch Compute.

Before sending a request to Batch Compute using a personal identity, a user must generate a signature string for the request according to the format specified by Batch Compute and then encrypt the signature string by using the AccessKeySecret to generate a verification code. After receiving the request, the Batch Compute finds the corresponding AccessKeySecret based on the AccessKey ID, and obtains the signature string and verification code in the same way. If the obtained verification code is the same as the provided verification code, the request is assumed valid. If not, Batch Compute rejects the request and returns an HTTP 400 error.

A user can add an Authorization header to carry the signature information in an HTTP request, indicating that the message has been authorized.

The Authorization field is calculated as follows:

Authorization: "acs " + AccessKeyId + ":" + Signature

Signature = base64(hmac-sha1(AccessKeySecret + "\n",
            + VERB + "\n" 
            + ACCEPT + "\n"
            + CONTENT-MD5 + "\n" 
            + CONTENT-TYPE + "\n" 
            + DATE + "\n" 
            + CanonicalizedBatchComputeHeaders
            + CanonicalizedResource))

• AccessKeySecret indicates the key required for the signature.

• VERB indicates an HTTP request method in uppercase, including PUT, GET, POST, HEAD, DELETE, and so on.

• CONTENT-MD5 indicates the MD5 value of the requested content. For more information, see (Hexadecimal sequence, in lowercase).

• ACCEPT indicates that the accept type expected by the HTTP request.

• CONTENT-TYPE indicates the type of the request content.

• DATE indicates the operation time, and must be in the GMT format supported in HTTP1.1.

• CanonicalizedBatchComputeHeaders indicates a combination of HTTP headers with prefix “x-acs-“.

• CanonicalizedResource indicates the Batch Compute resource that the API wants to access.

CanonicalizedBatchComputeHeaders indicates the object meta combination in HTTP. CanonicalizedResource indicates the Batch Compute resource that the API wants to access. Date and CanonicalizedResource cannot be empty. If Date in the request differs from the Batch Compute server time by 15 minutes or more, the Batch Compute server denies the service and return an HTTP 400 error. For other fields, see the description about parameters of the public request headers.

Method for constructing CanonicalizedBatchComputeHeaders:

All the HTTP headers starting with “x-acs-“ are called CanonicalizedBatchComputeHeaders. CanonicalizedBatchComputeHeaders is constructed as follows:

1. Lowercase the names of all HTTP request headers starting with “x-acs-“. For example, convert “X-Acs-Meta-Name: TaoBao” into “x-acs-meta-name: TaoBao”.

2. Sort all HTTP request headers obtained in the previous step in alphabetical order.

3. Combine request headers with the same name according to chapter 4.2 in RFC 2616, and separate two adjacent values by a comma (,). For example, combine the request headers “x-acs-meta-name: TaoBao” and “x-acs-meta-name: Alipay” into “x-acs-meta-name:TaoBao,Alipay”.

4. Delete all space on both sides of a separator between each request header and content. For example, convert “x-acs-meta-name: TaoBao,Alipay” to “x-acs-meta-name:TaoBao,Alipay”.

5. Separate all the headers and content using the separator “\n” to get the final CanonicalizedBatchComputeHeader.

Method for constructing CanonicalizedResource:

The target Batch Compute resource specified in the request sent by a user is called CanonicalizedResource. CanonicalizedResource is constructed as follows:

1. Set CanonicalizedResource to a blank string “”.

2. Enter the Batch Compute resource to be accessed, for example, “/ResourceName/ResourceId”. The field is left unspecified if no ResourceId exists.

3. If the requested resource includes sub-resources, sort all the sub-resources in alphabetical order and separate the sub-resources using the separator “&” to generate a sub-resource string. Add “?” and the sub-resource string to the end of the CanonicalizedResource string. In this way, CanonicalizedResource is constructed, for example, “/jobs/(id)/tasks?Marker=(Marer)&MaxItemCount=(MaxItemCount)”.

For example, to add the following signature information:

PUT /jobs/job-000000005645B53B0000AEA300000001 HTTP/1.0
Content-Md5: 900150983cd24fb0d6963f7d28e17f72
Content-Type: application/json
Date: Thu, 17 Nov 2005 18:49:58 GMT
Host: batchcompute.cn-qingdao.aliyuncs.com
x-acs-signature-method: HMAC-SHA1
x-acs-signature-version: 1.0

Assume that the AccessKeyID is “44CF******” and the AccessKeySecret is “Otxr******”. Follow these steps to add a signature:

Python sample code:

import base64
import hmac
import sha
h = hmac.new("Otxr******",
             "PUT\n900150983cd24fb0d6963f7d28e17f72\napplication/json\nThu, 17 Nov 2005 18:49:58 GMT\nx-acs-signature-method:HMAC-SHA1\nx-acs-signature-version:1.0\n/jobs/job-000000005645B53B0000AEA300000001", sha)
base64.encodestring(h.digest()).strip()

The signature calculation result is “26NBxoKdsyly4EDv6inkoDft/yA=”, which, together with the Authorization header, constitutes the final message that needs to be sent.

PUT /jobs/job-000000005645B53B0000AEA300000001 HTTP/1.0
Authorization: acs 44CF******: 26NBxoKdsyly4EDv6inkoDft/yA=
Content-Md5: 900150983cd24fb0d6963f7d28e17f72
Content-Type: application/json
Date: Thu, 17 Nov 2005 18:49:58 GMT
Host: batchcompute.cn-qingdao.aliyuncs.com
x-acs-signature-method: HMAC-SHA1
x-acs-signature-version: 1.0

Observe the following rules when calculating the signature header:

1. The string used for signature must be in UTF-8 format. A signature string containing Chinese characters must undergo UTF-8 encoding, and is then used together with AccessKeySecret to calculate the final signature.

2. The signing method adopted is the HMAC-SHA1 method defined in RFC 2104, where Key is the AccessKeySecret.

3. Content-Type and Content-MD5 are not required in a request. If the request requires signature verification, the null value can be replaced with the line break “\n”.

4. Among all the non-HTTP-standard headers, only the headers starting with “x-acs-“ require signature strings, and other non-HTTP-standard headers are ignored.

5. Headers starting with “x-acs-“ must comply with the following specifications before being used for signature verification:

   • The head name is changed to lowercase letters.

   • The headers are sorted in alphabetical order.

   • No space before and after the colon that separates the head name from the value.

   • Each header is followed by a linefeed “\n”. If no header is provided, CanonicalizedBatchComputeHeaders is set to null.

NOTE:All the requests of Batch Compute must use the GMT time format stipulated in the HTTP 1.1 protocol. The following three date formats are available:

In these three date formats, “day” occupies “2 DIGIT”. Therefore, “Jun 2”, “2 Jun 1982”, and “2-Jun-82” are all invalid date formats.