Identity Managers
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.
Immuta's built-in identity manager
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, so there are no additional configuration options needed to support this mode.
Best practice: Identity access management
Immuta recommends using an external IAM for user authentication and using Immuta's built-in IAM to manage user attributes.
External identity managers
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. 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 one IAM ID.
IAM protocol feature support matrix
The table below illustrates the features supported by each IAM protocol.
| Feature | AD/LDAP | SAML 2.0 | OpenID Connect 1.0 |
|---|---|---|---|
| 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. |
IAM solutions support matrix
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.
| Provider | LDAP | SAML 2.0 | OpenID Connect 1.0 | SCIM 2.0 |
|---|---|---|---|---|
| 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 |
| 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 |
Identity manager options and configuration
Identity managers are added from the app settings page. Settings like default permissions, profile schema, group schema, group permissions, and external groups and attributes endpoint are managed from that page as well.
Default permissions
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.
Migrating users
On the app settings page, application admins can 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.
SCIM support
Best practice: 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).
Attribute mapping
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
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.
Profile schema
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.
Group schema
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.
Group permissions
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.
External groups and attributes endpoint
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.