I am not an AWS expert but...
I think the 403 is from Amazon, telling you "that call is not authorized." In my experience, that can be returned for multiple reasons, and you need to look in the payload of the response from the AWS endpoint to figure out the specific reason. The payload you showed is from Apigee. You need to look into the payload from AWS for the explanation. A typical reason is that the signature does not validate. When the signature you provide in the request does not match the request you are making, the AWS endpoint will return 403 and an appropriate message in the payload.
AWS v4 Signatures can be tricky to get right. I notice that you showed a hard-coded ServiceCallout policy, which specific values in the configuration for the Payload, the Content-Sha256, and the Authorization header. how did you compute these values? Where did you get them?
As one consideration, the Content-Sha256 is a digest on the Payload. The payload you showed as hard-coded in this policy configuration has indentation and spacing. When I compute the SHA256 of the payload as you have pasted it in above, I get
54ce14b18187a00265ef75a5ee8fd69d53a5c3c97a0ed2b447377a2cb2f36941
...which differs from the content-sha256 value shown in your policy configuration. Why?
Depending on how you format the payload, how much indentation, whether there are spaces between the colons and the values, and so on... the SHA256 will be different. Even if the JSON is semantically the same, with all those appearance-only differences, the SHA256 will be different. And the AWS endpoint will check the digest, and if it finds that the SHA256 claimed in the header does not match the SHA256 it computes on the actual content you pass, then the signature validation will fail. You will see a 403.
It's tricky to get it just right. Hard-coding the sha256... is fragile and not likely to not result in success.
As another example, the x-amz-date header needs to be "now", at the time you send the request. You cannot copy a AWS v4 signature that worked 20 minutes ago and expect it to work if you send the request "now." AWS will reject it as stale. (I believe the maximum allowed timespan between x-amz-date and "now" is 15 minutes, not sure if that is bi-directional)
So hard-coding things is troublesome and hard to get right. There is a Java callout that helps compute the right signature and headers for AWS v4 signing. It's available here. Given a Message object containing a payload like the one shown in your ServiceCallout policy, this callout will
- compute the content-sha256 correctly and insert that header into the message
- format and insert the correct x-amz-date header into the message
- set the host header
- compute the signature and set the correctly formatted Authorization header using AWS4-HMAC-SHA256
After that, you can use a ServiceCallout policy that references that message, to connect to an endpoint like the AWS KMS endpoint.
Check the readme for examples.
If you choose to use this callout, your flow in Apigee will be something like this:
<Step>
<!-- create the message and set the payload + any static headers you need -->
<Name>AM-Construct-Outgoing-KMS-Message</Name>
</Step>
<Step>
<!-- insert the headers required for AWS v4 signature -->
<Name>JC-AWSSignV4-Outgoing-KMS-Message</Name>
</Step>
<Step>
<!-- send the message with the computed headers -->
<Name>SC-Send-KMS-Message</Name>
</Step>
LinkedIn
Twitter
