[
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640715#comment-13640715
]
Daryn Sharp commented on HADOOP-9421:
-------------------------------------
bq. Only if there is only one kind of tokens, which will not be true.
Valid point, but I'm interested in your vision/use-case for multiple tokens?
Could this be hidden behind the secret manager?
bq. Benoy: An alternative approach in choosing a mechanism is to model after
the SSL protocol. Here Client does "ClientHello" to server with a list of
mechanisms it supports.
Exploring that approach, why not return the mechanisms in response to the
connection header?
bq. In terms of complexity. Sasl-next proposal actually seems more complex by
intertwine sasl handshakes with mechanism/protocol selection/negotiation.
I'm open to ideas, but I'm not sure I understand this. How is "do you do this
mech?", "no?", "how about this mech?", "yes? ok, let's do it!" being complex?
bq. This is a generalization of the client initiation mechanism. If we
implement my proposal, this can be added later in a backward compatible manner,
as we can send the client capabilities in an optional field.
In your example, you're again assuming the client is in a position to
intelligently _propose_ a mechanism - it's not. The client can't make a
determination until he knows the server id for a mechanism.
The server can't _chose_ a mech based client capabilities either. Just because
the client and server support DIGEST-MD5/dtoken doesn't mean the client
actually has the right token. The server can't guess what the client has, nor
would be desirable for the client to send all his token services so the server
can chose.
The client is the one that must chose a mech but it needs server hints to do
so. I think a middle ground is the server advertises all its mechs at once,
instead of one at a time as I proposed.
{noformat}
C -> S [ connection-header: ... ]
S -> C [ sasl-mechs: [mech1, proto1, id1], [mech2, proto2, id2], ... ]
C -> S [ sasl-start: mech?, proto? ]
...
{noformat}
Having only one side (in this case client) start the negotiation is much
simpler. If we say the client gets one shot, instead of willy-nilly choosing
multiple mechs and the server keeping track of what's been attempted, then it
will be a lot easier.
The one downside I see to the client initiating the exchange, instead of the
server, is if the server wants to do a second mech based on success of another
mech. Ex. using some special mech with a secret requires a followup sasl
negotiation with say kerberos. If the server always initiates, and the dumb
client does what it's told, that's easy to do in a trivial fashion. IMHO, dumb
clients are always good, but I'm willing to compromise.
> 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
