[
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640536#comment-13640536
]
Daryn Sharp commented on HADOOP-9421:
-------------------------------------
Further thoughts. Sorry it's so long, but I'm presenting the entire thought
process I've gone through.
# If the server is going to tell the client its identity (ex. what token,
service principal, etc is required for a mechanism), then the client doesn't
have the foreknowledge to select an appropriate mechanism.
# The client shouldn't be relying on the site config because it may not be
valid in a heterogeneous environment of clusters with different authentication
requirements. Requiring multiple configs to access multiple clusters is
becoming very cumbersome.
# Main point: there will always be 1 round-trip in any implementation.
*Using sasl-next*
Nominal case with token
O(1)
{noformat}
C -> S [ connection-header: ... ]
S -> C [ sasl-start: mech1, proto1, id1 ]
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}
No token
O(N), typically O(2)
{noformat}
C -> S [ connection-header: ... ]
S -> C [ sasl-start: mech1, proto1, id1 ]
C -> S [ sasl-next ]
S -> C [ sasl-start: mech2, proto2, id2 ]
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}
Discussion of server directing authentication:
# The state-machines for authentication are simple. Server always initiates
SASL sequence.
# Client is simple and "dumb"
#* Just tries to do what it's told
# Server is simple and deterministic
#* Trivially gives client a chance with each mechanism
#* Don't have to handle a client spamming auths and tying up an fd (ie. it will
have to reconnect)
#* Don't have to handle tracking which auths have already been tried
#* Object creation to interrogate the mechanism id is deferred until needed
# Algorithmic complexity to negotiate a mechanism:
#* Technically the authentication exchange is O(N)
#* Tasks will be O(1)
#* Job submitters requiring a token will be O(N>1), typically O(2)
*Using server advertisement*
Server _does_ support client suggestion
Client _does_ possess the credential
O(1)
{noformat}
C -> S [ connection-header: ..., suggested-mech, suggested-proto ]
S -> C [ sasl-start: suggested-mech, suggested-proto, id ] // client needs
server id
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}
Server _does_ support client suggestion
Client _does not_ actually possess the credential
O(3)
{noformat}
C -> S [ connection-header: ..., suggested-mech, suggested-proto ]
S -> C [ sasl-start: suggested-mech, suggested-proto, id ] // client needs
server id
C -> S [ sasl-abort ] // uh-oh, client doesn't have the credentials for the
server id!
S -> C [ sasl-mechs: [mech1, proto1, id1], [mech2, proto2, id2], ... ]
C -> S [ sasl-start: mech?, proto?, id? ]
S -> C [ sasl-challenge: sasl-token ]
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}
Server _does not_ support client suggestion
O(2)
{noformat}
C -> S [ connection-header: ..., suggested-mech, suggested-proto ]
S -> C [ sasl-mechs: [mech1, proto1, id1], [mech2, proto2, id2], ... ]
C -> S [ sasl-start: mech?, proto?, id?]
S -> C [ sasl-challenge: sasl-token ]
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}
Discussion of client directing authentication:
# The state-machines for authentication are more complex. Either side can
initiate SASL sequence.
# Client is smart/more complex
#* How can it select a mechanism?
#** Clients on a secure cluster always claim to be KERBEROS despite a TGT
(arguably a bug)
#** Does the client try KERBEROS and fail? Another round-trip
#** What if the client has multiple authenticated credentials available? Does
it randomly pick one?
#** Or does it always request TOKEN and fail if it doesn't have one for the
server id returned? Another round-trip
#* Might as well not suggest a mech/proto and wait for server to tell it what
it can do...
# Server is smart and has more error cases to handle
#* Client can initially request an invalid auth, all server can do is respond
with supported mechs
#* More complex to allow a client to attempt each mechanism
#* Have to track which auths have been attempted to abort when all are exhausted
#* Server has to instantiate objects for all mechanisms to acquire server id
# Algorithmic complexity to negotiate a mechanism:
#* Is O(1) assuming client can select the correct mechanism, which it can't w/o
server id
#* In practice O(2)
#* Has more complex implementation and maintainability costs
I'm concerned we are venturing into premature optimization. In both cases,
it's likely to be O(2). Sasl-next _might_ be O(>2) but of a low number during
job submission. RPC connections are cached and multiplex higher level
clients (such as DFSClient) so a possible O(>2) is minimal one-time overhead.
Given that the actual SASL negotiation requires multiple RPCs, ex. kerberos is
at least 3, the difference between 3 and maybe 4 will only be measurable with a
micro-benchmark that connects & disconnects w/o performing operations.
> 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
