Identity mapping allows you to normalize user and group identities from different identity providers.
For example, you can combine mTLS authentication with an LDAP user group manager, even if there is no exact match in the Distinguished Name (DN) from the user certificate and LDAP.
The following examples demonstrate normalizing DNs from certificates and LDAP:
- Certificate DN mapping
- efm.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), L=(.*?), ST=(.*?), C=(.*?)$
- LDAP DN mapping
- efm.security.identity.mapping.pattern.ldap=^cn=(.*?), ou=(.*?), o=(.*?)$
Each property's final segment serves as an identifier, linking the pattern to the replacement value. When a user initiates a request in EFM, their identity is verified against these patterns in lexicographical order. When encountering the first matching pattern, the replacement specified in the efm.security.identity.mapping.value.xxxx property is applied.
For instance, when a login with the DN "CN=admin, OU=EFM, O=Cloudera, L=Santa Clara, ST=CA, C=US" corresponds to the above DN mapping pattern, the DN mapping value of "$1" is used, normalizing the user to localhost.
The LDAP DN is slightly different so it would not match with the certificate identity. To resolve this issue, a pattern is applied, to extract the CN part of the LDAP’s DN and transform the value to lowercase.
In addition to mapping, there is an option to apply transformations. Supported transformation options include:
- NONE: no transformation is applied
- LOWER: identity is converted to lowercase
- UPPER: identity is converted to uppercase
If not specified, the default value is NONE.
Group names can also be mapped. The following example accepts the existing group name but converts it to uppercase:
- Group name mapping