AWS (IAM Roles)

Enhanced Advanced

Setting up an identity provider

Viewer Integration

To enable Viewer authentication type AWS integrations, perform the following steps to setup an external identity provider:

  1. In your identity provider’s administrator console, create a new OIDC application (sometimes called a “client”)
  • Popular identity providers include: Entra and Okta
  1. Configure the application (varies across identity providers):
  • Select “Authorization Code” as the OAuth 2.0 grant type
  • Configure the redirect URL (callback URL): https://connect.example.org/__oauth__/integrations/callback (Replace connect.example.org with the address of the Connect server)
    • The administrator must configure a redirect_uri for the OIDC application. This is what allows Posit Connect to obtain temporary access tokens, ID tokens, and refresh tokens.
  • Enable PKCE (Proof Key for Code Exchange) support
  • Add the required OIDC scopes:
    • openid (mandatory for OIDC)
    • offline_access (for refresh tokens)
  • Set the client type as “Confidential” if you want to use a client secret
  • Ensure the provider supports the standard OIDC claims in the ID token:
    • sub (subject identifier)
    • iss (issuer)
    • aud (audience)
  1. Note the following OIDC endpoints and credentials:
  • Client ID
  • Client Secret
  • Authorization Endpoint URI
  • Token Endpoint URI
  • OIDC issuer URL
    • Some common examples of OIDC issuer URLs include:
    • Entra: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0
    • Okta: https://<org-id>.okta.com/oauth2/default or https://<org-id>.okta.com

Service Account Integration

For this integration authentication type, Connect acts as the identity provider by signing content session tokens with an RSA key managed by Connect. At startup, Connect creates and registers this key in the database. This process allows Connect to use workload identity federation to integrate with AWS.

AWS requires that identity providers are OIDC-compliant. To meet this requirement, Connect exposes the following public endpoints: - https://<connect-server-address>/.well-known/openid-configuration - Provides metadata necessary for OIDC discovery - https://<connect-server-address>/openid/v1/jwks - Provides list of public keys that can be used by external systems like AWS to validate content session tokens

Please note that this means that these routes needs to be made accessible to the AWS STS service in order to exchange credentials. Work with your network administrator to configure Connect properly for this use case.

Content session tokens are generated and injected into content when it starts up, so there are no extra steps to make this token available to publishers.

Note the following OIDC information managed by Connect: - OIDC issuer URL - https://<connect-server-address>/ - Client ID or Audience - connect-content

Setting up AWS IAM

Next, your AWS administrator needs to configure both an AWS IAM Identity Provider and Role. Using the OIDC information from either the Viewer or Service Account identity provider setup above, follow these steps to properly configure AWS.

  1. Add the Identity Provider (IdP) in AWS:
  • In AWS IAM console, go to “Identity providers”
  • Choose “Add provider” and select “OpenID Connect”
  • Enter your Identity Provider’s OIDC issuer URL
  • Enter your application’s client ID as the audience
  • Click “Add provider”

Create AWS IAM OIDC identity provider

  1. Create an IAM Role for OIDC:
  • In IAM console, create a new role
  • Choose “Web identity” as the trusted entity type
  • Select your newly created IdP
  • Configure the audience value to match your client ID
  • Add the required AWS permissions to the role
  • Note the Role ARN for later configuration

Create AWS IAM OIDC identity provider

  1. Configure trust relationship:
  • Edit the role’s trust relationship
  • If applicable, ensure the trust policy includes conditions to validate OIDC claims. Note that there are constraints on which claims are supported. These claims can be configured in the external IdP for Viewer integrations. For Service Account integrations, the Connect-issued OIDC token has both the aud and sub claims that are supported by AWS IAM trust policy conditions.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::12345:oidc-provider/login.microsoftonline.com/<tenant-id>/v2.0"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "login.microsoftonline.com/<tenant-id>/v2.0:aud": "<client-id>"
        }
      }
    }
  ]
}
  1. Note the Role ARN, STS region, and configured maximum session duration as needed in the role settings.
Note

For OAuth application administrators who prefer to use the same OAuth application for both Posit Connect and Posit Workbench, simply register the Workbench redirect URL (https://workbench.example.org/oauth_redirect_callback) in addition to the Connect redirect URL.

Transfer information to Connect Administrator

The administrator of the identity provider and AWS shares the following information with the Posit Connect administrator:

Field Description
client_id Unique identifier for the OIDC application.
client_secret Secret identifier for the OIDC application. Not required for Public Viewer integrations.
authorization_uri The URI for the authorization endpoint. Can also be obtained from the Authorization Server Metadata Endpoint.
token_uri The URI for the token endpoint. Can also be obtained from the Authorization Server Metadata Endpoint.
token_endpoint_auth_method Determines how parameters are passed to the OIDC application. This is a property of the OIDC application itself.
scopes The permissions requested by Connect. At minimum, this must include offline_access and openid in order to retrieve an ID and refresh token.
role_arn The AWS IAM Role ARN that the integration will allow content to assume.
sts_region The region used by the AWS Security Token Service to retrieve the temporary credentials.
session_duration The duration that the credentials will be valid. The maximum duration is set in AWS IAM dashboard. It is recommended to set this value to that maximum.

Create AWS integration in Posit Connect

The Posit Connect administrator creates an integration through the dashboard’s System>Integrations settings. Once the integration has been created in Connect, it is available for use by all publishers. Currently, this integration supports both the Viewer and Service Account authentication types. See the documentation on supported authentication types for more information.

Create AWS integration.

Alternatively, the example below shows how to create a Confidential AWS integration using curl and the Connect Server API.

Note

Replace connect.example.org with the address of the Connect server.

Terminal
curl -H "Authorization: Key ${CONNECT_API_KEY}" \
  -XPOST https://connect.example.org/__api__/v1/oauth/integrations \
  --data '{
    "template": "aws",
    "name": "AWS integration",
    "description": "A helpful description for publishers to use when choosing an integration for their content.",
    "config": {
      "auth_type": "Viewer",
      "auth_mode": "Confidential",
      "client_id": "<client-id>",
      "client_secret": "<client-secret>",
      "authorization_uri": "<authorization-endpoint>",
      "token_uri": "<token-endpoint>",
      "scopes": "offline_access openid profile email",
      "role_arn": "<role-arn>",
      "sts_region": "us-east-1",
      "session_duration": "3600",
    }
  }'
# 200 OK
# {"guid": "<oauth-integration-guid>", ... }
Note

OAuth/OIDC integrations in Connect use the PKCE (Proof Key for Code Exchange) extension for the authorization code flow by default. PKCE is required in the upcoming OAuth 2.1 specification, and is recommended in all cases to protect against authorization code injection attacks. If necessary, PKCE can be disabled by creating an AWS Viewer integration with "use_pkce": false in the config map, but this is not recommended.