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

View raw message