LDAP Protocol

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.

Configuration options

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.

• Enable scheduled LDAP sync support: LDAP sync takes an existing and configured LDAP IAM and seeds Immuta with all of its users. When configuring an identity provider that uses the LDAP protocol, you 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. 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}).

Attribute mapping

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

Immuta attribute key	LDAP attribute	Taylor's resulting attribute key-value pair in Immuta
Group	member	Group:Managers
Department	ou	Department:Engineering
Location	l	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 Location that matches the value in column tagged OfficeLocation on all data sources.

Then, Taylor would only see rows that include the value of her office location (Washington) in the column tagged OfficeLocation.

Group mapping

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:

LDAP user	Resulting group in Immuta
Taylor	Engineering
Alex	Research
Sai	Marketing

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 Department on all data sources.

Then, Taylor would only see rows that include the value of her group (Engineering) in the column tagged Department.