[jira] [Commented] (ACCUMULO-259) ZKAuthentictor needs to be split up

["John Vines (Commented) (JIRA)" <ji...@apache.org>]

    [ 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