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.
Immuta supports , , and protocols. The table below illustrates the features supported by each IAM protocol.
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.
Identity providers are configured on the Immuta app settings page, where you can map your users' and from your identity provider into Immuta for use in access control policies and manage other general settings:
: Map user attributes from your identity provider to Immuta.
: Map groups from your identity provider to Immuta.
: Map user profile details into Immuta.
For details about settings specific to a protocol, see the , , or protocol reference guide.
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 or 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 for details.
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 , , or protocol for details and examples.
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.
An IAM provider can be used for authentication and combined with an 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 .
Each identity manager supports the configuration of default permissions, which controls what 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.
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 .
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 or 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.
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 . 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.
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 is not responsible for inadvertent disclosures of such data related to the foregoing.
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:
Read ALL directory groups for policy authoring
✅
✅
✅
Consume attributes and groups from arbitrary sources
✅ Requires an
✅ Requires an (and is only supported if not using SCIM)
✅ Requires an (and is only supported if not using SCIM)
❌
✅
❌
❌
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
✅
✅
✅
✅
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.
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.
Read user groups and attributes on user login
✅
✅ Requires an external user info service
✅
SCIM 2.0 support for provisioning (users and groups)
❌
✅
✅
Periodic directory sync for provisioning (users and groups)
✅
❌
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.
You can use your existing identity provider to authenticate users to the Immuta application. LDAP, OpenID Connect, and SAML protocols are all supported. This reference guide provides details about the configuration options available for identity providers that use the LDAP protocol.
Beyond authentication, you can configure LDAP sync or an external user info endpoint so that Immuta can ingest groups and attributes already assigned to your users. Then, you can use that user metadata to author access control policies.
The following options are available when setting up an identity provider that uses the LDAP protocol.
Bind DN: The distinguished name (DN) Immuta will use to authenticate to the LDAP server and query the database.
Bind password: The password Immuta will use to authenticate to the LDAP server and query the database.
Enable pagination for LDAP sync: Set the page size to use when searching LDAP.
If you enable attribute sync for LDAP, you will configure the attribute schema to define how attributes are mapped in Immuta.
When configuring the attribute schema for LDAP, you specify the Immuta attribute key that will prepend the LDAP attribute key it maps to.
The table below illustrates a sample attribute schema mapping for Taylor, who is an engineering manager located in Washington:
givenName=Taylor, member=Managers, ou=Engineering, l=Washington
Once these attributes are pulled into Immuta, policy authors can create global policies using these attributes to automatically enforce access controls for users based on their attributes. Consider the following example:
Only show rows where user possesses an attribute in
Locationthat matches the value in column taggedOfficeLocationon all data sources.
Then, Taylor would only see rows that include the value of her office location (Washington) in the column tagged OfficeLocation.
If you enable group sync for your identity provider, you will configure the group schema by specifying the LDAP attribute that contains users' groups. This defines how groups are mapped in Immuta.
When configuring the group schema mapping, you provide the group name and group ID. Then, Immuta will automatically ingest those groups so that they can be used in policies.
Consider the following LDAP users:
givenName=Taylor, member=Managers, cn=Engineering, l=Washington
givenName=Alex, member=Intern, cn=Research, l=Ohio
givenName=Sai, member=Managers, cn=Marketing, l=Oregon
The table below illustrates the groups that Immuta would ingest if an administrator configured the group schema mapping to use cn to identify the groups to add to Immuta:
Once these groups are pulled into Immuta, policy authors can create global policies using these groups to automatically enforce access controls for users based on their groups. Consider the following example:
Only show rows where user is a member of a group that matches the value in column tagged
Departmenton all data sources.
Then, Taylor would only see rows that include the value of her group (Engineering) in the column tagged Department.
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.
Set the cron rule for how often to run the LDAP sync job. 0 */1 * * * is once every hour.
Enable SSL: Use SSL to protect user credentials, identity tokens, and profile data during login.
External groups and attributes endpoint: Immuta uses this REST endpoint to retrieve a user's groups and attributes from an external IAM service.
Sync REST attributes: Ingest user attributes from the external IAM service into Immuta.
Sync REST groups: Ingest user groups from the external IAM service into Immuta.
Use authentication: Provide credentials Immuta will use to connect to the external IAM service.
Group permissions: When LDAP is configured to sync groups, you can 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.
Group search base: The base DN to use as the starting point in the directory to find groups. For example, ou=groups.
Group search filter: The DN to add to the group search base to filter for a specific group. Defaults to (&(objectClass=posixGroup)(cn=*)).
Host: The URL of the LDAP server.
Make default IAM: This identity provider will be the default identity provider selected for users when logging in to Immuta.
Migrate users: Migrate users from a previously configured identity provider to the current identity provider being configured.
Port: The port of the LDAP server.
Profile schema: Map attributes from your identity provider to automatically fill in a user’s Immuta profile.
Require manual activation before a user can use Immuta: Users will be imported into Immuta in a disabled state and must be enabled by a user admin before they can use Immuta.
Sync attributes from LDAP/Active Directory to Immuta: Define the attribute key that will appear in Immuta and the LDAP attribute key it maps to.
Sync groups from LDAP/Active Directory to Immuta: Map attributes from LDAP to pull information about the groups into Immuta.
User attribute: The DN that holds the user's ID (uid).
User group search filter: The DN to use to find what groups a user is in. Defaults to (memberUid=${userid}).
User search base: The base DN to use as the starting point in the directory to find users. For example, o=Marketing or ou=Employees.
User search filter: The DN to add to the user search base to filter for a specific user (uid=${userid}).
Group
member
Group:Managers
Department
ou
Department:Engineering
Location
l
Location:Washington
Taylor
Engineering
Alex
Research
Sai
Marketing
Immuta can consume user attributes from an external HTTP endpoint. This feature allows you to retrieve users' groups and authorizations from an additional resource alongside the user attributes retrieved in the authentication flow. Such an external endpoint can be configured for any of the identity management protocols that Immuta supports.
The service can authenticate requests with both of these methods:
Basic username and password Authorization header
SSL cert validation
Note: Immuta will expect non 200 error codes when the user info cannot be retrieved.
The user info endpoint is called each time Immuta needs to synchronize with a remote IAM on user groups and attributes. Immuta will query the endpoint with the user ID specified in the request's query.
Note: The endpoint's path does not have to be /user-info.
Query parameter
Response
Response schema
Below is a sample response that could be returned by the endpoint.
userid string
The unique user identifier (username in Immuta)
Yes
200
successful operation - user info retrieved successfully
groups
[{"name": "<group_name>"}]
authorizations
{"<authorization_name>": ["<value>"]}
{
"groups": [{
"name": "Accountants",
}, {
"name": "Controllers",
}],
"authorizations": {
"EMEA": ["Sales", "Expenses"],
"APAC": ["Sales"]
}
}After you connect your existing identity provider to Immuta, users can authenticate to the Immuta application through the SAML protocol.
Beyond authentication, you can configure SCIM or an external user info endpoint so that Immuta can ingest groups and attributes already assigned to your users. Then, you can use that user metadata to author access control policies.
This reference guide outlines details about the configuration options available for SAML.
The following options are available when .
: When enabled, users authenticate once in their identity provider and can log in to Immuta.
: 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.
When configuring an identity provider that uses the SAML protocol, you can enable SCIM support. SCIM support allows Immuta to
Automatically create new users in Immuta as they are created in your identity provider
Keep existing users up-to-date in your identity provider
See the for details about SCIM support.
If you enable sync attributes from SAML to Immuta, you will configure the attribute schema to define how attributes are mapped in Immuta.
When configuring the attribute schema for SAML (with SCIM disabled), you define the attribute key prefix, the attribute delimiter, and (optionally) the Immuta attribute key that maps to the IAM attribute.
The table below illustrates a sample attribute schema mapping for Taylor, who has the following attribute key-value pairs:
role:Managers
dept:Engineering
location:Washington
Once these attributes are pulled into Immuta, policy authors can create global policies using these attributes to automatically enforce access controls for users based on their attributes. Consider the following example:
Only show rows where user possesses an attribute in
immutaAuth.OfficeLocationthat matches the value in column taggedOfficeLocationon all data sources.
Then, Taylor would only see rows that include the value of her office location (Washington) in the column tagged OfficeLocation.
For SCIM attribute mapping with SCIM enabled, the attribute prefix is mapped to the relevant SCIM schema.
The Immuta attribute prefix will be prepended to all attribute keys included in that schema. For example, if the SCIM schema urn:immuta:schemas:extension:custom:2.0:User included the attributes Title, employeeNumber, and AccessLevel and was mapped to the Immuta attribute prefix Immuta, the attribute key-value pairs would be pulled into Immuta like this:
Immuta.Title:x
Immuta.employeeNumber:x
Immuta.AccessLevel:x
The table below illustrates a sample attribute schema mapping with SCIM enabled for Taylor, who has the following attribute key-value pairs:
"role": "Manager"
"dept": "Engineering"
Once these attributes are pulled into Immuta, policy authors can create global policies using these attributes to automatically enforce access controls for users based on their attributes. Consider the following example:
Only show rows where user possesses an attribute in
Immuta.deptthat matches the value in column taggedLOBon all data sources.
Then, Taylor would only see rows that include the value of her department (Engineering) in the column tagged LOB.
If you enable sync groups from SAML to Immuta, you will configure the group schema to specify the SAML attribute that contains users' groups. This defines how groups are mapped in Immuta.
When configuring the group schema mapping for SAML (with SCIM disabled), you define the SAML attribute that contains the groups you want Immuta to ingest.
Consider the following SAML users:
firstName:Taylor, role:Managers, dept:Engineering, location:Washington
firstName:Alex, role:Intern, dept:Research, location:Ohio
firstName:Sai, role:Managers, dept:Marketing, location:Oregon
The table below illustrates the groups that Immuta would ingest if an administrator configured the group schema mapping to use the dept SAML attribute to identify the groups to add to Immuta:
Once these groups are pulled into Immuta, policy authors can create global policies using these groups to automatically enforce access controls for users based on their groups. Consider the following example:
Only show rows where user is a member of a group that matches the value in column tagged
Departmenton all data sources.
Then, Taylor would only see rows that include the value of her group (Engineering) in the column tagged Department.
Immuta's SAML integration supports the identity-provider-initiated authentication flow single sign-on method.
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's SAML SLO support has been tested with the following identity providers:
Key Cloak
Microsoft Entra ID
Okta
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 .
Immuta cannot ensure that other service providers will log out, as Immuta has no control over those applications.
There are two logout processes for SAML SLO:
: A user logs out from a service provider.
: A user logs out from their identity provider.
After you connect your existing identity provider to Immuta, users can authenticate to the Immuta application through the OpenID Connect protocol.
Beyond authentication, you can configure an external user info endpoint so that Immuta can ingest groups and attributes already assigned to your users. Then, you can use that user metadata to author access control policies.
This reference guide outlines details about the configuration options available for OpenID Connect.
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.
Allow Immuta attributes to be applied to SAML users and groups: Attributes created in Immuta can be added to your users and groups in your identity provider.
Allow SAML users to be added to Immuta groups: This allows you to create groups in Immuta and add SAML users to those groups.
Attribute schema: Map SAML attributes into Immuta after you enable sync attributes from SAML to Immuta.
Decryption private key: The private key for decrypting attribute assertions from the identity provider.
Encryption private key: An optional private key to encrypt requests.
Entry point: The URL of your single sign on application that the Immuta login page will redirect to.
External groups and attributes endpoint: Immuta uses this REST endpoint to retrieve a user's groups and attributes from an external IAM service.
Sync REST attributes: Ingest user attributes from the external IAM service into Immuta.
Sync REST groups: Ingest user groups from the external IAM service into Immuta.
Use authentication: Provide credentials Immuta will use to connect to the external IAM service.
Enable SSL: Use SSL to protect credentials during login.
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 being configured in Immuta.
Profile schema: Map attributes from your identity provider to automatically fill in a user’s Immuta profile.
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.
User ID attribute: The attribute that contains the user's username.
immutaAuth.OfficeLocation:Washington
immutaAuth.
Title
role
immutaAuth.Title:Managers
immutaAuth.
Department
dept
immutaAuth.Department:Engineering
immutaAuth.
OfficeLocation
urn:immuta:schemas:extension:custom:2.0:User
Title
Title.role:Manager
urn:ietf:params:scim:schemas:core:2.0:User
Immuta
Immuta.dept:Engineering
Taylor
Engineering
Alex
Research
Sai
Marketing
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 user 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 user 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.
location
Allow identity-provider-initiated single sign-on: When enabled, users authenticate once in their identity provider and can log in to Immuta.
Allow Immuta attributes to be applied to OpenID users and groups: Attributes created in Immuta can be added to your users and groups in your identity provider. SCIM must be enabled or you must configure an external user info endpoint for this option to be available.
Allow OpenID users to be added to Immuta groups: This allows you to create groups in Immuta and add OpenID users to those groups. SCIM must be enabled or you must configure an external user info endpoint for this option to be available.
: Map OpenID Connect attributes into Immuta after you enable SCIM.
Authorization endpoint: The URL of the authorization server. The user will be redirected to this URL to authenticate when they log in to Immuta. If the Discover URL is provided, this field will be disabled.
Client ID: The unique string identifier assigned to the OpenID Connect application you created in your identity provider. See your identity provider's documentation for details.
Client secret: Client secret the OpenID Connect application uses to verify its identity with the authorization server. See your identity provider's documentation for details.
Discover URL: URL of the identity provider's discovery endpoint. If this URL is provided, the fields for manually specifying the endpoint will be disabled.
Enable SSL: Use SSL to protect user credentials, identity tokens, and profile data during login.
End session endpoint: The URL of the identity provider's end session endpoint, which will trigger single logout.
: Immuta uses this REST endpoint to retrieve a user's groups and attributes from an external IAM service.
Sync REST attributes: Ingest user attributes from the external IAM service into Immuta.
Sync REST groups: Ingest user groups from the external IAM service into Immuta.
Group permissions: Once you enable group permissions, you can define a mapping of groups to Immuta permissions. Users who belong to one of the given groups will be granted the listed permissions automatically. SCIM must be enabled or you must configure an external user info endpoint for this option to be available.
Issuer: The identity provider's URL. If the Discover URL is provided, this field will be disabled.
JWKS URI: URL of the identity provider's JSON Web Key set. This is configured in the authorization server. If the Discover URL is provided, this field will be disabled.
: Migrate users from a previously configured identity provider to the current identity provider being configured.
: Map attributes from your identity provider to automatically fill in a user’s Immuta profile.
: 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.
Scopes: The scopes sent when a user authenticates. Scopes authorize access to a user’s profile details, like name and email.
Supported ID token signing algorithms: A list of supported signing algorithms for verifying ID token signatures. If the Discover URL is provided, this field will be disabled.
Token endpoint: URL of the identity provider's endpoint that returns access tokens or ID tokens. If the Discover URL is provided, this field will be disabled.
User info endpoint: URL of the identity provider's user info endpoint. Complete this field if you will add custom scopes. If the Discover URL is provided, this field will be disabled.
User ID claim: This key (primarily the sub (subject) claim) of the claim holds a unique identifier for the end user assigned by the identity provider.
When configuring an identity provider that uses the OpenID Connect protocol, you can enable SCIM support. SCIM support allows Immuta to
Automatically create new users in Immuta as they are created in your identity provider
Keep existing users up-to-date in your identity provider
Map OpenID Connect attributes to Immuta attributes
Ingest OpenID Connect groups
Add Immuta attributes to OpenID Connect users and groups
Add OpenID Connect users to Immuta groups
See the Identity managers overview for details about SCIM support.
If you enable SCIM for OpenID Connect, Immuta will ingest the attributes and groups configured in your identity provider.
For groups and attributes to sync in Immuta, no additional configuration is required beyond enabling SCIM. However, you can define how user attributes are mapped into Immuta. See the attribute mapping section for details.
To configure attribute mapping for OpenID Connect, SCIM must be enabled. Once enabled, you can complete the attribute schema, which defines how attributes are mapped in Immuta.
For SCIM attribute mapping, the attribute prefix is mapped to the relevant SCIM schema. The Immuta attribute prefix will be prepended to all attribute keys included in that schema. For example, if the SCIM schema urn:immuta:schemas:extension:custom:2.0:User included the attributes Title, employeeNumber, and AccessLevel and was mapped to the Immuta attribute prefix Immuta, the attribute key-value pairs would be pulled into Immuta like this:
Immuta.Title:x
Immuta.employeeNumber:x
Immuta.AccessLevel:x
The table below illustrates a sample attribute schema mapping with SCIM enabled for Taylor, who has the following attribute key-value pairs:
"role": "Manager"
"dept": "Engineering"
urn:immuta:schemas:extension:custom:2.0:User
Title
Title.role:Manager
urn:ietf:params:scim:schemas:core:2.0:User
Immuta
Immuta.dept:Engineering
Once these attributes are pulled into Immuta, policy authors can create global policies using these attributes to automatically enforce access controls for users based on their attributes. Consider the following example:
Only show rows where user possesses an attribute in
Immuta.deptthat matches the value in column taggedLOBon all data sources.
Then, Taylor would only see rows that include the value of her department (Engineering) in the column tagged LOB.
Immuta's OpenID Connect integration supports the identity-provider-initiated authentication flow single sign-on method.