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 Wed, 21 Aug 2013 18:57:52 GMT

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

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

Hi Lars,

bq. is there any chance to do away with all of the static members and methods on UGI
Yes it’s possible. We’re working on incremental patches and in them getting rid of global
and static stuffs is considered.
bq. the same JVM we need to connect to some kerberos secured and some unsecured clusters.
Good idea! This provides another strong case to validate the change to support multiple clusters
for client. The change will ensure to use fresh UGI and its internals after cluster switching,
beside this, any security concerns do you have? If any what kind of convenient support the
UGI library can provide?
                
> 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