AWS Signature Authentication¶
The AWS Signature authentication protocol signs every request sent through a web service connection with AWS Signature Version 4 (SigV4). AWS services such as AWS HealthLake and Amazon API Gateway reject requests that are not signed this way. QIE builds the signature itself, so channel scripts need no signing code.
What QIE Signs¶
QIE signs each request at the moment it is sent, using the request's method, URL, query string and content. Because the signature is created per request, a retry or a message resolved from the error queue is signed again with a fresh timestamp. QIE adds the Authorization, x-amz-date and x-amz-content-sha256 headers, plus x-amz-security-token when the credentials include a session token.
Signing applies to every call made through the connection: Web Service destination nodes, Web Service mapping functions, and qie.callRESTWebService() in a script.
QIE signs the URL as it is configured, before it adds any parameters. Non-header parameters, from a destination's parameter list or a qie.callRESTWebService() parameter map, are added after signing: to the query string for GET, and to a form-encoded body for other methods that have no content. The request AWS receives then no longer matches the signature, and AWS rejects it with a 403. Write query parameters into the URL itself, and pass only http.header. entries as parameters.
AWS rebuilds the query string in a canonical form before checking the signature, so write it that way yourself. Percent-encode each value once with uppercase hex, as in %7C for |, and list multiple parameters in alphabetical order by name.
Note
QIE cannot sign content streamed from a file or an input stream. Pass the content as a string or byte array instead.
Credentials¶
QIE takes the AWS credentials from one of two places:
- Use the AWS Credentials Provider checked: QIE obtains temporary credentials from the AWS environment it runs in (e.g. an ECS task role, an EC2 instance profile, or AWS environment variables). No keys are stored in QIE. This option requires QIE to be running in AWS.
- Use the AWS Credentials Provider unchecked: QIE signs with the access key ID entered in Username and the secret access key entered in Password. Session tokens are not supported in this mode.
The AWS identity must have IAM permission for every operation the channel performs. When QIE runs on ECS using the AWS ECS Install Guide, that identity is the role selected as the task's Task role.
Connecting to AWS HealthLake¶
- Create a web service connection and set Type to REST (Content Encoded).
- Set the Endpoint URL to the data store's FHIR R4 base URL, for example
https://healthlake.us-east-1.amazonaws.com/datastore/<datastore-id>/r4/. - Set Authentication to AWS Signature.
- Check Use the AWS Credentials Provider when QIE runs in AWS. Otherwise, enter an access key ID and secret access key in Username and Password.
- Set AWS Region to the data store's region (e.g.
us-east-1). - Set AWS Service to
healthlake.
Select this connection on a REST (Content Encoded) Sender destination or a Web Service mapping function. Set Content Type to application/fhir+json, and add the FHIR resource type (e.g. Patient) to the end of the URL.
Troubleshooting¶
A 403 response means AWS rejected the signature or the credentials. A 400 response means AWS accepted the signature and rejected the request itself; the response body explains why. To see the exact URL and headers QIE sent, follow Inspecting Requests and Responses.