hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9797) Pluggable and compatible UGI change
Date Tue, 06 Aug 2013 14:41:48 GMT

    [ 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

Mime
View raw message