Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
Validate that your provider is supported by Immuta and supports SCIM. If your provider is not listed or does not support SCIM, reach out to your Immuta representative for guidance.
Configure your OpenID provider in Immuta with SCIM enabled. Guides for specific providers are linked below.
Once your IAM is configured, complete one of the following tasks:
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.
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.
Adjust Default Permissions granted to users by selecting from the list in this dropdown menu.
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.
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.
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.
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.
Save your configuration.
Okta LDAP Interface is a built-in Okta integration that enables you to expose your Okta directory over standard LDAP wire. The Okta LDAP Interface exposes the entire Okta directory.
The LDAP interface is not an isolated application
This means that you cannot manage the assignment of users and groups to the LDAP Interface the same way you would in a web application. Instead, you should be able to leverage LDAP filters to moderate access to applications that call the LDAP Interface (i.e., filtering user attributes and groups.)
Go to the Admin Console in your Okta account.
Select Directory, and then click Directory Integrations.
Select Add Directory and Add LDAP Interface. You will be presented with the details required to make a successful LDAP connection.
Create a service account
Create a service account to use as your LDAP bind user; any Okta admin with the "view users" permission can serve the role. Choose the Read-Only Admin to grant the least privilege.
Navigate to the App Settings page in Immuta.
Click the Add IAM button.
Complete the Display Name field and select LDAP/Active Directory from the Identity Provider Type dropdown.
Adjust Default Permissions granted to users by selecting from the list in this dropdown menu, and then complete the required fields in the Credentials and Options sections. Note: Either User Attribute OR User Search Filter is required, not both. Completing one of these fields disables the other.
Opt to have Case-insensitive user names by clicking the checkbox.
Opt to Enable Debug Logging or Enable SSL by clicking the checkboxes.
In the Profile Schema section, map attributes in LDAP/Active Directory 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.
Opt to enable the following settings by selecting their checkboxes:
Enable scheduled LDAP Sync support for LDAP/Active Directory
Require manual approval before a user can use Immuta
Enable pagination for LDAP Sync: Once enabled, confirm the sync schedule written in Cron rule; the default is every hour. Confirm the LDAP page size for pagination; the default is 1,000.
Sync groups from LDAP/Active Directory to Immuta: Once enabled, map attributes in LDAP/Active Directory to automatically pull information about the groups into Immuta.
Sync attributes from LDAP/Active Directory to Immuta: Once enabled, add attribute mappings in the attribute schema. The desired attribute prefix should be mapped to the relevant schema URN.
External Groups and Attributes Endpoint
Make Default IAM
Migrate Users from another IAM
Click the Test Connection button.
Once the connection is successful, click the Test User Login button.
Click the Test LDAP Sync button if scheduled sync has been enabled.
Click Save and confirm your changes.
To enforce directory-wide MFA, create an authentication policy in Okta (if you do not yet have MFA policies in place).
Navigate to Security in the Okta Admin console.
Select Authentication, and then click Sign On.
Note: If you enforce MFA on the user that’s configured as your LDAP bind user, the integration won’t work. You will therefore need to make that user exempt in your MFA policies.
This section includes a general guide for configuring a SAML provider and guides for specific SAML 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.
Validate that your provider is supported by Immuta and supports SCIM. If your provider is not listed or does not support SCIM, reach out to your Immuta representative for guidance.
Configure your SAML provider in Immuta with SCIM enabled. Guides for specific providers are linked below.
Once your IAM is configured, complete one of the following tasks:
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.
There are additional configuration options available for the SAML 2.0 protocol than are referenced in this guide, which only outlines the required settings. For details about the additional options, see the SAML protocol configuration options reference guide.
Navigate to the Immuta App Settings page.
Scroll to the Identity Management section and click Add IAM.
Complete the Display Name field and select SAML 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.
Adjust Default Permissions granted to users by selecting from the list in this dropdown menu.
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.
Upload your Signing Certificate. This is your identity provider's public signing certificate.
Opt to 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.
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.
Click Test Connection and Test User Login.
Save your configuration.
An Immuta tenant with version 2020.4 or higher is required to use Immuta's SCIM 2.0 feature.
Users have to be an administrator in Okta to edit or add applications.
The following Okta provisioning features are supported by Immuta:
Import users from Okta: Okta users who had previously been assigned to an Okta application can be imported to your Immuta tenant.
Push users to Immuta: Okta users who are assigned to the Immuta application in Okta are automatically added as members to your Immuta tenant.
Deactivate users in Immuta: Okta users who are unassigned from the Immuta application in Okta or are deleted or deactivated from Okta are automatically deactivated in your Immuta tenant.
Push groups to Immuta: Groups and their members in Okta can be pushed to your Immuta tenant.
Remove groups from Immuta: Groups in Okta are removed from your Immuta tenant when they are no longer mapped to your Immuta application in Okta.
Map user attributes from Okta to Immuta: You can map user attributes between Okta and your Immuta tenant. The mapping will remain synced by detecting profile changes in Okta.
Log in to your Okta instance and click Applications in the menu in the left pane.
Click Browse App Catalog, and then search for and select Immuta.
Click Add.
In General Settings, opt to change the Application label. Then, click Next.
Click View Setup Instructions and complete the tutorial to configure the IAM in Immuta. Note: You will complete all steps outlined for the Immuta App Settings page except Test User Login. You cannot test the login or save the IAM configuration in Immuta until you have added yourself as a user to the application in Okta. These steps are outlined in the next section.
In the Okta console under Advanced Sign-on Settings, fill in the following fields.
Base URL (typically your Immuta tenant URL)
IAM ID (found on the Immuta App Settings page)
Click Done.
Attribute matching allows you to determine how to uniquely identify a user in Okta and match that user in Immuta at login and during provisioning. Immuta supports the following matching attributes in Okta:
Users:
id
userName
email
displayName
emails[type eq "work"].value
Groups
id
displayName
Using any other attribute in Okta as a matching attribute results in an error. See the Okta documentation for details about attribute matching and how to configure it.
Click the Assignments tab.
Click Assign and then Assign to People.
Enter your name in the search field to filter results, and then click Assign.
Click Save and Go Back, and then click Done.
Return to the Immuta console and click Test User Login. Once this test passes, click Save.
Navigate to the App Settings page in Immuta, and click the Add IAM button.
Complete the Display Name field and select SAML as your IAM type from the Identity Provider Type dropdown.
Adjust Default Permissions granted to users by selecting from the list in this dropdown menu, and then complete the required fields in the Client Options section.
Enable SCIM support for SAML 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.
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.
Enable Sync groups from SAML to Immuta and Sync attributes from SAML to Immuta by selecting the checkboxes, and then click the Test Connection button.
Once the connection is successful, click the Test User Login button.
Before you save the configuration, store the SCIM information that displays on the Immuta App Settings page, as it will be used in subsequent steps.
In Okta, navigate to your application and click the Provisioning tab.
Click Configure API Integration and then select the Enable API integration checkbox.
Fill in the following fields:
Base URL (found on the Immuta App Settings page as SCIM URL)
API Token (found on the Immuta App Settings page as SCIM Api Key)
Click Test API Credentials.
Once that test passes, click Save.
You will automatically navigate to the Provisioning tab. To make sure everything syncs as expected, select To App in the Settings pane, click Edit, and enable the following fields:
Create Users
Update User Attributes
Deactivate Users
Click Save.
Syncing current users in Okta
Once SCIM is enabled in Okta, it only works for changes in Okta going forward. To get your current users to sync, navigate to the Assignment tab and click Provision User in Okta. Existing users (or any new users you add/remove) should now display in Immuta under this external IAM.
Using the same group to assign users to Okta (groups added to the Okta Assignments tab) and to push groups and users to Immuta (groups added to the Okta Push Groups tab) is not supported. See the Okta troubleshooting guide for details.
The Okta directory cannot be synced with Immuta's internal IAM (BIM). You must configure an external IAM in Immuta to push users and groups from Okta to Immuta.
You should create a new Immuta IAM and a new Okta application for Immuta to set up the provisioning. An existing setup can cause discrepancies between the Okta directory and the app, leading to syncing failures.
When making a GET request for a user, there are extra attributes in the response.
Add users in Okta SCIM
Navigate to your application in Okta and click the Assignments tab.
Click Assign and then Assign to People.
Enter the name of the user you would like to add in the search field and click Assign.
Click Save and Go Back, and then click Done.
The user has been added to your application in Okta and displays as a user in Immuta under this external IAM.
Remove users from Okta SCIM
Click the delete icon next to the user you want to remove.
When prompted to make sure you want to delete this user, click OK.
This user is removed from your application in Okta and displays as disabled in Immuta under this external IAM.
Group sync
Groups will automatically sync in Immuta for any users added to the SCIM application if
Push Groups in Okta is enabled
Sync Groups is enabled in Immuta
Add users to groups
In Okta, navigate to your application and click on the Assignments tab.
Click on the name of the user whose groups you want to update.
Click on the Groups tab.
To add a new group, start to type the name of an existing group in the search field, and when it displays, click Add.
This group has been added to the user in Okta. It will also automatically appear in Immuta for the same user.
Remove users from groups
In Okta, navigate to your application and click the Assignments tab.
Click the name of the user whose groups you want to update, and then navigate to the Groups tab.
Click the delete icon next to the group you want to remove for this user.
This group has been removed from the user in Okta, and it will automatically be removed from this user in Immuta.
Add attributes to users
In Okta, navigate to your application and click To App on the Provisioning tab.
Click the Go to Profile Editor button.
Click Add Attribute and fill in the following fields:
Data type (defaults to string).
Display name.
Variable name.
External namespace. This field has to be formatted using a special schema format (e.g., urn:ietf:params:scim:schemas:extension:enterprise:2.0:DEMOEXT). Copy this information; you will need it for Immuta configuration.
Click Save.
By default, the value for this attribute is empty. Follow the Adding Attribute Values section to add values.
Update the SCIM attribute schema in Immuta
In Immuta, navigate to the App Settings page and edit your SCIM configuration.
Scroll to the Attribute Schema section under Sync Attributes.
Click Add Attribute and complete the following fields:
SCIM Schema: <found on the Okta SCIM attribute page (in the previous section)>
IAM Immuta Attribute Prefix: this can be anything you want
Click Test Connection and then Test User.
Save your changes.
Add attribute values
After adding attributes to users and updating the SCIM Attribute Schema in Immuta,
In Okta, navigate to the Assignments tab for your application and click the edit icon next to the user you want to update attributes for.
Scroll to the attribute you created and add a value in the textbox.
Save your changes.
Now that this attribute has been added to the user in Okta, it will automatically appear in Immuta for the same user.
You must configure a SCIM application and enable sync attributes before syncing external usernames.
In Immuta, navigate to your Okta SCIM configuration on the App Settings page.
Under Sync attributes from SAML to Immuta, add an attribute for the field you would like to map to an external username.
Copy and paste the resulting attribute for the desired external username.
Click Test Connection and then Test User.
Save your changes.
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.
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.
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.
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.
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.
Click Save.
Administrator account in Okta.
Immuta's OpenID Connect integration supports the following features
Service Provider (SP)-Initiated Authentication (SSO) Flow
Identity Provider (IDP)-Initiated Authentication (SSO) Flow
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.
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.
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
email
displayName
emails[type eq "work"].value
Groups
id
displayName
Using any other attribute in Okta as a matching attribute results in an error. See the Okta documentation for details about attribute matching and how to configure it.
Log in to Immuta and click the App Settings icon in the left sidebar.
Click the Add IAM button and enter a Display Name.
Select OpenID from the Identity Provider Type dropdown menu.
If required, navigate back to Okta and enter the IAM ID below the Base URL then complete the steps from the Okta section.
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.
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.
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.
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 the Test Connection button.
Once the connection is successful, click the Test User Login button.
Click Save.
Immuta can integrate with Microsoft Entra ID as an IAM over SAML 2.0. This page outlines how to register Immuta as an Azure Enterprise Application with Single Sign-On over SAML 2.0.
Microsoft Azure subscription: Microsoft Azure requires a Premium subscription to create a non-gallery application, which is essential for this integration.
In the Microsoft Azure portal, browse to Enterprise Applications.
Click the New Application button and then select Create your own application.
Name the application with the name of your choice, select Integrate any other application you don't find in the gallery (Non-gallery), and click Create.
On the left menu, choose the Single sign-on menu item and then pick the SAML tile.
In the first section (Basic SAML Configuration), click the Edit icon and fill in Identifier (Entity ID) field with the full URI of your Immuta app (e.g., https://immuta.my-comany.com).
In the second section (User Attributes & Claims), specify the unique user identifier you want to use in Immuta. Common choices are the mail claim or the userprincipalname claim. You can also specify the user claims you want Azure to expose to Immuta. You will use the names of those claims to map them to Immuta user attributes when you .
In the third section (SAML Signing Certificate), click the Download link next to Certificate (Base64) and save the file on your hard drive:
In the fourth section, copy the Login URL and save it for when you will through the Immuta UI.
Now that you have an enterprise application in place, continue to create and configure an IAM in Immuta. You will need a few details from the Immuta UI to complete the configuration of the enterprise application.
Attribute matching allows you to determine how to uniquely identify a user in Microsoft Entra ID and match that user in Immuta at login and during provisioning. Immuta supports the following matching attributes in Microsoft Entra ID:
Users:
id
userName
email
displayName
emails[type eq "work"].value
Groups
id
displayName (See the below for group names.)
In Immuta, browse to App Settings, go to the Identity Managers section, and click Add IAM
Assign a name to the new IAM. Immuta will automatically derive the ID of the IAM from the name you pick.
Select SAML in the Identity Provider Type drop-down.
Start configuring the new IAM:
Default Permissions: The default permission that should be assigned to a Microsoft Entra ID user in Immuta.
Issuer: This field needs to have the same value as the Identifier (Entity ID) of the enterprise application (e.g., https://immuta.my-comany.com).
Entry Point: Paste the Login URL that you obtained in the previous section.
User ID Attribute: This field is the attribute that will contain the username of the user logging in.
Signing Certificate: Upload the certificate file you have previously downloaded and converted into a PEM encoded certificate.
Decryption Private Key: This field is the optional key for decrypting attribute assertions.
Enable SCIM support for SAML: Opt to enable SCIM support. 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.
Profile Schema: 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.
Enable any optional settings:
Link SQL
Allow Identity Provider Initiated Single Sign On: After checking this option, set disableRequestedAuthnContext to true under Additional Config Parameters.
Sync groups from SAML to Immuta
Sync attributes from SAML to Immuta: After selecting this checkbox, map your Entra ID attributes to Immuta in the Attribute Schema section.
External Groups and Attributes Endpoint
Before you can test the integration and save the new IAM, you will need to go back to the Microsoft Azure Portal and fill in the Reply URL.
In the Single sign-on page of your enterprise application, edit the first section with the title Basic SAML Configuration.
Fill in the Reply URL (Assertion Consumer Service URL) field with a value that adheres to the following format: ${IMMUTA_URL}/bim/iam/${IAM_ID}/user/authenticate/callback. For example, if the URL to your Immuta tenant is https://immuta.my-comany.com and the assigned IAM ID is MicrosoftEntraID, the value of the Reply URL field should be https://immuta.my-comany.com/bim/iam/MicrosoftEntraID/user/authenticate/callback. To save the changes, click Save. You can find the IAM ID that Immuta has assigned to the IAM in the form.
You should now be able to test the IAM and save it. After clicking Test Connection and letting Immuta hit the enterprise application URL, you will need to verify that the authentication flow works before you can save and create the IAM. To do so, click Test User Login and follow the instructions.
Save the changes in Immuta.
SCIM will skip updates and will not inform Immuta that an attribute should be removed from a user in the following scenarios, even if the attribute mapping has been deleted from the IAM configuration on the Immuta app settings page:
Attribute is set to empty (removed) in Microsoft Entra ID
Attribute is deleted in Microsoft Entra ID
In both of these scenarios, Azure doesn’t send Immuta a payload to remove the attribute, as it considers the action a redundant export. As a result, the attribute values that previously existed in Microsoft Entra ID will not get removed from the user in Immuta.
To remediate this limitation, take one of the following actions:
Change the attribute to a non-impacting value other than empty in Microsoft Entra ID.
Group names containing " are unsupported in the Microsoft Entra ID integration.
Using any other attribute in Microsoft Entra ID as a matching attribute results in an error. See the for details about attribute matching and how to configure it.
Alternatively, remove the . Then, trigger an update for that user in Microsoft Entra ID by making a change to any value for that user. Microsoft Entra ID will send an update for that user to Immuta, and Immuta will remove the attribute from the user. Note that if that attribute mapping is ever re-added in Immuta on the app settings page, that attribute will be added to the user again.
See for more details about this limitation.
