|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
This section provides detailed explanations for some of the tasks required to generate a signature. A signature is required for every request. For sample code for generating signatures, see Code Samples.
Web service requests are sent using SSL (HTTPS) across the Internet and are subject to tampering. Amazon FPS uses the signature to determine if any of the parameters or parameter values were changed in a web service request. Amazon FPS requires a signature to be part of every request.
To create the signature
Create the canonicalized query string that you need later in this procedure:
Sort the UTF-8 query string components by parameter name with natural byte ordering.
The parameters can come from the GET URI or from the POST body (when
URL encode the parameter name and values according to the following rules:
Do not URL encode any of the unreserved characters that RFC 3986 defines.
These unreserved characters are A-Z, a-z, 0-9, hyphen ( - ), underscore ( _ ), period ( . ), and tilde ( ~ ).
Percent encode all other characters with %XY, where X and Y are hex characters 0-9 and uppercase A-F.
Percent encode extended UTF-8 characters in the form %XY%ZA....
Percent encode the space character as %20 (and not +, as common encoding schemes do).
Currently all AWS service parameter names use unreserved characters, so you don't need to encode them. However, you might want to include code to handle parameter names that use reserved characters, for possible future use.
Separate the encoded parameter names from their encoded values with the equals sign ( = ) (ASCII character 61), even if the parameter value is empty.
Separate the name-value pairs with an ampersand ( & ) (ASCII code 38).
Create the string to sign according to the following pseudo-grammar (the
"\n" represents an ASCII newline).
StringToSign = HTTPVerb + "\n" + ValueOfHostHeaderInLowercase + "\n" + HTTPRequestURI + "\n" + CanonicalizedQueryString <from the preceding step>
The HTTPRequestURI component is the HTTP absolute path component of the URI up to, but not including, the query string. If the HTTPRequestURI is empty, use a forward slash ( / ).
Calculate an RFC 2104-compliant HMAC with the string you just created, your Secret Access Key as the key, and SHA256 or SHA1 as the hash algorithm.
For more information, go to http://www.ietf.org/rfc/rfc2104.txt.
Convert the resulting value to base64.
Use the resulting value as the value of the
Signature request parameter.
The final signature you send in the request must be URL encoded as specified in RFC 3986 (for more information, go to http://www.ietf.org/rfc/rfc3986.txt). If your toolkit URL encodes your final request, then it handles the required URL encoding of the signature. If your toolkit doesn't URL encode the final request, then make sure to URL encode the signature before you include it in the request. Most importantly, make sure the signature is URL encoded only once. A common mistake is to URL encode it manually during signature formation, and then again when the toolkit URL encodes the entire request.
For inbound requests, signature version 2 signing uses the entire request uri as the basis for the signature, and encryption is based on the unique security credentials for your account.
For outbound notifications, signature version 2 provides the Amazon FPS action,
VerifySignature, which enables you to securely check a response using a server-side call.
The original implementation of signature version 2 supported client-side signature validation using PKI. Client-side signature validation was deprecated on November 3rd, 2009, and as of 10 February, 2011 it is no longer supported. If you have been using client-side signature validation, you must switch to server-side validation using the FPS action
The previous method for signing (signature version 1) was deprecated on November 3rd, 2009, and as of 10 February, 2011 it is no longer supported. Whenever you sign a request with your access keys, you must now use signature version 2.
If you decide that it is necessary to change your access keys, the security credentials page (available from your account page at the Amazon Web Services website at http://aws.amazon.com) enables you to create a second set, and allows you to activate and deactivate the sets independently.
With both sets active, you can propagate the new set to your applications over time, maintaining the high security that signing provides. Since both sets are valid, you don't have to take your entire application down to incorporate the new keys. When the distribution is complete you can deactivate the old set.
You can have two sets of keys only. Both, one, or neither of them can be active.