Configure Redshift SSO via Microsoft Entra ID for Data Product Chat

Alation Cloud Service Applies to Alation Cloud Service instances of Alation

This topic provides step-by-step instructions for configuring SSO authentication for Redshift data products using Microsoft Entra ID (formerly Azure Active Directory) as the identity provider (IdP).

In this topic:

Prerequisites

Before you begin, confirm the following:

  • You have the Application Administrator or Cloud Application Administrator role in Microsoft Entra ID.

  • AWS STS is enabled in the AWS region where your Redshift cluster is located.

  • You have the Server Admin role in Alation.

  • Each Alation user who needs to access Redshift data through Data Product Chat exists in your Entra ID user directory.

  • Your Redshift cluster is accessible and you know the cluster ID and region.

Step 1: Register Alation as an Enterprise Application in Entra ID

  1. Sign in to the Microsoft Entra admin center.

  2. Go to Identity > Applications > Enterprise applications.

  3. Click New application.

  4. Click Create your own application.

  5. Enter a name for the application, for example Alation Data Products Redshift SSO.

  6. Select Integrate any other application you don’t find in the gallery (Non-gallery) and click Create.

Note

If your organization already has an AWS enterprise application in Entra ID (for example, Amazon Web Services (AWS)), you can use it instead of creating a new one. Open the existing application and proceed to Step 2.

Step 2: Configure SAML SSO in the Enterprise Application

  1. In the enterprise application, go to Single sign-on in the left menu.

  2. Select SAML as the single sign-on method.

  3. In Section 1 — Basic SAML Configuration, click Edit and configure:

    Field

    Value

    Identifier (Entity ID)

    urn:amazon:webservices

    Reply URL (Assertion Consumer Service URL)

    https://<your_alation_url>/api/v2/auth/callback/

    Replace <your_alation_url> with the base URL of your Alation instance.

  4. Click Save.

Step 3: Download the Federation Metadata XML

  1. In the enterprise application’s Single sign-on page, scroll to Section 3 — SAML Signing Certificate.

  2. Click Download next to Federation Metadata XML.

  3. Save the downloaded XML file. You will upload it to AWS in the next step.

  4. Note the Login URL from Section 4 — Set up <app name>. You will enter this URL in Alation in Step 8: Create an Authentication Configuration in Alation.

Step 4: Create an Identity Provider in AWS

  1. In the AWS Management Console, go to IAM > Identity providers.

  2. Click Add provider.

  3. Set Provider type to SAML.

  4. Enter a provider name, for example entra-redshift-sso.

  5. Upload the Federation Metadata XML file you downloaded in Step 3.

  6. Click Add provider.

  7. Note the provider ARN. You will need it when configuring claims in Step 6.

Step 5: Create an IAM Role with Trust Relationship

  1. In the AWS Management Console, go to IAM > Roles and click Create role.

  2. Select SAML 2.0 federation as the trusted entity type.

  3. Select the SAML provider you created in Step 4.

  4. Select Allow programmatic and AWS Management Console access.

  5. Click Next and attach a policy with the following permissions:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "redshift:GetClusterCredentials",
          "Resource": [
            "arn:aws:redshift:<region>:<account-id>:dbname:<cluster-id>/*",
            "arn:aws:redshift:<region>:<account-id>:dbuser:<cluster-id>/${redshift:DbUser}"
          ]
        },
        {
          "Effect": "Allow",
          "Action": "redshift:DescribeClusters",
          "Resource": "*"
        }
      ]
    }
    

    Replace <region>, <account-id>, and <cluster-id> with your cluster values.

  6. Name the role, for example alation-redshift-saml-role, and click Create role.

  7. Open the role’s Trust relationships tab. Verify the trust policy includes a SAML:aud condition pointing to your Alation callback URL:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::<account-id>:saml-provider/<provider-name>"
          },
          "Action": "sts:AssumeRoleWithSAML",
          "Condition": {
            "StringEquals": {
              "SAML:aud": "https://<your_alation_url>/api/v2/auth/callback/"
            }
          }
        }
      ]
    }
    

    Replace <account-id> with your AWS account ID, <provider-name> with the SAML provider name from Step 4, and <your_alation_url> with your Alation base URL. This condition ensures the role can only be assumed via SAML assertions destined for your Alation instance.

    Important

    Do not use https://signin.aws.amazon.com/saml for the SAML:aud value. That URL is for direct AWS Console SSO. Alation uses its own callback endpoint as the SAML audience.

  8. Note the role ARN. You will need it in Step 6.

Step 6: Configure SAML Claims in Entra ID

  1. Return to the enterprise application in the Microsoft Entra admin center.

  2. Go to Single sign-on > Section 2 — Attributes & Claims and click Edit.

  3. Click Add new claim and configure the following claims:

    Claim Name

    Value

    https://aws.amazon.com/SAML/Attributes/RoleSessionName

    user.userprincipalname

    https://aws.amazon.com/SAML/Attributes/Role

    <RoleARN>,<PrincipalARN>

    Replace:

    • <RoleARN> with the ARN of the IAM role from Step 5, for example arn:aws:iam::123456789012:role/alation-redshift-saml-role

    • <PrincipalARN> with the ARN of the identity provider from Step 4, for example arn:aws:iam::123456789012:saml-provider/entra-redshift-sso

    The combined value for the Role claim should look like:

    arn:aws:iam::123456789012:role/alation-redshift-saml-role,arn:aws:iam::123456789012:saml-provider/entra-redshift-sso
    
  4. Click Save.

Step 7: Assign Users in Entra ID

  1. In the enterprise application, go to Users and groups.

  2. Click Add user/group.

  3. Select the users or groups who need access to Redshift data through Data Product Chat.

  4. Click Assign.

Step 8: Create an Authentication Configuration in Alation

  1. Log in to Alation as a Server Admin.

  2. Click the Settings icon in the upper right to open Admin Settings.

  3. Go to Server Admin > Authentication and scroll to the Authentication Configuration Methods for External Systems section.

  4. Click Add Configuration and select AWS IAM.

  5. Fill in the following fields:

    Field

    Value

    Config Name

    Enter a unique name, for example Redshift Entra SSO.

    STS Duration

    Enter the duration in seconds (900–43200). Default is 3600.

    Region

    Select the AWS region of your Redshift cluster.

    Cred Type

    Leave as default. This field is not required for SAML SSO authentication.

    Redirect URL

    Paste the Login URL from Step 3 (the Entra SAML SSO endpoint).

    Entity Id

    Leave blank or enter the base URL of your Alation instance. This field sets the Issuer in the SAML AuthnRequest.

    Encode Relay State

    Check this box if your Redshift connection URI contains multiple query parameters (for example, ?ClusterID=x&Region=y).

    Important

    You must enable Encode Relay State when the JDBC URI used in the data product contains an ampersand (&) character. Without encoding, the & in the URI breaks the SAML RelayState parameter and causes authentication failures.

  6. Click Save.

Step 9: Configure the Data Product and Test

  1. Navigate to the data product in the Data Products App.

  2. Go to Settings > Chat Configuration > Configure Connection.

  3. Under Authentication Method, select AWS IAM: AWS IAM authentication.

  4. Select the authentication configuration you created in Step 8.

  5. Open the Chat panel and click Continue with SSO.

  6. You are redirected to the Microsoft Entra ID login page. Enter your credentials.

  7. After successful authentication, the Chat is ready for use.

Troubleshooting

Issue

Resolution

400 error or “missing root element” from Entra ID

The & characters in the JDBC URI are breaking the SAML RelayState. Enable the Encode Relay State checkbox in the Alation AWS IAM authentication configuration.

“Logon denied” after SSO completes

Verify the IAM role has redshift:GetClusterCredentials permission scoped to your cluster. Check that the role ARN and provider ARN in the Entra claims match exactly.

“Auth received, but session not found”

The Reply URL in Entra does not match the Alation callback endpoint. Confirm it is set to https://<your_alation_url>/api/v2/auth/callback/.

Entra shows “AADSTS50011: Reply URL does not match”

Update the Reply URL in the enterprise application’s Basic SAML Configuration to match the callback URL exactly, including the trailing slash.

User gets “Access denied” in Entra

The user is not assigned to the enterprise application. Assign them in Users and groups.

“Specified provider doesn’t exist” (AuthSamlManifestNotFoundException)

The SAML provider ARN in the IAM role trust policy does not match the provider you created in AWS, or the metadata XML uploaded to AWS does not match your IdP. Verify the provider name matches exactly (including hyphens vs. underscores) and re-upload the metadata if you recreated the IdP application.

“Could not resolve OCF configuration for data product”

The connection URI in the data product must match the URI configured on the Redshift OCF data source. Confirm both use the same redshift:iam:// URI format with matching host, database, and query parameters.

IdP shows a generic error without displaying the login page

The Entity Id configured in Alation must match the Audience (or Realm) configured in your IdP application. If you left Entity Id blank in Alation, the default is https://www.alation.com — configure the same value as the audience in your IdP.

AssumeRoleWithSAML fails with “Access Denied” or “Not authorized”

The IAM role’s trust policy SAML:aud condition is set to https://signin.aws.amazon.com/saml (the AWS Console SSO URL). Change it to https://<your_alation_url>/api/v2/auth/callback/ to match the Alation SAML audience.

Chat connection breaks after a period of time

STS tokens have a limited lifetime controlled by the STS Duration setting in the Alation auth config (default 3600 seconds). After expiration, you must re-authenticate via SSO. Ensure the IAM role’s Maximum session duration in AWS is greater than or equal to the STS Duration you configured.

Note

Leave the SAML authenticate request XML field blank in the Alation authentication configuration. The auth service generates its own SAML AuthnRequest. Do not paste the full IdP metadata XML into this field — it exceeds the 3000-character limit and is not required.

Note

Multi role flow: When enabled in the Alation auth config, if the SAML assertion contains multiple IAM roles, Alation displays a role selector so the user can choose which role to assume. Each user gets the permissions of the single role they select — not all roles combined. If the assertion contains only one role, selection happens automatically.