The following options are available when setting up an identity provider that uses the SAML 2.0 protocol.
Allow identity provider initiated single sign on: When enabled, users authenticate once in their identity provider and can log in to Immuta.
Allow identity provider initiated single logout: When enabled, users can log out of Immuta or their identity provider and simultaneously log out of other applications. Additional configuration settings will appear when this checkbox is selected:
Logout URL: The URL of your single sign on application that will be redirected to after you log out of Immuta, as some identity providers differentiate between the logout and authorization URLs.
SLO binding URL: The URL Immuta displays that you can add to your identity provider to specify where to send requests or responses to Immuta's SLO requests.
Encryption private key: An optional private key to encrypt requests.
Decryption private key: The private key for decrypting attribute assertions from the identity provider.
Display name: The internal ID of the identity manager in Immuta. This setting cannot be changed once the configuration is saved.
Entry point: The URL of your single sign on application that the Immuta login page will redirect to.
External groups and attributes endpoint: A REST endpoint that Immuta will use to retrieve a user's groups and attributes.
Issuer: The URL of the identity provider that issues assertions for authentication.
Migrate users: Migrate users from a previously configured identity provider to the current identity provider.
SCIM support: When enabled, your identity provider automatically creates new users in Immuta and updates existing user accounts, whether or not users log in to Immuta. When you click this checkbox, Immuta generates a SCIM API key.
Signing certificate: Your identity provider's public signing certificate.
Sync attributes from SAML to Immuta: Allows attributes added in your identity provider to be synced with Immuta.
Attribute delimiter: The character used to split values in a string of attributes. After enabling sync attributes, providing delimiters for attributes is required.
Attribute prefix: The prefix used for attribute keys.
Sync groups from SAML to Immuta: Allows groups added in your identity provider to be synced with Immuta.
Group attribute: The attribute that contains the user's group. Enable sync groups from SAML to Immuta to make this option available.
User ID attribute: The attribute that contains the user's username.
Best practice: Identity access management
Organize user attributes and groups in Immuta and then transfer them to your IAM.
Note: User Admins can add attributes in Immuta to external IAM groups using the Add Attributes button.
Attributes can be added to individual users or groups and then included in Data policies and Subscription policies to restrict what data users can see. They can be created by a User Admin in the Immuta UI or mapped in from an external IAM.
To learn how to add attributes to a user or group, navigate to the tutorial.
Individual users are added into groups, and then groups are used in Data policies and Subscription policies to restrict what data users in each group can see. Groups are also used in assigning members to projects. Users can belong to any number of groups and can be added or removed from groups at any time.
To learn how to create a group, navigate to the tutorial.
The SAML 2.0 single logout (SAML SLO) protocol allows identity providers to terminate sessions across a user's applications nearly simultaneously with a single logout request.
SAML SLO enabled in Immuta can minimize security risks by terminating abandoned sessions after a timeout event occurs or after a user logs out of their identity provider or another application. Once users are logged out of Immuta, they must re-authenticate to log back in.
Immuta APPLICATION_ADMIN permission
An identity provider that supports the SAML protocol. See this list of supported identity providers and their protocols.
There are two logout processes for SAML SLO:
Application-initiated logout: A user logs out from a service provider.
Identity-provider-initiated logout: A user logs out from their identity provider.
The following objects are referenced in both processes below:
Principal: A user, service, or process that must authenticate with a service before being granted access and privileges.
Service provider (or session participant): The service or application the principal wants to be granted access to (for example, Immuta).
Session authority (or identity management provider): The identity management provider that verifies the principal's identity. See this list of supported identity providers for examples.
Session: The period during which the principal is authenticated with the service provider; a session is started when a user authenticates their identity using a password or another authentication protocol and the service provider has verified that the user is allowed access to their service.
Immuta's SAML SLO support has been tested with the following identity providers:
Key Cloak
Microsoft Entra ID
See your identity provider's documentation to determine whether or not your provider supports SAML SLO. For a list of identity providers and protocols supported by Immuta, see the identity management support matrix.
Immuta cannot ensure that other service providers will log out, as Immuta has no control over those applications.
Identity managers are used with Immuta to provide authentication and fine-grained user entitlement. A number of identity managers can be configured and enabled in Immuta, each with a specific set of configuration options that enable Immuta to communicate with the IAM system and map the users, permissions, groups, and attributes into Immuta.
The Immuta IAM can be used as a complete solution for authentication and authorization. Group and attribute values within the Immuta IAM can be used to broker access to projects and data sources and to drive policies.
The Immuta IAM is enabled by default, so there are no additional configuration options needed to support this mode.
External identity managers configured in Immuta allow users to authenticate using an existing identity management system and can optionally be used to synchronize user groups and attributes into Immuta. The synchronization between Immuta and your external IAM is one-way: changes made to your users' entitlements or users added in Immuta will not be reflected in your external IAM. Each identity manager configured in Immuta is assigned a unique identifier, referred to as the IAM ID, and all users, groups, and attributes are associated with exactly one IAM ID.
The table below illustrates the features supported by each IAM protocol.
| Feature | AD/LDAP | SAML 2.0 | OpenID Connect 1.0 |
|---|---|---|---|
The table below illustrates common providers that support the protocols listed above. However, this list may not be all-inclusive, and if a provider stops supporting a protocol, Immuta may not fully support that provider.
Identity managers are added from the App Settings page. Features like default permissions, profile schema, group schema, group permissions, and external groups and attributes endpoint are managed from the App Settings page as well.
Each identity manager supports the configuration of default permissions. This configuration setting controls what permissions each user who logs in receives by default. These permissions are applied the first time each user logs in, and any changes to the default permissions will only apply to new users.
In the case where the default permissions are empty, new users receive no special permissions in Immuta and an administrator will need to grant them any permissions that they need. Alternatively, group permissions may be configured, in which case permissions will be evaluated based on the groups users belong to.
On the App Settings page, Application Admins can migrate user accounts from one identity manager to another.
Once this setting is enabled, Immuta checks user IDs when users log in against the IAM they are migrating from, so the user IDs for these accounts must match. (For example, if their userID in Immuta's built-in IAM is consumer@example.com, their user ID in the new IAM should be consumer@example.com.) Then, users' profiles will be moved to the new IAM, including their subscriptions, permissions, and pending requests.
If a user does not have an exact user ID match, a User Admin can manually migrate their account.
Immuta's Best Practices: Sync Attributes and Groups
When enabling SCIM, it is best to enable sync attributes and groups. If this is not done, the IAM performing provisioning will likely continue to try to perform updates that are otherwise blocked.
When configuring a SAML or OpenID IAM, Application Admins can enable SCIM support, which allows these IAMs to automatically create new users in Immuta and keep existing users up-to-date. Once enabled, the majority of the profile schema fields will be hidden and automatically synced from the SCIM response. The API key will be displayed to be used to configure provisioning in the external IAM. After the configuration is saved, it will be hashed. A new key can be regenerated here if the old key is ever lost.
If SCIM support is not enabled in a SAML configuration, administrators must disable relevant users in Immuta if they are removed from the IAM, since the IAM will not send Immuta those updates.
SCIM and Azure
In some instances, updates in Azure are instantly pushed to Immuta. In others, however, pushes update on a schedule (roughly every 40 minutes), and there is more than one sync event (i.e., users may be updated in the first event and user memberships in another).
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.
Alternatively, remove the attribute mapping from the attribute schema section of the IAM configuration on the Immuta app settings page. 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 Known issues for provisioning in Microsoft Entra ID for more details about this limitation.
Attribute mapping for SCIM is slightly different compared to the normal attribute mapping for IAMs. For SCIM mapping, the desired attribute prefix should be mapped to the relevant schema URN:
In Immuta this attribute would translate from SCIM Schema Attribute: “urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:Test” into Immuta Attribute: “scimuser.Test”
LDAP Sync takes an existing and configured LDAP IAM and seeds Immuta with all of its users, subject to the intersection of the IAM's user search filter and the plugin's user search filter. When configuring an LDAP/Active Directory IAM , Application Admins can enable scheduled LDAP Sync; this will allow directory users to be registered within Immuta without the users having to log directly into Immuta.
Once enabled, LDAP Sync will automatically provision and sync users from LDAP on an approved schedule. The default is every hour, but can be adjusted to an organization's needs.
Application Admins can also enable pagination for LDAP Sync, which will be a predetermined page size when searching LDAP during this scheduled sync.
Each identity manager configured has a mapping of attributes from the source system into attributes on the user profile in Immuta.
Profile schema attributes provide general purpose user information and cannot be used as entitlements for policies.
Identity managers that support group synchronization will have a group schema configuration option. This defines how group attributes are mapped in Immuta.
This example is the group schema mapping for an LDAP/Active Directory IAM.
When an identity manager is configured to synchronize groups you will have the option to define a mapping of groups to Immuta permissions. Users who belong to one of the given groups will be granted the listed permissions automatically. Additionally, User Admins can add attributes in Immuta to groups from external IAMs.
If desired, an IAM system can be used for authentication and combined with an external REST endpoint to retrieve user groups and attributes. This option provides flexibility in exactly how groups and attributes are associated with users in Immuta.
Permissions are a system-level mechanism that control what actions a user is allowed to take through the Immuta API and UI. Permissions can be added to any user by a user admin (any user with the USER_ADMIN permission), but the permissions themselves are managed by Immuta and cannot be added or removed in the Immuta UI; however, custom permissions can be created on the app settings page.
The table below illustrates what Immuta permissions map to specific Immuta personas.
| Persona | Permissions | Description |
|---|---|---|
See Manage personas and permissions for guidance on adding and removing permissions.
| SAML SLO protocol | Example |
|---|---|
| SAML SLO protocol | Example |
|---|---|
| Provider | LDAP | SAML 2.0 | OpenID Connect 1.0 | SCIM 2.0 |
|---|---|---|---|---|
1. The principal requests to log out of the service provider, or a timeout event initiates a logout request.
1. User logs out of Immuta.
2. The service provider sends a logout request to the session authority.
2. Immuta sends a logout request to Okta and terminates the user's Immuta session.
3. The session authority validates the signature and data in the request and sends a logout request to all the service providers for the current authenticated session (except the service provider from which the logout was initiated).
3. Okta validates the signature and data in the request and sends a logout request to all the other applications the user is logged in to.
4. The service providers terminate the sessions and send logout responses to the session authority indicating that the users has been logged out.
4. The other applications validate the signature and the data in the request and terminate the user's sessions in their application.
5. The session authority ends its own session with the principal.
5. Okta terminates its own session with the user.
6. The session authority sends a logout response message to the service provider from which the logout was initiated.
6. Okta sends a logout response message to Immuta.
1. The principal requests to log out of the session authority, or a timeout event initiates a logout request.
1. User logs out of Okta.
2. The session authority validates the signature and data in the request and sends a logout request message to all the service providers for the current authenticated session.
2. Okta validates the signature and data in the request and sends a logout request to all applications the user is logged in to.
3. The service providers validate the signature and data in the request and terminate the sessions.
3. Immuta and other applications validate the signature and data in the request and terminate the user's sessions.
4. The service providers terminate the sessions and send logout responses to the session authority indicating that the users has been logged out.
4. Immuta and other applications send a logout response to Okta to indicate the user has been logged out.
5. The session authority ends its own session with the principal.
5. Okta terminates its own session with the user.
Read user groups on user login
Yes
Yes
No - it needs an external user info service.
Read user attributes on user login
Yes
Yes
No - it needs an external user info service.
Provisioning: SCIM 2.0 Support (users & groups)
No
Yes
Yes
Provisioning: Periodic directory sync (users & groups)
Yes
No
No
Read ALL directory groups for policy authoring
Yes
Yes, with SCIM.
Yes, with SCIM.
Consume attributes/groups from arbitrary sources
Yes, with a shim.
Yes, with a shim and only if NOT using SCIM.
Yes, with a shim and only if NOT using SCIM.
Query Engine SSO support
Yes
No - Exception: Okta customers can leverage their Okta LDAP interface to authenticate their users with the Query Engine using LDAP, while using SAML/OIDC-based SSO for the Immuta web application.
No - Exception: Okta customers can leverage their Okta LDAP interface to authenticate their users with the Query Engine using LDAP, while using SAML/OIDC-based SSO for the Immuta web application.
Active Directory
Yes
No
No
No
ADFS This provider only supports authentication with integrations, meaning users can authenticate to their integration, but their attributes will not be synced; attributes will only be synced when users authenticate with the Immuta UI.
No
Yes
Yes
No
Amazon Cognito This provider only supports authentication with integrations, meaning users can authenticate to their integration, but their attributes will not be synced; attributes will only be synced when users authenticate with the Immuta UI.
No
No
Yes
No
Centrify
Yes
Yes
Yes
No
Yes
Yes
Yes
No
JumpCloud
Yes
Yes
Yes
No
Keycloak This provider only supports authentication with integrations, meaning users can authenticate to their integration, but their attributes will not be synced; attributes will only be synced when users authenticate with the Immuta UI.
No
Yes
Yes
No
Microsoft Entra ID
No
Yes
Yes
Yes
Okta
Yes
Yes
Yes
Yes
OneLogin
Yes
Yes
Yes
Yes
OpenLDAP & other LDAP servers
Yes
No
No
No
Oracle Access Manager
No
Yes
Yes
Yes
Ping Identity
Yes
Yes
Yes
Yes
Application admins
APPLICATION_ADMIN
These users have access to the administrative actions for the configuration of Immuta. They can
add external IAMs
configure email settings
Auditors
AUDIT
These users can access audit logs for their entire organization. Data owners can view audit logs for the data sources they own.
Data governors
GOVERNANCE
Data governors set global policies within Immuta, meaning they can restrict the ways that data is used within Immuta across multiple projects and data sources. Governors can also set purpose-based usage restrictions on projects, which can help limit the ways that data is used within Immuta. By default, governors can subscribe to data sources; however, this setting can be disabled on the app settings page to remove the governor's ability to create or subscribe to data sources. Additionally, users can be a governor and admin simultaneously by default, but this setting can also be changed to render the governor and admin roles mutually exclusive.
Data owners
To be a data owner, a user must have one of the following Immuta permissions or be manually assigned ownership of a data source:
CREATE_DATA_SOURCE: Gives the user the ability to create data sources.
CREATE_DATA_SOURCE_IN_PROJECT: Gives the user the ability to create data sources within a project.
Users who are manually assigned as owners of a data source do not need any Immuta permissions.
For data to be available in the Immuta platform, a data owner — the individual or team responsible for the data — needs to connect their data to Immuta. Once data is connected to Immuta, that data is called a data source. In the process of creating a data source, data owners are able to set policies on their data that restrict which users can access the data source, which rows within the data a user can access, and which columns within the data a user can see. Data owners can also view the audit page in Immuta, but they are limited to only viewing records related to the data sources they own.
Data users
Users do not need any permissions assigned to them to subscribe to data sources. However, they can have any of the Immuta permissions described below:
CREATE_FILTER: Gives the user the ability to create and save a search filter.
CREATE_PROJECT: Gives the user the ability to create projects.
IMPERSONATE_HDFS_USER: When creating an HDFS data source, this allows the user to enter any HDFS user name to use when accessing data.
IMPERSONATE_USER: Allows the user to impersonate another user when accessing data.
Data users query data that’s been made available through Immuta.
Project managers
PROJECT_MANAGEMENT
Project Managers oversee projects by creating, approving, or denying purposes in projects and adding and removing project data sources.
User admins
USER_ADMIN
These users have access to the administrative actions for managing users in Immuta. They can
create and manage users and groups
add and remove user permissions
create and manage user attributes
