Audience: System Administrators
Content Summary: Any number of identity managers can be configured and enabled for an instance of Immuta. Each identity manager has a specific set of configurations that enables it to communicate with the IAM system and map the users, permissions, groups, and attributes into Immuta.
This page contains general information about how identity managers are used within Immuta and common configuration options.
Identity managers are used with Immuta to provide authentication and fine-grained user entitlement.
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.
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 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 exactly one IAM ID.
Identity Manager Options and Configuration
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
their user ID in the new IAM should be
firstname.lastname@example.org.) 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.
Each identity manager configured has a mapping of attributes from the source system into attributes on the user profile in Immuta.
This example is the profile schema mapping for an LDAP/Active Directory IAM.
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.
External Groups and Attributes Endpoint
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.