[
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
