Identity Assertion Providers Overview
There are multiple options for Identity Assertion Provider, configured in
Ambari under Knox>Configs>Advanced topology
. The following
identity-assertion
providers can be used:
Table 2.25. Identity Assertion Providers
Provider | <name> | Use | Example |
---|---|---|---|
Default Identity Assertion Provider Pseudo (deprecated) |
|
The default identity assertion provider enables simple mapping of principal usernames and groups and is responsible for the establishing the identity that gets propagated to the cluster service as the effective user. |
<provider> <role>identity-assertion</role> <name>Default</name> <enabled>true</enabled> <param> <name>principal.mapping</name> <value>guest=hdfs;</value> </param> <param> <name>group.principal.mapping</name> <value>*=users;hdfs=admin</value> </param> </provider> |
|
The Concat identity assertion provider allows for composition of a new user principal through the concatenation of optionally configured prefix and/or suffix provider parameters. This is a useful assertion provider for converting an incoming identity into a disambiguated identity within the Hadoop cluster based on what topology is used to access Hadoop. |
<provider> <role>identity-assertion</role> <name>Concat</name> <enabled>true</enabled> <param> <name>concat.suffix</name> <value>_domain1</value> </param> </provider> | |
|
The SwitchCase identity assertion provider solves issues where down stream ecosystem components require user and group principal names to be a specific case. An example of how this provider is enabled and configured within the <gateway> section of a topology file is shown below. |
<provider> <role>identity-assertion</role> <name>SwitchCase</name> <param> <name>principal.case</name> <value>lower</value> </param> <param> <name>group.principal.case</name> <value>upper</value> </param> <enabled>true</enabled> </provider> | |
|
The regular expression identity assertion provider allows incoming identities to be translated using a regular expression, template and lookup table. This will probably be most useful in conjunction with the HeaderPreAuth federation provider. |
<provider> <role>identity-assertion</role> <name>Regex</name> <enabled>true</enabled> <param> <name>input</name> <value>(.*)@(.*?)\..*</value> </param> <param> <name>output</name> <value>{1}_{[2]}</value> </param> <param> <name>lookup</name> <value>us=USA;ca=CANADA</value> </param> </provider> | |
|
The Hadoop Group Lookup identity assertion provider looks up the user’s ‘group membership’ for authenticated users using Hadoop’s group mapping service (GroupMappingServiceProvider). This allows existing investments in the Hadoop to be leveraged within Knox and used within the access control policy enforcement at the perimeter. |
<provider> <role>identity-assertion</role> <name>HadoopGroupProvider</name> <enabled>true</enabled> <param> <name>hadoop.security.group.mapping</name> <value>org.apache.hadoop.security.LdapGroupsMapping</value> </param> <param> <name>hadoop.security.group.mapping.ldap.bind.user</name> <value>uid=tom,ou=people,dc=hadoop,dc=apache,dc=org</value> </param> <param> <name>hadoop.security.group.mapping.ldap.bind.password</name> <value>tom-password</value> </param> <param> <name>hadoop.security.group.mapping.ldap.url</name> <value>ldap://localhost:33389</value> </param> <param> <name>hadoop.security.group.mapping.ldap.base</name> <value></value> </param> <param> <name>hadoop.security.group.mapping.ldap.search.filter.user</name> <value>(&(|(objectclass=person)(objectclass=applicationProcess))(cn={0}))</value> </param> <param> <name>hadoop.security.group.mapping.ldap.search.filter.group</name> <value>(objectclass=groupOfNames)</value> </param> <param> <name>hadoop.security.group.mapping.ldap.search.attr.member</name> <value>member</value> </param> <param> <name>hadoop.security.group.mapping.ldap.search.attr.group.name</name> <value>cn</value> </param> </provider> |
Note | |
---|---|
You can only use one identity assertion provider at a time. |