[
https://issues.apache.org/jira/browse/ACCUMULO-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13712944#comment-13712944
]
Christopher Tubbs commented on ACCUMULO-1578:
---------------------------------------------
[~vines] - No, there *is* something different between the old system and the
new pluggable authentication. The previous assumption was that credentials were
long-lived, and thus an early check made sense, because it could be assumed
that later checks would pass if an earlier check passed. If a password changed,
it's probably because the user knew about it and meant to change it. In the
pluggable authentication system, the assumption that credentials are
long-lived, or were changed as a result of deliberate user action, both go
completely out the window. Credentials can be instantiated temporarily from a
credential-providing service, and expire quite quickly. There is no reason to
assume they are long-lived.
The additional check doesn't really provide much protection against changed
passwords anyway... its just a slight sanity check, for convenience, at the
cost of an extra RPC call.
As the developer who coded this sanity check in the first place, I'm arguing
that it's not really worth it, but I agree that changing the contract could be
disruptive. I'm trying to get a sense of how disruptive... especially since
we've never really *documented* this contract outside the implementing code (to
my knowledge).
> Connector constructor doesn't need to fail-fast (maybe?)
> --------------------------------------------------------
>
> Key: ACCUMULO-1578
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1578
> Project: Accumulo
> Issue Type: Task
> Reporter: Christopher Tubbs
> Assignee: Christopher Tubbs
> Fix For: 1.6.0
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> Currently, when one instantiates a Connector from an Instance, with one's
> username and token, the Connector actually tries to reach out and
> authenticate those credentials, to provide early failure.
> Because this has some overhead, we explicitly check for the condition that
> the user is a system user (a tserver or the monitor, etc.), so that we don't
> fail early in these conditions (because we don't expect the system to be
> poorly configured or running in a bad state, such that it doesn't
> authenticate... and we don't care about causing an inconvenience to
> unauthorized servers by failing late).
> After some thought, I'm not sure that we should continue to fail fast. I'm
> not sure that it provides sufficient convenience for users to warrant the
> additional RPC calls. Besides, there's no guarantee, especially with the new
> pluggable authentication introduced in 1.5.0, that the credentials will still
> be valid later, even if the user were able to authenticate initially.
> As such, I propose we drop this check, and rely on authentication failures
> later (when work is actually initiated).
--
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
