[
https://issues.apache.org/jira/browse/KNOX-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772464#comment-16772464
]
Larry McCay commented on KNOX-1765:
-----------------------------------
However, while we wouldn't want to do make this a change in the core Knox idea
of the impersonated identity, you can likely do exactly what you want with one
of the existing identity assertion providers.
For instance, there is a Concat identity assertion provider [1] that allows you
to concatenate a string to the end of the asserted identity. There is also a
Regular Expression identity assertion provider [2] which allows you to get more
creative. Since an authenticated user in a given topology could be represented
as being from any realm, it would be perfectly reasonable to just dedicate a
topology to such a realm name. If you would rather a more complex mechanism
that derives the realm from the server you could always implement your own
identity assertion provider - very easy. Such a provider may make sense to
contribute back even.
The ability to affect the asserted identity within those providers is exactly
what that type of provider was added for. Making any fundamental change to the
core notion of the identity when then effect how identity assertion providers
work which would be a bad idea. For instance, adding a realm to a username
before some provider does its job on the principal on the way through may lead
to unexpected results.
#
[http://knox.apache.org/books/knox-1-2-0/user-guide.html#Concat+Identity+Assertion+Provider]
#
[http://knox.apache.org/books/knox-1-2-0/user-guide.html#Regular+Expression+Identity+Assertion+Provider]
> option to append @realm to usernames
> ------------------------------------
>
> Key: KNOX-1765
> URL: https://issues.apache.org/jira/browse/KNOX-1765
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Affects Versions: 1.1.0, 1.2.0
> Reporter: Ruslan Dautkhanov
> Assignee: Larry McCay
> Priority: Critical
>
> We'd like Hadoop to map user names to short names.
>
> For auth_to_local to work, @realm part is mandatory.
>
> For example, Apache Knox if authenticates users using LDAP,
> and then sends requests over to Livy, doesn't append realm.
>
> It seems we could duplicate rules from Hadoop's auth_to_local
> using `livy.server.auth.kerberos.name_rules` but it doesn't work
> for the same reason on Livy side.
> Spin-off from https://issues.apache.org/jira/browse/LIVY-548
> as it seems Knox is the right place for this fix (as other endpoints like
> HDFS, Hive access would need similar mappings).
> Hadoop code says opposite - there is an explicit check - if
> realm is empty, auth_to_local rules are not applied
>
> [https://github.com/apache/hadoop/blob/release-2.7.1/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/KerberosName.java#L376]
>
> rules application starts down below on line 383
>
> so it never reaches rules transformations loop if realm is empty.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
