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-9421) Add full length to SASL response to allow non-blocking readers
Date Tue, 23 Apr 2013 16:19:17 GMT

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

Daryn Sharp commented on HADOOP-9421:
-------------------------------------

Sorry for not responding.  I'm still trying to get my head above water from vacation, but
having the server return a list of mechanisms is probably a worth goal.  I originally considered
the server walking through a list to be the simplest implementation.  I'll try to focus on
the server providing all mechanisms now.

Having the client suggest a mechanism is probably less useful because it won't eliminate a
round-trip.  The server has to respond with "client, you start", "client, here's your first
challenge", or "client, I don't do that, here's my mechanisms".

Then there's the problem of the client deciding which mechanism to suggest - ex. how would
the client advertise "let's try token" when it doesn't even know if it has the token until
the server responds and tells it what token service it needs.

bq. This is assuming you either hard code the order at the server side or having an extra
source of configuration errors

The token value doesn't necessarily have to be in the config.  Currently a secret manager
implicitly enables token support.  The server can always return token first if a secret manager
is enabled, or first only if token isn't already explicitly specified in configured auths.

What I'm pondering is when we want to provide a hint to the client for a given mechanism:
ex. telling the client the token it wants, or perhaps telling the client the service principal
so it doesn't have to guess (to allow multi-NIC/host/realm support), etc.  If the value can't
always be pre-determined, having the server instantiate all possible SASL servers to obtain
the value to return in the supported mechanisms response may not be efficient/desirable.

I'll continue to think through the use-cases...
                
> Add full length to SASL response to allow non-blocking readers
> --------------------------------------------------------------
>
>                 Key: HADOOP-9421
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9421
>             Project: Hadoop Common
>          Issue Type: Sub-task
>    Affects Versions: 2.0.3-alpha
>            Reporter: Sanjay Radia
>            Assignee: Junping Du
>         Attachments: HADOOP-9421.patch
>
>


--
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