[
https://issues.apache.org/jira/browse/ACCUMULO-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762309#comment-13762309
]
Christopher Tubbs commented on ACCUMULO-1681:
---------------------------------------------
{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.{quote}
Technically, quoting was introduced to avoid the reserved character problem,
not to allow for arbitrary bytes. There's still good reasons to treat this as
human-readable. The fact that it uses bytes for its contains method is
incidental to the history of treating everything as bytes. I don't know that
"contains" was ever really considered part of the public API... it's just a
getter to power internal use of the Authorizations object. Since it's there, we
can treat it as public API... for historical reasons, but I'd really want any
improvements to this API (like the addition of an AuthorizationsContainer) to
reflect and enforce the human-readable assumptions, rather than to follow
Authorizations.contains(). Since this is something new, and not simply a
modification of something that we're stuck with, it seems like it's a good
opportunity to improve this API all around.
{quote}I'm not sure how I feel exposing the SecurityOperations as a whole to
users.{quote}
While the existing backend SecurityOperation (singular for the backend) does
provide similar functionality to the type of centralized "flexing point" that
I'd prefer, I'd want something that is logically more user-centric rather than
generically "security" centric. In other words, something that takes
Credentials on the backend and provides a User instance, with methods like
"canPerform(Action)" and "hasAuthorization(Authorization)" and
"isAuthenticated()". This would allow us to prepackage things like an
LDAPUserModule or an ZooKeeperUserModule or a CustomUserModule (that maybe uses
Kerberos for authentication, LDAP for authorizations, and a policy file for
permissions).
What I'd really like is for us to come up with a comprehensive solution that
implements all these improvements and push for it to be a major feature of an
upcoming release (1.7? maybe call it 2.0?). Without that comprehensive
solution, I'm reluctant to get on board for this in 1.6.
> 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
