accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1681) Adjust Authorizor Interface to validate auths instead of retrieving a list
Date Sat, 07 Sep 2013 00:52:52 GMT


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

View raw message