# 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. {% hint style="info" %} **Immuta's built-in IAM** The Immuta IAM can be used as a complete solution for [authentication and authorization](https://documentation.immuta.com/saas/configuration/people/users-index/reference-guides/personas-and-permissions). 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. {% endhint %} ## IAM protocol support matrix Immuta supports [LDAP](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/ldap-protocol), [OpenID Connect](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/openid-connect-protocol), [SAML](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/saml-protocol), and [SCIM](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/scim-protocol) protocols. The table below illustrates the features supported by each protocol. | Feature | LDAP | OpenID Connect 2.0 | SAML 2.0 | SCIM 2.0 | | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | | **Read user groups and attributes on user login** | :white\_check\_mark: Entitlements will sync without user login if LDAP sync is enabled | :white\_check\_mark: Requires an [external user info service](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/custom-external) | :white\_check\_mark: | :x: | | **Support for automatic provisioning** (users and groups) | :x: | :x: (SCIM must be enabled) | :x: (SCIM must be enabled) | :white\_check\_mark: | | **Periodic directory sync for provisioning** (users and groups) | :white\_check\_mark: | :x: | :x: | :white\_check\_mark: | | **Read ALL directory groups for policy authoring** | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | | **Consume attributes and groups from arbitrary sources** | :white\_check\_mark: Requires an [external user info service](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/custom-external) | :white\_check\_mark: Requires an [external user info service](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/custom-external) (and is only supported if not using SCIM) | :white\_check\_mark: Requires an [external user info service](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/custom-external) (and is only supported if not using SCIM) | :x: | ## 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. | Provider | LDAP | OpenID Connect 2.0 | SAML 2.0 | SCIM 2.0 | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | -------------------- | -------------------- | -------------------- | | **Active Directory** | :white\_check\_mark: | :x: | :x: | :x: | | **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.* | :x: | :white\_check\_mark: | :white\_check\_mark: | :x: | | **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.* | :x: | :white\_check\_mark: | :x: | :x: | | **Centrify** | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | :x: | | **JumpCloud** | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | :x: | | **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.* | :x: | :white\_check\_mark: | :white\_check\_mark: | :x: | | **Microsoft Entra ID** | :x: | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | | **Okta** | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | | **OneLogin** | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | | **OpenLDAP and other LDAP servers** | :white\_check\_mark: | :x: | :x: | :x: | | **Oracle Access Manager** | :x: | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | | **Ping Identity** | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | :white\_check\_mark: | ## Identity provider general configuration options Identity providers are configured on the Immuta app settings page, where you can map your users' [groups](https://documentation.immuta.com/saas/configuration/users-index/reference-guides/attribute-and-group-overview#groups) and [attributes](https://documentation.immuta.com/saas/configuration/users-index/reference-guides/attribute-and-group-overview#attributes) from your identity provider into Immuta for use in access control policies and manage other general settings: * [Attribute mapping](#attribute-mapping): Map user attributes from your identity provider to Immuta. * [Group mapping](#group-schema): Map groups from your identity provider to Immuta. * [Profile schema mapping](#profile-schema-mapping): Map user profile details into Immuta. * [External groups and attributes endpoint](#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](#default-permissions): Control what permissions each user who logs in receives by default. * [Migrating users](#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](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/ldap-protocol), [OpenID Connect](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/openid-connect-protocol), or [SAML](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/saml-protocol) protocol reference guide. ### Attribute mapping Attribute mapping allows you to synchronize attributes from your identity provider to Immuta. * If you enable attribute synchronization for LDAP or SAML, you will configure the attribute schema, which defines how attributes are mapped in Immuta. See the reference guide for the [LDAP](https://documentation.immuta.com/saas/configuration/people/section-contents/ldap-protocol#attribute-mapping) or [SAML](https://documentation.immuta.com/saas/configuration/people/section-contents/saml-protocol#attribute-mapping) protocol for details and examples. * 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](https://documentation.immuta.com/saas/configuration/people/section-contents/openid-connect-protocol#attribute-mapping) 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](https://documentation.immuta.com/saas/configuration/people/section-contents/ldap-protocol#group-mapping), [SAML](https://documentation.immuta.com/saas/configuration/people/section-contents/saml-protocol#group-mapping), or [OpenID Connect](https://documentation.immuta.com/saas/configuration/people/section-contents/openid-connect-protocol#group-mapping) 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](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/custom-external) 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](https://documentation.immuta.com/saas/configuration/people/section-contents/how-to-guides/configure-an-external-user-info-endpoint). ### Default user permissions Each identity manager supports the configuration of default permissions, which controls what [permissions](https://documentation.immuta.com/saas/configuration/users-index/reference-guides/personas-and-permissions#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 `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](https://documentation.immuta.com/saas/configuration/users-index/how-to-guides/managing-personas-and-permissions#migrate-users). ## SCIM support {% hint style="info" %} **Sync attributes and groups** When enabling SCIM, syncing attributes and groups is automatically enabled, and you cannot disable those settings. Otherwise, the identity provider performing provisioning would continue to try to perform updates that are otherwise blocked. {% endhint %} When configuring a provider that uses the [SAML](https://documentation.immuta.com/saas/configuration/people/section-contents/how-to-guides/saml/enable-saml) or [OpenID Connect](https://documentation.immuta.com/saas/configuration/people/section-contents/how-to-guides/openid-connect/openid-connect-protocol) 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. See the [SCIM protocol reference guide](https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/scim-protocol) for more information about SCIM and how it works in Immuta. ## 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](https://documentation.immuta.com/saas/configuration/application-configuration/reference-guides/immuta-ai-faq/immutas-ai-features). 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 ****. * **User B** is registered later in Immuta with the email address ****. 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/index.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.