This section includes a general guide for configuring an OpenID provider and guides for specific OpenID providers in Immuta. The getting started section below provides best practices for setup and configuration.
Start by creating a few initial subscription and data policies so that you know the user metadata you will need from your IAM. For example, will user attributes be used to author policies, or will groups also be needed? The subscription and data policies below illustrate the need for both groups and attributes to be imported from the IAM to enforce appropriate access controls:
Subscription policy: Allow all users in the Marketing group to access data sources tagged Marketing.
Data policy: Mask all columns tagged Location except for users with the attribute AccessLevel.Gold.
If your provider is not listed or does not support SCIM, reach out to your Immuta representative for guidance.
with SCIM enabled. Guides for specific providers are linked below.
Once your IAM is configured, complete one of the following tasks:
Administrator account in Okta
Log in to Okta as an Admin, navigate to the Applications tab, and click Add Application.
Search for Immuta in the search bar and click Add.
Choose a name for your integration and click Next. Then select the OpenID Connect button.
Attribute matching allows you to determine how to uniquely identify a user in Okta and match that user in Immuta during login and provisioning. Immuta supports the following matching attributes in Okta:
Users:
id
userName
Using any other attribute in Okta as a matching attribute results in an error. See the for details about attribute matching and how to configure it.
Log in to Immuta and click the App Settings icon in the navigation menu.
Click the Add IAM button and enter a Display Name.
Select OpenID from the Identity Provider Type dropdown menu.
For details about the configuration options below and additional configuration options, see the .
In the Identity Management section of the Immuta console, enter the Client ID and Client Secret you copied from Okta in the previous section.
Enter the following URL in the Discover URL field: https://<your_okta_workspace.com>/.well-known/openid-configuration.
Opt to add additional Scopes.
Multiple user accounts cannot have the same email address
If you register user accounts that have the same email address as an existing Immuta user account, the email field for the subsequent user accounts will be left empty. For more details, see the .
Click the Test Connection button.
Once the connection is successful, click the Test User Login button. Because this test button attempts to log in, a user or group must be assigned to the application in Okta that you have login access for.
Click Save.
Editing your IAM configuration
With the exception of the IAM ID (also called the display name), any of these 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 .
Scroll down and enter the Base URL for your Immuta tenant.
Enter the IAM ID for your Immuta OIDC integration (if you have not created an IAM ID, you will complete that step in the next section).
Click Done and once the page reloads, navigate back to the Sign On tab and copy down the Client ID and Client secret.
email
displayName
emails[type eq "work"].value
Groups
id
displayName
Opt to Enable SCIM support for OpenID by clicking the checkbox, which will generate a SCIM API Key. 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.
Copy the SCIM URL and API key generated, and then save your changes.
Validate the URL and credentials within the identity provider application.
In the Profile Schema section, map attributes in OpenID 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:
User's Databricks Username
User's Snowflake Username
User's Trino Username
User's Azure Synapse Analytics Username
User's Redshift Username
User's BigQuery Username
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.
: 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.
User's PostgreSQL Username
User's Teradata Username
Opt to Allow Identity Provider Initiated Single Sign On to use the IDP-Initiated SSO feature by selecting the checkbox.
Opt to Migrate Users from another IAM by selecting the checkbox.
Navigate to the Immuta App Settings page.
Scroll to the Identity Management section and click Add IAM.
Complete the Display Name field and select OpenID from the Identity Provider Type dropdown.
Take note of the ID and copy the SSO Callback URL to use as the ACS URL in your identity provider.
Enter the Client ID and Client Secret from your identity provider.
Enter the URL of your identity provider's discovery endpoint in the Discover URL field. If you do not provide this URL, you will have to complete the manual endpoint specification fields (authorization endpoint, issuer, token endpoint, etc.).
Opt to add additional Scopes.
Enable SCIM support for OpenID by clicking the checkbox, which will generate a SCIM API Key. 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.
Copy the SCIM URL and API key generated, and then save your changes.
Validate the URL and credentials within the identity provider application.
In the Profile Schema section, map attributes in OpenID 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:
User's Databricks Username
User's Snowflake Username
User's Trino Username
User's Azure Synapse Analytics Username
User's Redshift Username
User's BigQuery Username
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.
: 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.
User's PostgreSQL Username
User's Teradata Username
Opt to Allow Identity Provider Initiated Single Sign On to use the IDP-Initiated SSO feature by selecting the checkbox.
Opt to Migrate Users from another IAM by selecting the checkbox.
Click Test Connection 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.
Save your configuration.
Multiple user accounts cannot have the same email address
If you register user accounts that have the same email address as an existing Immuta user account, the email field for the subsequent user accounts will be left empty. For more details, see the Identity managers reference guide.
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.
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.
Navigate to the App Settings page in the Immuta console and click the Add IAM button.
Complete the Display Name field and select OpenID from the Identity Provider Type dropdown.
Adjust Default Permissions granted to users by selecting from the list in this dropdown menu.
Navigate to OneLogin, click Administration, and then select Applications from the Applications menu.
Click Add App in the top right corner of the screen. Search for and select OpenID Connect (OIDC).
Complete the Display Name field and click Save.
For details about the configuration options below and additional configuration options, see the .
From the Identity and Access Management window in your Immuta tenant, copy the SSO Callback URL to your clipboard.
Return to OneLogin, click the Configuration tab in the left panel, and paste the URL in the Login Url and Redirect URI's fields.
Click Save in the top right corner of this screen.
Multiple user accounts cannot have the same email address
If you register user accounts that have the same email address as an existing Immuta user account, the email field for the subsequent user accounts will be left empty. For more details, see the .
Click the SSO tab in the left panel of your OneLogin account. Copy the Client ID and the Client Secret and paste these values in the corresponding fields in your Immuta tenant.
Then, right click the Well-known Configuration text from the SSO tab of OneLogin, and copy the link to your clipboard.
Return to your Immuta tenant, and paste this link in the Discover URL field; pasting this link here prevents you from having to manually fill out the rest of the form.
Confirm email as the User ID claim, and fill out the Scopes section.
Return to OneLogin and scroll to the Token Endpoint section. Select POST from the Authentication Method dropdown.
Click Save.
Return to your Immuta console, opt to Enable SSL and Enable SCIM support for OpenID. 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.
Copy the SCIM URL and API key generated, and then save your changes.
Validate the URL and credentials within the identity provider application.
In the Profile Schema section, map attributes in OpenID 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:
User's Databricks Username
User's Snowflake Username
User's Trino Username
User's Azure Synapse Analytics Username
User's Redshift Username
User's BigQuery Username
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.
: 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.
User's PostgreSQL Username
User's Teradata Username
Opt to Allow Identity Provider Initiated Single Sign On, External Groups and Attributes Endpoint, and Migrate Users.
Click Test Connection. Once the connection is successful, click Test User Login. Because this test button attempts to log in, a user or group must be assigned to the application in OneLogin that you have login access for.
Click Save.
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.