Identity Management Overview
You can connect your existing identity provider to Immuta to use that system for user authentication and authorization.
Each identity provider you configure in Immuta is assigned a unique identifier, and all users, groups, and attributes are associated with one IAM ID. The synchronization between Immuta and your external identity provider is one-way: changes made to your users' entitlements or users added in Immuta will not be reflected in your external identity provider.
Immuta's built-in IAM
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 create policies. The Immuta IAM is enabled by default.
IAM protocol support matrix
Immuta supports LDAP, OpenID Connect, and SAML protocols. The table below illustrates the features supported by each IAM protocol.
SCIM 2.0 support for provisioning (users and groups)
❌
✅
✅
Periodic directory sync for provisioning (users and groups)
✅
❌
❌
Read ALL directory groups for policy authoring
✅
✅
✅
Consume attributes and groups from arbitrary sources
✅ Requires an external user info service
✅ Requires an external user info service (and is only supported if not using SCIM)
✅ Requires an external user info service (and is only supported if not using SCIM)
IAM provider support matrix
The table below illustrates common providers that support the protocols listed above. However, this list may not be all-inclusive. If a provider stops supporting a protocol, Immuta may not fully support that provider.
Active Directory
✅
❌
❌
❌
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.
❌
✅
✅
❌
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.
❌
✅
❌
❌
Centrify
✅
✅
✅
❌
JumpCloud
✅
✅
✅
❌
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.
❌
✅
✅
❌
Microsoft Entra ID
❌
✅
✅
✅
Okta
✅
✅
✅
✅
OneLogin
✅
✅
✅
✅
OpenLDAP and other LDAP servers
✅
❌
❌
❌
Oracle Access Manager
❌
✅
✅
✅
Ping Identity
✅
✅
✅
✅
Identity provider general configuration options
Identity providers are configured on the Immuta app settings page, where you can map your users' groups and attributes from your identity provider into Immuta for use in access control policies and manage other general settings:
Attribute mapping: Map user attributes from your identity provider to Immuta.
Group mapping: Map groups from your identity provider to Immuta.
Profile schema mapping: Map user profile details into Immuta.
External groups and attributes endpoint: Use your identity provider for authentication, but retrieve users' groups and attributes from another resource using an external REST endpoint.
Default user permissions: Control what permissions each user who logs in receives by default.
Migrating users: Migrate user accounts from one identity provider configured in Immuta to another.
For details about settings specific to a protocol, see the LDAP, OpenID Connect, or SAML protocol reference guide.
Attribute mapping
Attribute mapping allows you to synchronize attributes from your identity provider to Immuta.
Attribute mapping for OpenID Connect is only available when SCIM is enabled and differs slightly from attribute mapping without SCIM enabled. See the OpenID Connect protocol reference guide for details.
Group mapping
Group mapping allows you to synchronize groups from your identity provider to Immuta. If you enable group synchronization for your identity provider, you will configure the group schema by specifying the LDAP, SAML, or OpenID Connect attribute that contains users' groups to define how those groups are mapped in Immuta.
To map OpenID Connect groups into Immuta, SCIM must be enabled. See the reference guide for the LDAP, SAML, or OpenID Connect protocol for details and examples.
Profile schema mapping
You can map user profile attributes from your source identity provider into the user profile page in Immuta. Profile schema attributes provide general purpose user information (such as email, phone number, and location) and cannot be used as entitlements for policies.
External groups and attributes endpoint
An IAM provider can be used for authentication and combined with an external REST endpoint to retrieve user groups and attributes. This option provides flexibility in how groups and attributes are associated with users in Immuta.
To connect an external REST endpoint to Immuta, see the Configure an external user info endpoint guide.
Default user permissions
Each identity manager supports the configuration of default permissions, which 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. Alternatively, group permissions may be configured, in which case permissions will be evaluated based on the groups users belong to.
If 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.
Migrating users
This setting allows application admins to migrate user accounts from one identity manager configured in Immuta 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 [email protected], their user ID in the new IAM should be [email protected]. 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.
SCIM support
Sync attributes and groups
When enabling SCIM, syncing attributes and groups is automatically enabled, and you cannot disable those settings. Otherwise, the IAM performing provisioning would continue to try to perform updates that are otherwise blocked.
When configuring a provider that uses the SAML or OpenID Connect protocol, 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, this API key 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.
Microsoft Entra ID limitation
SCIM and Microsoft Entra ID
In some instances, updates in Microsoft Entra ID 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, Microsoft Entra ID 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.
Omit personally identifiable information
Immuta recommends that you omit any personal data or data that is otherwise personally identifiable from groups or attribute keys, as that information is revealed to policy authors in the Immuta UI and certain Immuta AI capabilities.
Immuta is not responsible for inadvertent disclosures of such data related to the foregoing.
Limitations
Immuta does not support adding duplicate external usernames from different IAMs in a single Immuta tenant. If duplicate external usernames from different IAMs are registered in Immuta and mapped to one or more users, those users will receive an error like the following when they attempt to query Immuta-protected data:
Single-row subquery returns more than one row.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:
User A is registered in Immuta first with the email address [email protected].
User B is registered later in Immuta with the email address [email protected].
In this example, User B's email field would be left empty in Immuta.
This scenario typically happens if an admin user creates an account for themselves in Immuta using Immuta's built-in identity provider, and then they connect their existing identity provider that includes another user account for themselves with the same email address.
Last updated
Was this helpful?