[
https://issues.apache.org/jira/browse/ACCUMULO-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13760864#comment-13760864
]
John Vines commented on ACCUMULO-1681:
--------------------------------------
{quote}
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).
{quote}
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.
{quote}
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.
{quote}
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?
{quote}
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.
{quote}
Agreed. But until we write a separate manager for the classic ZooKeeper based
ones, we need to keep these around.
{quote}
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.
{quote}
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: 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
