Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Sat, 7 Sep 2013 00:52:52 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12666769.1378245743089.95689.1378515172145@arcas>
In-Reply-To: <JIRA.12666769.1378245743089@arcas>
References: <JIRA.12666769.1378245743089@arcas>
Subject: [jira] [Commented] (ACCUMULO-1681) Adjust Authorizor Interface to
 validate auths instead of retrieving a list
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Christopher Tubbs commented on ACCUMULO-1681:
---------------------------------------------

Since we've already established the standard that visibility labels should be human-readable, and previous discussions around Authorizations have concluded with the idea that java Strings contain the set of everything that is "human-readable" for this definition, I don't see a reason to make the interface accept ByteSequence instead of CharSequence (or really String, to offer the guarantee of no side-effects in the interface).

Additionally, I'd like to see a comprehensive user module, that manages a user's authorizations, authentication, and permissions, comprehensively, rather than as separate things. We sort of have this already internally on the back end, but it's not very separable from our internal code. I think that's prerequisite to all these little changes to improve the backend security, and would better isolate these changes in a way that other developers can actually write their own pluggable modules to handle these, without worrying about constant interface changes. We're gradually making improvements here, and that's good... but we're not really working towards a good end-goal, I think.

This feature also highlights the fact that authorizors, like authenticators, are really a separate service, and that our API that deals with management of that service, doesn't necessarily make sense. Like createUser/deleteUser wouldn't necessarily make sense for some backend implementations, setAuthorizations doesn't make sense on an Authorizor that is developed externally to the core project, and configured as a plugin. This problem exists now... but is highlighted by interface changes like this, where the goal is to function without those interface methods (getAuths) having a reasonable implementation.

One feature we'd lose here, is the ability for the shell to automatically retrieve authorizations and scan with all the user's authorizations, by default. We'd also need to consider the fact that many users call getAuths for a user, and intersect it with a set of auths, on the client side, before creating a scanner. We'd need to enable that case. This goes back to the comprehensive, public-facing user service interface. As is, I think the existing authenticator/authorizor/tablepermissionshandler are a bit unpolished to consider user-facing (though they're available for experimenting on the back end configuration). But, with a bit of polishing, such as the addition of an intersect method (maybe you can't view authorizations, but you should be able to prune a set), would help support these use cases.

                
> Adjust Authorizor Interface to validate auths instead of retrieving a list
> --------------------------------------------------------------------------
>
>                 Key: ACCUMULO-1681
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1681
>             Project: Accumulo
>          Issue Type: Bug
>          Components: tserver
>            Reporter: John Vines
>            Assignee: John Vines
>             Fix For: 1.6.0
>
>         Attachments: ACCUMULO-1681.patch, ACCUMULO-1681.v2.patch
>
>
> Currently the Authorizor interface is used to request a set of authorizations which then get checked against the authorizations a user is attempting to use. However, some security systems only support the ability to validate authorizations/permissions/roles and not provide a list. That makes these systems (entirely) incompatible with Accumulo when they don't have to be.
> We should switch the behavior of Accumulo to ask the Authorizor (via SecurityOperations) if the auths are valid. The existing getAuths functionality will still use that call and would have potentially limited support, similar to the potentially limited support of any of the set operations.

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