[
https://issues.apache.org/jira/browse/ACCUMULO-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181628#comment-13181628
]
John Vines commented on ACCUMULO-259:
-------------------------------------
To elaborate on the changes needed-
The act of checking instance IDs is a system authenticator action (system
authenticator meaning the authenticator code that always exists vs. the
pluggable authenticator). Authenticating the system user also falls into here.
The public authenticateUser is a system action, which should rely on pluggable
authenticator's authenticate(AuthInfo) to simply check a users info. Plugging
authenticator should trust that the system authenticator made sure the person
calling authenticate is allowed to authenticate the given user.
These changes are similar across the other functions- the pluggable
authenticator does what is asked, trusting the system authenticator already
decided it was okay. The system authenticator will decide this from information
derived from the pluggable authenticator. So I pose the following pluggable
authenticator interface:
public boolean authenticate(AuthInfo user);
public boolean changePassword(AuthInfo user, byte[] newPass);
public boolean createUser(AuthInfo newUser);
public boolean hasPermission(String user, Table/SystemPermission);
public boolean setPermission(String user, Table/SystemPermission);
public boolean revokePermission(String user, Table/SystemPermission);
public boolean changeAuthorizations(String user, Auths newAuths);
public Auths getAuths(String user);
public void init(String rootuser, byte[] rootPass);
public List<String> users();
public boolean userExists(String user);
This is a quick interface based off of the ZKAuthenticator. The few comments I
have on it are-
1. I used the booleans for sets, revokes, etc. in case we have a pluggable
authenticator which can fail at it's actions.
2. While I removed the Auths from the calling user because we trust the system
authenticator, this may not be possible. There may be pluggable security
systems that want to be designed for the Accumulo system user to validate, or
another calling user. However, the pluggable security system could have a set
of master credentials it uses, so we might want to rely on those. However,
regardless if a pluggable system required a master user or not, we will still
be doing our own authentication in the system authenticator.
3. This is pretty much identical to the exact Authenticator. But that's the
point- we started with the right idea, but we fell off the course. The only
real interface changes I'm proposing are dropping getRootUser (ZK should hold
this info [but just the name, unless the ZKAuthenticator is being used]),
changing many of the results from void to booleans, and possibly dropping
parent credentials.
Thoughts?
> ZKAuthentictor needs to be split up
> -----------------------------------
>
> Key: ACCUMULO-259
> URL: https://issues.apache.org/jira/browse/ACCUMULO-259
> Project: Accumulo
> Issue Type: Improvement
> Components: master, tserver
> Reporter: John Vines
> Assignee: Eric Newton
>
> Currently the ZKAuthenticator does both the checking of credentials as well
> as the functionality of the Authenticator. We need to split those into two
> different classes for improved testing as well as pluggability of the
> security scheme.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
