accumulo-notifications mailing list archives

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


John Vines 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).

Actually, I thought the rules for visibilities changed to allow quoted strings which could
contain anything. Regardless, that contains() method is exactly the same as the existing Authorizations.contains()
method. If you want to change that, that is an entirely separate issue.

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.

I'm not sure how I feel exposing the SecurityOperations as a whole to users. But making that
pluggable still wouldn't have caught this because it requires changes to how the TServer handled
authorizations and constraints. The end goal is to make a pluggable system that has flexibility,
but the question is what is the flexing point. Do we want people to drop in alternative tserver
client handlers to deal with it?

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.

Agreed. But until we write a separate manager for the classic ZooKeeper based ones, we need
to keep these around.

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.

Correct, and I think that once we have the ZooKeeper security manager in place, getAuths will
be the one method that has optional support. But adding in a getAuthsSubset or something like
that to get that would be something worth exploring. However, that would require an iterative
check as the basic model for some of these Authorization systems are "Do I have this/these
auths, Y/N?", not "Which of these auths do I have?". But it should be doable.
> 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