[ 
https://issues.apache.org/jira/browse/HADOOP-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731814#comment-13731814
 ] 

Kai Zheng commented on HADOOP-9797:
-----------------------------------

bq.Along the same lines as HADOOP-9840, this is further locking in a client 
having one and only one identity.
Please see my response on HADOOP-9840, it should still allow for support of 
multiple identities.

bq.I've often considered having subclasses of UGI that were login-type specific.
Good to hear. In the initial patch it comes up LiteUGI and various subclasses 
of it are login-type specific. I will resolve some concerns like naming issues 
and provide another patch based on existing ones.
bq.a client UGI should do JAAS login on-demand for a given AuthMethod.
Quite agree. It's particularly useful for token authn client which is 
instructed by server to use specific authn mechanisms and JAAS login modules 
dynamically. That's also the primary goal for this issue although we should 
approach it incrementally as you suggested.
                
> 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

Reply via email to