Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Date: Wed, 1 Aug 2012 17:47:02 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: dev@accumulo.apache.org
Message-ID: <965591775.1507.1343843222845.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <156687942.15731.1341605615440.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (ACCUMULO-677) Remove (deprecate) createUser
 call with authorizations argument
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426770#comment-13426770 ] 

Christopher Tubbs commented on ACCUMULO-677:
--------------------------------------------

I suppose a system administrator could create the user account, while the data owner can grant an authorization (a concept I strongly like). After some consideration, I think I'm also in reluctant agreement with the above (I really liked the simplicity of "CREATE/ALTER USER").

Under this user management model, API changes should include add/remove methods for auths, rather than simply setAuths. Also, the API should be robust enough to assign and manage data owners, on a per-authorization basis to make this change useful. The ability to grant an authorization should be based on that user's relationship to the authorization in question (eg. data owner), not based on a blanket permission to grant all authorizations.

My concerns under this model, though, remain:

1) if the data owner only grants authorizations to existing users rather than creating users themselves, then a trust relationship must exist between the data owner and the system administrator who created the user, so that the data owner can trust that the user to whom they are assigning auths (based on user name) is the correct user,

2) this trust relationship may add security assumptions to the API that users need to be aware of (imagine a user admin deleting an existing user with authorizations, and re-creating it with a new password that he/she knows), and

3) the separation of responsibilities for user management may add confusion to end users of the type that this ticket intends to avoid.

                
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
>                 Key: ACCUMULO-677
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-677
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 1.4.1, 1.4.2
>            Reporter: John Vines
>            Assignee: John Vines
>            Priority: Minor
>              Labels: acl, alter, api, create, permissions, security, user
>             Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.

--
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