For the complete documentation index, see llms.txt. This page is also available as Markdown.

SAML Protocol

Connect an identity provider that uses the SAML protocol

Editing your IAM configuration

With the exception of the IAM ID (also called the display name), any of these settings can be changed after an IAM is configured. To edit IAM settings, click the dropdown arrow next to the IAM listed in the identity management section on the app settings page and then make your changes.

For details about the configuration options below and additional configuration options, see the SAML protocol reference guide.

  1. Navigate to the Immuta App Settings page.

  2. Scroll to the Identity Management section and click Add IAM.

  3. Complete the Display Name field and select SAML from the Identity Provider Type dropdown.

  4. Take note of the ID and copy the SSO Callback URL to use as the ACS URL in your identity provider.

  5. Complete the Entry Point field. This is the location of your single sign on application that will be redirected to from the Immuta login page.

  6. Upload your Signing Certificate. This is your identity provider's public signing certificate.

  7. Enable SCIM support for SAML. Validate that the usernames in your IAM match those in your data platform (Snowflake, Databricks, etc.). If they are incorrect in the IAM or the casing doesn't match, fix the data platform username in the identity provider before configuring SCIM in Immuta.

    1. Copy the SCIM URL and API key generated, and then save your changes.

    2. Validate the URL and credentials within the identity provider application.

  8. After enabling SCIM, opt to map a custom SCIM attribute into Immuta in the Agent Identifier section to identify user accounts as agents. If you don't replace the default values with your own in the fields listed below, users that have userType with a value of AI_Agent will be treated as an agent in Immuta. Agentic data access is in private preview and must be enabled in your tenant for this section to appear.

    • SCIM Attribute: The name of your custom attribute. userType is the default value.

    • Identifying Value: The value to pass to Immuta to identify the user as an agent. AI_Agent is the default value.

  9. In the Profile Schema section, map attributes in SAML to automatically fill in a user's Immuta profile. Note: Fields that you specify in this schema will not be editable by users within Immuta.

    If usernames in your data platform align with usernames in an external IAM and those accounts align with an IAM attribute, enter the IAM attribute in the field that corresponds to your data platform:

    1. User's Databricks Username

    2. User's Snowflake Username

    3. User's Trino Username

    4. User's Azure Synapse Analytics Username

    5. User's Redshift Username

    6. User's BigQuery Username

    7. User's AWS User. After entering the IAM attribute in the User's AWS User field, click the Select AWS User Type from the dropdown and select one of the types below. This is used by the Amazon S3 Integration to map users in Immuta to the corresponding user type in AWS.

      • None (fallback to Immuta username): When selecting this option, the AWS username is assumed to be the same as the Immuta username.

      • AWS IAM role: Only a single Immuta user can be mapped to an IAM role. This restriction prohibits enforcing policies on AWS users who could assume that role. Therefore, if using role principals, create a new user in Immuta that represents the role so that the role then has the permissions applied specifically to it.

      • AWS Identity Center user IDs: You must use the numeric User ID value found in AWS IAM Identity Center, not the user's email address.

    8. User's PostgreSQL Username

    9. User's Teradata Username

  10. Click the Test Connection button and Test User Login. Because this test button attempts to log in, a user or group must exist in your identity provider that you have login access for.

  11. Save your configuration.

Last updated

Was this helpful?