What is the Aliyun calling API signature mechanism

　　Signature mechanism

The ECS service authenticates each access request, so it is necessary to include the signature (Signature) information in the request, regardless of whether the request is submitted using the HTTP or HTTPS protocol. ECS verifies the sender identity of the request by using the access key ID and access key Secret for symmetric encryption. Access key IDs and access key Secret are issued to visitors by Aliyun authorities (which can be requested and managed through the Aliyun official web site), where the access key ID is used to identify the visitor; Access key Secret is the key used to encrypt signature strings and server-side validation signature strings, which must be kept strictly confidential and only Aliyun and users know.

When the user accesses, the request is signed by the following method:

Constructs a normalized request string using the request parameter (canonicalized Query string)

(a) The ordering of the parameters. Sorts the request parameters in the request in the dictionary order of the parameter names, including the custom parameters of the common request parameters and interfaces, but not the signature parameter itself, as mentioned in the common request parameters.

Note: When submitting a request using the Get method, these parameters are the parameter part in the request URI (that is, the "?" in the URI). The part that is then connected by the "&").

(b) Parameter encoding. The name and value of the request parameter after the sort is coded separately with the UTF-8 character set. The rules for encoding are as follows:

I. For characters A-Z, A-Z, 0-9 and character "-", "_", ".", "~" is not encoded;

Ii. for other characters encoded into "%XY" format, where XY is the character corresponding to the ASCII code of the 16-binary representation. For example, the English double quotation mark (") corresponds to the code is%22

Iii. for extended UTF-8 characters, encoded as "%xy%za ..." of the format;

Iv. what needs to be explained is that the English space () is coded to be%20 rather than a plus sign (+).

Note: This encoding is similar to the commonly used "application/x-www-form-urlencoded" MIME format encoding algorithm (such as the implementation of the Java.net.URLEncoder in the Java Standard library), but it is different. When implemented, you can encode the standard library, and then replace the plus (+) sign in the encoded string with a%20, asterisk (*) to replace the%2A,%7e replace the Wave (~), to get the code string described in the above rules. This algorithm can be implemented using the following Percentencode method:

private static final String ENCODING = "UTF-8";

private static string Percentencode (String value) throws Unsupportedencodingexception {

return value!= null? Urlencoder.encode (value, ENCODING). Replace ("+", "%20"). Replace ("*", "%2a"). Replace ("%7e", "~"): null;

}

(c) Connect the encoded parameter name and value in English by equal sign (=).

(d) A normalized request string is obtained by using the & symbolic connection in the order in which the combination of the parameters obtained by the equals sign is arranged in step (a).

The normalized string constructed in the previous step is constructed as a string to be signed according to the following rules:

stringtosign=

HttpMethod + "&" +

Percentencode ("/") + "&" +

Percentencode (canonicalizedquerystring)

Where HttpMethod is the HTTP method used to submit the request, such as get.

Percentencode ("/") is the value that the character "/" is encoded according to the URL encoding rule described in 1.b, that is, "%2f".

Percentencode (canonicalizedquerystring) is a string that is encoded by the URL encoding rule that is constructed in step 1th in the canonical request string as described in 1.b.

Calculates the HMAC value of the Stringtosign string to be signed, as defined in RFC2104. Note: The key used to compute the signature is the access key Secret that the user holds, plus a "&" character (ascii:38), and the hash algorithm used is SHA1.

The above HMAC value is encoded into a string according to the BASE64 encoding rule, and the signature value (Signature) is obtained.

The resulting signature value is added to the request parameter as the Signature parameter, which completes the process of signing the request.

Note: The resulting signature value is submitted to the ECS server as the final request parameter value and, like other parameters, URL-coded according to RFC3986 's rules.

Take describeregions For example, assuming that the access key Id is "TestID", access key Secret is "Testsecret." Then the request URL before signing is:

http://ecs.aliyuncs.com/? timestamp=2016-02-23t12:46:24z&format=xml&accesskeyid=testid&action=describeregions& signaturemethod=hmac-sha1&signaturenonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&version=2014-05-26& signatureversion=1.0

The computed signature string stringtosign is:

get&%2f&accesskeyid%3dtestid%26action%3ddescriberegions%26format%3dxml%26signaturemethod%3dhmac-sha1% 26signaturenonce%3d3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf%26signatureversion%3d1.0%26timestamp%3d2016-02-23t12% 253a46%253a24z%26version%3d2014-05-26

Because the access key Secret is "Testsecret", the key used to compute HMAC is "testsecret&", and the resulting signature value is:

Ct9x0vtwr86fnwsnsc6v8ygojue=

Add the signature as a signature parameter to the URL request, and the last URL is:

Http://ecs.aliyuncs.com/?SignatureVersion=1.0&Action=DescribeRegions&Format=XML&SignatureNonce= 3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&version=2014-05-26&accesskeyid=testid&signature= ct9x0vtwr86fnwsnsc6v8ygojue%3d&signaturemethod=hmac-sha1&timestamp=2016-02-23t12%3a46%3a24z

For a detailed example of how to sign and submit a request, see Appendix: How to invoke an interface.