hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Zheng (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9797) Pluggable and compatible UGI change
Date Mon, 02 Sep 2013 09:01:58 GMT

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

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

Larry & Dilli,

This UGI change desires to be both pluggable and compatible. To be pluggable, it sure needs
to be modular first and this requires removing the relevant global static variables in the
UGI class. On the other hand to be compatible, as stated in the JIRA description and Dilli
suggested, the static public methods in the UGI class will remain and are to be just deprecated
since they’re part of the API. Sure this focuses on pluggable, removing statics is more
like a side effect. I would keep the support of multiple clusters in mind in the design and
implementation, though.

                
> 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

Mime
View raw message