AWS

New
  • Published on Jan 11, 2026
  • 3 minute(s) read
Prev Next

PlainID’s PIP REST adapter can be used to integrate with AWS endpoints and consume them as Data Sources. This integration enables PlainID to retrieve external data directly from AWS services using standard REST calls.

AWS APIs typically require AWS Signature Version 4 (SigV4) authentication. SigV4 signs each outbound request using AWS credentials and attaches the calculated signature to the request, primarily through the Authorization header with supporting SigV4 headers.

The aws-sigv4 wrapper generates SigV4-compliant authentication by calculating the signature and injecting the required headers into each request. This approach aligns with the AWS security model, where the request itself is signed, rather than using a bearer token.

For additional background, see the AWS SigV4 documentation.

AWS Prerequisites

The target AWS Service name that will be used for this integration and the matching AWS Region of that service should be well defined before setting up the PIP integration.

To enable the integration with AWS using REST APIs, these prerequisites are required:

  • AWS credentials to connect to the AWS REST API
    • Long-term credentials consisting of an Access Key ID and Secret Access Key.
    • Temporary credentials from AWS STS consisting of an Access Key ID, Secret Access Key, and Session Token.
  • Permission to the target AWS Service that will be called in the API with the appropriate credentials.

REST Data Source Configuration

AWS integration is configured using the PIP REST adapter, in the same manner as any other REST Data Source. This includes defining endpoints, DDL, and response parsing. The AWS-specific requirement is enabling SigV4 request signing.

Authentication Configuration for AWS SigV4

Configure AWS credentials in auth-config.xml using the dedicated AWS Login Module.

<application-policy name="aws-creds">
  <authentication>
    <login-module code="com.plainid.pip.auth.oauth.aws.AWSLoginModule" flag="required">
      <module-option name="access-key-id">...enter here...</module-option>
      <module-option name="secret-access-key">...enter here...</module-option>

      <!-- Optional: include when using temporary STS credentials -->
      <!-- <module-option name="session-token">...enter here...</module-option> -->
    </login-module>
  </authentication>
</application-policy>

AWS SigV4 is not an OAuth flow and instead of getting a token based on client credentials, the credentials are used directly to sign each request and generate the Authorization header and supporting headers, such as x-amz-date and, when applicable, x-amz-security-token.

Translator Properties for AWS SigV4

Other than setting up the auth-config with the AWS Login Module and referring to it using the regular translator properties, authConf and securityDomain, the PIP Data Source definition must include the translator property restWrapper with the value aws-sigv4.

AWS SigV4 also requires the AWS service name (tagging in this example) and region to correctly scope the signature.

authConf = /app/conf/auth-config.xml
securityDomain = aws-creds
restWrapper = aws-sigv4
awsService = tagging
awsRegion  = us-east-2

Many AWS services also require additional service-specific headers, such as content type or protocol targets. These headers can be provided using the headers configuration property.

Example: AWS Resource Groups Tagging (SigV4)

This example demonstrates using the AWS Resource Groups Tagging API GetResources operation as a REST Data Source, signed with AWS Signature Version 4 (SigV4).

AWS exposes a query-style HTTPS API. While AWS SDKs typically handle SigV4 signing automatically, direct REST calls are supported when requests are properly signed.

Endpoint

https://tagging.us-east-2.amazonaws.com

Foreign Table Example

The GetResources API returns a list of tagged AWS resources. The foreign table below maps each entry in ResourceTagMappingList and includes a request body that filters by a specific tag and limits results per page.

CREATE FOREIGN TABLE AWS_TAGGED_RESOURCES (
    ResourceARN STRING,
    ResourceType STRING,
    Tags STRING
)
OPTIONS (
    nameinsource '$.ResourceTagMappingList[*]',
    "plainid:unwrap" 'false',
    "plainid:method" 'POST',
    "plainid:URI" '/',
    "plainid:bodyJsonContent" '{
        "TagFilters": [
            {
                "Key": "X392",
                "Values": ["KFJS-45353"]
            }
        ],
        "ResourcesPerPage": 100
    }'
);

Translator Properties for Resource Groups Tagging API

restWrapper = aws-sigv4
authConf = /app/conf/auth-config.xml


awsService = tagging
awsRegion  = us-east-2

headers = {
  "content-type": ["application/x-amz-json-1.1"],
  "x-amz-target": ["ResourceGroupsTaggingAPI_20170126.GetResources"]
}
securityDomain = aws-creds

Notes:

  • awsService=tagging is required for SigV4 signing with the Resource Groups Tagging API.
  • The x-amz-target value must exactly match the API service name, version, and action.

Authentication Configuration (auth-config.xml)

Replace the credentials below with your own secure mechanism (IAM role, temporary credentials, secrets manager, etc.).

<application-policy name="aws-creds">
             <authentication>
                 <login-module code="com.plainid.pip.auth.oauth.aws.AWSLoginModule" flag="required">
                     <module-option name="access-key-id">AKIAYZHG4SXQ5YAGHV4K</module-option>
                     <module-option name="secret-access-key">LZ6uyY345235231FGLYsfsieohfjxEfHrAkXyQmIJcK</module-option>

Important:

  • Credentials must be protected and rotated. Prefer IAM roles or temporary credentials wherever possible.
  • Ensure securityDomain=aws-creds matches the <application-policy name="aws-creds"> value.

Known Limitations

  • Currently, this integration can be used for AWS APIs using JSONs only.
  • AWS APIs Pagination based on next page link is not supported.

By correctly configuring AWS credentials, IAM permissions, service names, and regions, the PIP can retrieve external data from AWS endpoints without relying on SDKs or token-based authentication. This approach provides flexibility while adhering to AWS security requirements, allowing AWS services to be consumed consistently as Data Sources within authorization Policies.

Related articles