Configure Redshift Compose SSO with IAM Identity Center and Trusted Identity Providers¶

Alation Cloud Service Applies to Alation Cloud Service instances of Alation

Customer Managed Applies to customer-managed instances of Alation

Core Connector Core connectors are included with all Alation platform tiers (subject to each tier’s connector limits) and are fully supported by Alation.

Applies from Alation version 2026.4.1.0 and Redshift OCF Connector version 1.12.0 onwards.

This topic explains how to configure Single Sign-On (SSO) in Compose for an Amazon Redshift data source using a trusted identity provider (IdP), such as Okta or Microsoft Entra ID, with AWS IAM Identity Center (IDC). This approach uses OAuth 2.0 / OpenID Connect (OIDC) and the Redshift JDBC driver’s IdpTokenAuthPlugin plugin with the EXT_JWT token type to propagate per-user identity to Redshift.

An SSO-enabled connection authenticates to the database for:

Running queries in Compose
Running query forms in Compose
Dynamic Profiling (if enabled)
The Upload Data operation

Each user gets a unique database identity (awsidc:<username>) in Redshift, providing a full per-user audit trail in both CloudTrail and Redshift query logs. This works with both Redshift Provisioned Clusters and Redshift Serverless Workgroups.

Note

This page covers the trusted identity provider approach using OAuth/OIDC. For the SAML federation approach, see Configure Redshift Compose SSO with IAM Identity Center Using SAML Federation.

Workflow¶

The following diagram shows the end-to-end authentication flow:

User in Alation Compose
    |
    | 1. User initiates an SSO login from Compose
    v
Identity provider (Okta / Entra ID)
    |
    | 2. User authenticates at the identity provider
    |    Identity provider returns an authorization code to Alation
    v
Alation
    |
    | 3. Alation exchanges the code for an access token (JWT) and refresh token
    |    Alation passes the JWT to the Redshift OCF connector
    v
Redshift JDBC Driver (IdpTokenAuthPlugin)
    |
    | 4. Driver presents the JWT to Redshift
    |    Redshift validates the token via IAM Identity Center
    v
Amazon Redshift
    Query executes as: awsidc:<username>

Prerequisites¶

Before you begin, ensure the following prerequisites are met:

AWS IAM Identity Center is enabled for your AWS organization.
Identity source is configured in IAM Identity Center (Active Directory, external IdP, or IAM Identity Center directory).
Users and groups are assigned to the target AWS account in IAM Identity Center with appropriate permissions.
Redshift Provisioned Cluster or Redshift Serverless Workgroup is deployed and accessible.
An OIDC-capable identity provider (Okta, Microsoft Entra ID, or equivalent) is available with admin access to create applications.
Alation instance is running with the Redshift OCF connector deployed.

Important

Enhanced VPC routing is not supported when using IAM Identity Center SSO for Amazon Redshift. If enhanced VPC routing is enabled on your cluster or workgroup, this integration will not work.

Because enabling or disabling enhanced VPC routing can affect your network setup, security, and how data is accessed, evaluate this requirement carefully before proceeding. If this integration is required, you may need to disable enhanced VPC routing or use a separate cluster or workgroup configured without it.

For more information, see Amazon Redshift enhanced VPC routing.

Required Roles¶

System	Role Required	Purpose
Alation	Data Source Admin	Configure OAuth settings and enable Compose SSO.
AWS	Administrative role	This role must have permissions to create applications and roles, manage users and groups, and access AWS IAM and AWS IAM Identity Center.
Identity Provider (Okta / Entra ID)	Application Administrator	Create OIDC applications, configure redirect URIs and scopes.
Amazon Redshift	Database superuser	Execute `CREATE IDENTITY PROVIDER` and `GRANT` SQL commands. These commands require superuser privileges.

Values You Will Collect¶

As you work through the steps, you will collect these values. Keep them handy:

Value	Source	Used In
`<idp_client_id>`	Identity provider app registration (Step 1)	Alation OAuth configuration (Step 2)
`<idp_client_secret>`	Identity provider app registration (Step 1)	Alation OAuth configuration (Step 2)
`<idp_issuer_url>`	Identity provider OIDC metadata (Step 1)	AWS Trusted Token Issuer (Step 4)
`<idp_authorize_endpoint>`	Identity provider OIDC metadata (Step 1)	Alation OAuth configuration (Step 2)
`<idp_token_endpoint>`	Identity provider OIDC metadata (Step 1)	Alation OAuth configuration (Step 2)
`<alation_base_url>`	Your Alation instance URL	Identity provider redirect URI (Step 1)
`<redshift_managed_app_arn>`	Redshift IDC integration (Step 5)	Redshift `CREATE IDENTITY PROVIDER` (Step 7)
`<iam_role_arn>`	IAM role creation (Step 3)	Redshift IDC integration and `CREATE IDENTITY PROVIDER` (Step 5, Step 7)
`<redshift-endpoint>`	Redshift console (Step 7)	Alation Compose connection URI (Step 2)
`<database>`	Redshift console (Step 7)	Alation Compose connection URI (Step 2)

The steps are performed in your identity provider, in Alation, and in AWS.

Step 1. IdP: Configure Your Trusted Identity Provider
Step 2. Alation: Configure OAuth and Compose Connection
Step 3. AWS: Create the IAM Role
Step 4. AWS: Create the Trusted Token Issuer
Step 5. AWS: Create the Redshift IDC Application
Step 6. AWS: Assign Users and Groups
Step 7. AWS: Integrate Redshift Cluster or Workgroup
Step 8. AWS: Grant Access to IDC Users and Groups
Test the Configuration

Step 1. IdP: Configure Your Trusted Identity Provider¶

Note

If you use a different OIDC-compliant identity provider, follow equivalent steps to create an OAuth 2.0 / OIDC application with the authorization code grant type.

Create an OIDC Application¶

Configure the following settings in your identity provider to create an OAuth 2.0 or OIDC Web Application:

Application type: Web Application
Grant type: Authorization Code (also enable Refresh Token)
Sign-in redirect URI: See Configure the Redirect URI below
Scopes: See Configure Scopes below

Copy the following values to your local machine from the application page:

<idp_client_id>: The Client ID or Application ID
<idp_client_secret>: The Client Secret

See the following reference documentation for more information:

Configure the Redirect URI¶

The redirect URI tells the identity provider where to send the user after authentication. This must point back to your Alation instance.

Redirect URI format:

<alation_base_url>/api/datasource_auth/oauth/callback/

Example:

https://alation.yourcompany.com/api/datasource_auth/oauth/callback/

Add this URI as a sign-in redirect URI in your identity provider application.

Important

The redirect URI must match exactly, including the trailing slash and protocol (https://). A mismatch will cause the OAuth callback to fail.

Collect OIDC Endpoints¶

Every OIDC provider publishes a discovery document at a well-known URL. Locate your provider’s OIDC discovery endpoint (typically <idp_issuer_url>/.well-known/openid-configuration) and from the JSON response, record:

JSON Field	Record As	Example (Okta)
`issuer`	`<idp_issuer_url>`	`https://yourcompany.okta.com/oauth2/default`
`authorization_endpoint`	`<idp_authorize_endpoint>`	`https://yourcompany.okta.com/oauth2/default/v1/authorize`
`token_endpoint`	`<idp_token_endpoint>`	`https://yourcompany.okta.com/oauth2/default/v1/token`

Configure Scopes¶

Ensure the OIDC application is configured to request the following scopes:

Scope	Required	Purpose
`openid`	Yes	Standard OIDC scope, required for ID token.
`email`	Recommended	Returns the user’s email address. Required if you use `email` as the Username Field/Claim in Alation and as the mapped attribute in the Trusted Token Issuer. The scope you request must return the claim that matches the attribute mapping configured in the Trusted Token Issuer (see Step 4).
`profile`	Recommended	Returns the user’s display name and other profile attributes.
`offline_access`	Yes	Returns a refresh token, enabling Alation to refresh access tokens without re-authentication. Required for scheduled queries, dynamic profiling, and uninterrupted long-lived sessions.

Assign Users¶

Assign users who need to connect to the data source using user-initiated connections. This applies to authentication initiated from Compose and from the Alation Catalog for actions that require user credentials, such as dynamic profiling, running query forms, and uploading data.

Step 2. Alation: Configure OAuth and Compose Connection¶

Note

You must have completed Step 1 and have all the collected values ready (client ID, client secret, authorize endpoint, token endpoint).

Enable Compose SSO¶

Note

This configuration requires a role that allows you to be assigned as a Data Source Admin (Server Admin, Catalog Admin, or Source Admin). The following steps assume you are already assigned as a Data Source Admin for the Redshift data source where you want to configure this authentication method.

Navigate to the Redshift data source for which you want to enable Compose SSO.
Go to Settings > Compose tab.
Locate Enabled in Compose and enable it for this data source.
Select the Enable OAuth 2.0 in Compose checkbox to enable OAuth 2.0.

Configure OAuth¶

On the Settings page of your Redshift data source, go to the Compose tab.
Locate the OAuth Connection section. Fill in the following fields:

Warning

If an OAuth configuration already exists on this data source, updating these fields will override it. Verify with your team before changing an existing configuration.

Field	Value	Description
Authorization Endpoint	`<idp_authorize_endpoint>`	The OIDC authorization endpoint from your identity provider. Example: `https://yourcompany.okta.com/oauth2/default/v1/authorize`
Token Request Endpoint	`<idp_token_endpoint>`	The OIDC token endpoint from your identity provider. Example: `https://yourcompany.okta.com/oauth2/default/v1/token`
Client ID	`<idp_client_id>`	The OAuth client ID from Step 1.
Client Secret	`<idp_client_secret>`	The OAuth client secret from Step 1.
Default Scope	`openid email profile offline_access`	Space-separated list of scopes. `offline_access` enables refresh tokens for scheduled queries.
Request Refresh Tokens	Selected	Enables the token refresh flow so Alation can obtain new access tokens without re-authentication.
Refresh Scope	`offline_access`	Scope to include when requesting refresh tokens.
Enable PKCE	Selected	Enables Proof Key for Code Exchange for enhanced security. Recommended for all deployments.
Username Field/Claim	For example, `sub`, `email`, `unique_name`	The claim in the access token that uniquely identifies the user. Use the claim whose value matches the user’s identity in AWS IAM Identity Center.
JWT	Selected	Indicates that the access token is a JWT (required for Redshift IDC authentication).

Click Save.

Note

The OAuth configuration is per data source. If you have multiple Redshift data sources that require Compose SSO, repeat this step for each one. You can reuse the same identity provider application and OAuth credentials (client ID, client secret, endpoints) across multiple Redshift data sources.

Create the Connection URI¶

On the Settings page of your Redshift data source, go to the Compose tab.
Go to the Compose Connections section and click + Add Connection.
Enter the connection URI in the following format:

redshift://<redshift-endpoint>:5439/<database>?plugin_name=com.amazon.redshift.plugin.IdpTokenAuthPlugin&token_type=EXT_JWT&authenticator=oauth

Example:

redshift://my-cluster.abc123xyz.us-east-1.redshift.amazonaws.com:5439/mydb?plugin_name=com.amazon.redshift.plugin.IdpTokenAuthPlugin&token_type=EXT_JWT&authenticator=oauth

Note

The URI format is the same for both provisioned clusters and serverless workgroups. The only difference is the <redshift-endpoint>.

Parameter	Value	Purpose
`plugin_name`	`com.amazon.redshift.plugin.IdpTokenAuthPlugin`	Tells the Redshift JDBC driver to use the IdP Token Authentication Plugin for connection.
`token_type`	`EXT_JWT`	Specifies that the token is an external JWT from a Trusted Identity Provider (not a native IDC token).
`authenticator`	`oauth`	Alation uses this parameter to detect that the connection requires OAuth authentication and triggers the SSO flow.

Give the connection a descriptive title (for example, Redshift Analytics (IDC SSO)).
Save the connection.

Verify the Configuration¶

After completing the OAuth setup and creating the connection:

Navigate to Compose.
Select the Redshift connection you just created.
In the Connect as dropdown, you should see +Add New (SSO Login).

If you do not see the SSO Login option, verify:

OAuth configuration is saved correctly with all required fields.
Compose SSO is enabled on the data source.
The connection URI contains the authenticator=oauth parameter.

Important

Do not test the full connection yet. The AWS and Redshift configuration (Steps 3-8) must be completed first for the end-to-end flow to work.

Step 3. AWS: Create the IAM Role¶

Note

You must have completed Step 1 (identity provider setup) and have the <idp_issuer_url> value ready.

Redshift needs an IAM role to communicate with IAM Identity Center for token validation and identity propagation.

Open the IAM console > Roles > Create role.
Configure the trust policy. sts:AssumeRole allows the Redshift service to assume this role. sts:SetContext allows the principal to embed trusted context key-value pairs into a temporary STS role session for identity propagation. Include both service principals if you use both provisioned clusters and serverless workgroups.
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "redshift.amazonaws.com",
          "redshift-serverless.amazonaws.com"
        ]
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetContext"
      ]
    }
  ]
}
```
Note

Include redshift.amazonaws.com for provisioned clusters or redshift-serverless.amazonaws.com for serverless workgroups (or both if you use both).

Attach the following permissions policy. This example covers both provisioned clusters and serverless workgroups. Include only the statements that apply to your deployment:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "IDCAccess",
      "Effect": "Allow",
      "Action": [
        "sso:DescribeApplication",
        "sso:DescribeInstance",
        "sso:GetApplicationGrant",
        "sso:ListInstances",
        "sso-oauth:CreateTokenWithIAM",
        "sso-oauth:IntrospectTokenWithIAM",
        "sso-oauth:RevokeTokenWithIAM"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftAccess",
      "Effect": "Allow",
      "Action": [
        "redshift:DescribeClusters"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftServerlessAccess",
      "Effect": "Allow",
      "Action": [
        "redshift-serverless:GetWorkgroup",
        "redshift-serverless:GetNamespace"
      ],
      "Resource": "*"
    }
  ]
}

Note

Include RedshiftAccess for provisioned clusters or RedshiftServerlessAccess for serverless workgroups (or both if you use both). These permissions allow Redshift to describe its own resources during the IDC integration flow.

Name the role (for example, RedshiftIDCRole) and click Create role.

Copy the IAM role ARN and save it as <iam_role_arn> (for example, arn:aws:iam::123456789012:role/RedshiftIDCRole). You will need this value in the following steps.

Step 4. AWS: Create the Trusted Token Issuer¶

The Trusted Token Issuer (TTI) tells IAM Identity Center how to validate JWTs from your external identity provider.

In the IAM Identity Center console, go to Settings > Authentication > Trusted token issuers.
Click Create trusted token issuer.
Configure:
- Issuer URL: <idp_issuer_url> (for example, https://yourcompany.okta.com/oauth2/default)
- Map attributes:
  - Identity Center attribute: for example, email
  - Trusted token issuer attribute: for example, email
Important

The trusted token issuer attribute you map here must match the JWT claim that you configure as Username Field/Claim in Alation (see Configure OAuth). Your identity provider must include this claim in the access token. For example, if you map email in the Trusted Token Issuer, use email as the Username Field/Claim in Alation and ensure the email scope is requested.
Click Create trusted token issuer.

Step 5. AWS: Create the Redshift IDC Application¶

In the Amazon Redshift console, select IAM Identity Center connection from the left navigation menu.
Click Create application.
On the IAM Identity Center connection page, click Next.
In the IAM Identity Center integration setup section, configure:
- IAM Identity Center display name — Enter a unique name (for example, Alation-Redshift-IDC). This appears in the IAM Identity Center console and APIs.
- Managed application name — You can use the assigned default value or enter a custom name. This is the unique identifier for the managed application.
- Identity provider namespace — Enter a namespace for your organization (for example, awsidc). This is added as a prefix for IAM Identity Center-managed users and roles in the Redshift database (for example, awsidc:<username>).
- IAM role for IAM Identity Center access — Select the IAM role created in Step 3 (for example, RedshiftIDCRole).
- Enable the query editor v2 application — Check this box to allow users to access the database through their IAM Identity Center-based identity via Query Editor V2.
In the Configure client connections that use third-party IdPs section, select Yes. This is required for Alation Compose SSO, which presents external IdP JWTs to Redshift.
In the Trusted token issuers section, select the Trusted Token Issuer created in Step 4 and configure the audience — this is the intended recipient of the token and must match the aud claim in the JWT issued by your identity provider (for example, 0oazbhjfqgyEMjWZ7697 or api://0oazbhjfqgyEMjWZ7697 depending on your IdP configuration).
Click Next.
On the Review and create application page, review all details and click Create application.

After the application is created, the IAM Identity Center properties appear in the Redshift Console with an integration status of Success.

Copy the Redshift managed application ARN and save it as <redshift_managed_app_arn> (for example, arn:aws:sso::123456789012:application/ssoins-abc123/apl-xyz789). You will need this value in the following steps.

Step 6. AWS: Assign Users and Groups¶

Users and groups must exist in your IAM Identity Center instance before they can be assigned to the Redshift managed application. Provision them via SCIM synchronization from your identity provider or create them manually in the IAM Identity Center directory. Once provisioned, assign them to the application to control who can authenticate to Redshift via the external IdP.

In the Amazon Redshift console, go to IAM Identity Center properties (this appears after the application was created in Step 5).
Select the Groups tab.
Click Assign.
If this is the first time you’re assigning groups, you’ll see a notification — select Get started.
Enter which groups you want to synchronize with the application, and select them.

Note

Best practice: Assign groups rather than individual users. New users added to the group automatically get access.

Click Done.

Step 7. AWS: Integrate Redshift Cluster or Workgroup¶

After creating the IDC application, you need to integrate it with your Redshift cluster or workgroup. The steps differ depending on whether you are creating a new resource or using an existing one.

For a New Cluster or Serverless Workgroup

When creating a new provisioned cluster or serverless workgroup:

In the Amazon Redshift console, start the cluster or workgroup creation workflow.
In the IAM Identity Center connection section, select Enable for the cluster (or workgroup).
From the dropdown, select the Redshift application you created in Step 5.
Complete the remaining cluster/workgroup creation steps.

Note

The IAM role specified for IAM Identity Center integration is automatically attached to the provisioned cluster or Serverless namespace during creation.

For an Existing Provisioned Cluster

First, associate the IAM role created in Step 3 with the cluster:

In the Amazon Redshift console, select your cluster.
Go to Properties > Cluster permissions.
Under Associated IAM roles, associate the IAM role (for example, RedshiftIDCRole).

For an Existing Serverless Workgroup

First, associate the IAM role created in Step 3 with the workgroup’s namespace:

In the Amazon Redshift Serverless console, select your workgroup.
Go to Security & Encryption.
Under Permissions, click Manage IAM roles.
Associate the IAM role (for example, RedshiftIDCRole).

Create the identity provider (existing cluster or workgroup)

After associating the IAM role, connect to your Redshift database as a superuser (using Query Editor V2, psql, or any SQL client) and run the following SQL:

CREATE IDENTITY PROVIDER "<display_name>" TYPE AWSIDC
  NAMESPACE '<namespace>'
  APPLICATION_ARN '<redshift_managed_app_arn>'
  IAM_ROLE '<iam_role_arn>';

Example:

CREATE IDENTITY PROVIDER "redshift-idc-app" TYPE AWSIDC
  NAMESPACE 'awsidc'
  APPLICATION_ARN 'arn:aws:sso::123456789012:application/ssoins-abc123/apl-xyz789'
  IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftIDCRole';

Replace <display_name> with the IAM Identity Center display name from Step 5, <namespace> with the identity provider namespace from that same section, <redshift_managed_app_arn> with the managed application ARN, and <iam_role_arn> with the IAM role ARN from Step 3.

Verify the identity provider was created:

SELECT * FROM svv_identity_providers;

You should see a row with the name, type awsidc, and namespace you specified.

Step 8. AWS: Grant Access to IDC Users and Groups¶

After the identity provider is created, IDC users and groups appear in Redshift with the awsidc: namespace prefix. You need to grant them appropriate permissions.

Grant Schema and Table Permissions

-- Grant usage on schema (to group)
GRANT USAGE ON SCHEMA public TO ROLE "awsidc:<group_name>";

-- Grant read access to all existing tables in a schema
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ROLE "awsidc:<group_name>";

-- Grant read access on future tables automatically
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO ROLE "awsidc:<group_name>";

-- Grant read access to specific tables (per-user, only if needed)
GRANT SELECT ON TABLE public.my_table TO USER "awsidc:<username>";

Note

Always include ALTER DEFAULT PRIVILEGES so that new tables created in the schema are automatically accessible. Without it, you’d need to re-run GRANT SELECT ON ALL TABLES every time a new table is created.

Example: Full Setup for an Analytics Group

This example grants the data-analysts IDC group read access to the analytics and public schemas:

-- 1. Grant schema access
GRANT USAGE ON SCHEMA analytics TO ROLE "awsidc:data-analysts";
GRANT USAGE ON SCHEMA public TO ROLE "awsidc:data-analysts";

-- 2. Grant read access to existing tables
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO ROLE "awsidc:data-analysts";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ROLE "awsidc:data-analysts";

-- 3. Grant read access to future tables (important)
ALTER DEFAULT PRIVILEGES IN SCHEMA analytics
  GRANT SELECT ON TABLES TO ROLE "awsidc:data-analysts";
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO ROLE "awsidc:data-analysts";

Test the Configuration¶

Verify Redshift Setup¶

Run these SQL queries to verify the Redshift configuration:

Check the identity provider:
```
SELECT * FROM svv_identity_providers;
```

Check IDC-mapped roles (after at least one user has connected):

SELECT * FROM svv_roles WHERE role_name LIKE 'awsidc:%';

Check current user (when connected via IDC):

SELECT current_user;
-- Should return: awsidc:<your_username>

Test Connection in Compose¶

Log in to Alation as a user who has access to the Amazon Redshift data source and needs to use Compose.
Navigate to Compose.
Click the Connection Settings link to open the Connection Settings dialog.
From the Choose a Connection list, select the connection you created in Create the Connection URI.
Open the Connect as list. It should include an option +Add New (SSO Login). This means that the OAuth configuration in the URI has been recognized by Compose.
Click +Add New (SSO Login). This should open the identity provider login screen in a new tab.
Log in with your credentials. The tab will close and you will be authenticated in Compose.

Test Dynamic Profiling¶

This test applies if Dynamic Profiling is enabled for the Amazon Redshift data source:

In the Alation Catalog, open a catalog page of a column in your Redshift data source.
Click Run Profile. The Data Source Authorization dialog should pop up.
Use the SSO-enabled connection from the list of saved connections or create a new one for your test user.
Click Set as Active Connection to apply the connection.
A new browser tab should open where you will be redirected to the identity provider login screen. Enter the IdP credentials to authenticate.
Upon authentication, you will be able to profile the column.

Test Data Upload¶

Go to the Amazon Redshift data source page in the catalog.
On the upper right, click the Options menu (the three dots icon), and then select Upload Data.
Try to test-upload a table: the authentication flow should be the same as described above in Test Dynamic Profiling.

Configure Redshift Compose SSO with IAM Identity Center and Trusted Identity Providers¶

Workflow¶

Prerequisites¶

Required Roles¶

Values You Will Collect¶

Step 1. IdP: Configure Your Trusted Identity Provider¶

Create an OIDC Application¶

Configure the Redirect URI¶

Collect OIDC Endpoints¶

Configure Scopes¶

Assign Users¶

Step 2. Alation: Configure OAuth and Compose Connection¶

Enable Compose SSO¶

Configure OAuth¶

Create the Connection URI¶

Verify the Configuration¶

Step 3. AWS: Create the IAM Role¶

Step 4. AWS: Create the Trusted Token Issuer¶

Step 5. AWS: Create the Redshift IDC Application¶

Step 6. AWS: Assign Users and Groups¶

Step 7. AWS: Integrate Redshift Cluster or Workgroup¶

Step 8. AWS: Grant Access to IDC Users and Groups¶

Test the Configuration¶

Verify Redshift Setup¶

Test Connection in Compose¶

Test Dynamic Profiling¶

Test Data Upload¶

Alation User Documentation PDFs