[
https://issues.apache.org/jira/browse/HADOOP-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730826#comment-13730826
]
Daryn Sharp commented on HADOOP-9797:
-------------------------------------
Along the same lines as HADOOP-9840, this is further locking in a client having
one and only one identity.
I've often considered having subclasses of UGI that were login-type specific.
Owen had concerns that this was once tried and failed but I thought I could
make it work. Now that there's these alternate login methods coming, there's a
problem if the user has a TGT - it's authMethod KERBEROS but then accesses a
service requiring HSSO/TokenAuth. The UGI must simultaneously support both.
My general thinking from before the summit has been a client UGI should do JAAS
login on-demand for a given AuthMethod. A few examples are only trigger
kerberos auth if a web service wants spnego or SASL service wants GSSAPI.
Being on the 2.1 critical path has prevented me from having the time to flesh
out how that may be accomplished...
> Pluggable and compatible UGI change
> -----------------------------------
>
> Key: HADOOP-9797
> URL: https://issues.apache.org/jira/browse/HADOOP-9797
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: security
> Reporter: Kai Zheng
> Assignee: Kai Zheng
> Labels: Rhino
> Fix For: 3.0.0
>
> Attachments: HADOOP-9797-v1.patch
>
>
> As already widely discussed current UGI related classes needs to be improved
> in many aspects. This is to improve and make UGI so that it can be:
>
> * Pluggable, new authentication method with its login module can be
> dynamically registered and plugged without having to change the UGI class;
> * Extensible, login modules with their options can be dynamically extended
> and customized so that can be reusable elsewhere, like in TokenAuth;
>
> * No Kerberos relevant, remove any Kerberos relevant functionalities out of
> it to make it simple and suitable for other login mechanisms;
> * Of appropriate abstraction and API, with improved abstraction and API it’s
> possible to allow authentication implementations not using JAAS modules;
> * Compatible, should be compatible with previous deployment and
> authentication methods, so the existing APIs won’t be removed and some of
> them are just to be deprecated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
