sentry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SENTRY-551) Extend the ProviderBackend interface method getRoles when Solr/Sentry integation with DB Provider
Date Tue, 02 Dec 2014 23:25:13 GMT

    [ https://issues.apache.org/jira/browse/SENTRY-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232295#comment-14232295
] 

Gregory Chanan commented on SENTRY-551:
---------------------------------------

bq.  1) Why is the group mapping consulted twice (once by the client, to be able to pass to
the sentry service) and once by the sentry service for the "no acces" check. There should
be a single source of truth for each invocation – either the groups are the client groups
or the groups are the service groups. Mixing them is just confusing.

Maybe a better way of saying this is that the groups should be resolved by client or the backend.

> Extend the ProviderBackend interface method getRoles when Solr/Sentry integation with
DB Provider
> -------------------------------------------------------------------------------------------------
>
>                 Key: SENTRY-551
>                 URL: https://issues.apache.org/jira/browse/SENTRY-551
>             Project: Sentry
>          Issue Type: Bug
>            Reporter: shenguoquan
>            Assignee: shenguoquan
>         Attachments: SENTRY-551.001.patch
>
>
> In document-level security, the class QueryDocAuthorizationComponent is used to get roles
the request user belong to and 
> adds a FilterQuery with the roles to restrict certain documents.Right now the procedure
of QueryDocAuthorizationComponent used to get roles the request user belong to as following:
> {code}Roles= QueryDocAuthorizationComponent.getRoles(requestUser) ->ProviderBackend.getRoles(GroupMappingService.getGroups(requestUser)){code}
> The interface ProviderBackend as following:
> {code}public interface ProviderBackend {
> public ImmutableSet<String> getRoles(Set<String> groups, ActiveRoleSet roleSet);
> ...
> }{code}
> The interface must be extended as following:
>  {code}public interface ProviderBackend {
> public ImmutableSet<String> getRoles(String requestor, Set<String> groups,
ActiveRoleSet roleSet);
> ...
> }{code}
> That's the reason:
> ProviderBackend.getRoles(groups)
> The roles which the group belong to has been gotten through the providerBackend. Currently
the Solr only uses a simple policy file as the backend, the format policy is as following:
> [groups]
> ops_group = ops_role
> [roles]
> ops_role = ...
> This policy is parsed through the class SimpleFileProviderBackend, it implements the
interface ProviderBackend. This class is used to determine the relationship between the roles
and groups. You can see that when user call SimpleFileProviderBackend.getRole(ops_group),
it returns ops_role.
> However, when security search integration with DB store, the relationship between group
and roles will be stored in the Database and must through the Sentry Service. There is a SimpleDBProviderBackend
implemented the interface ProviderBackend can communication with Sentry Service
> to get roles information. The Sentry Service exposes the thrift API like this: getRoles(requestUser,
groups). Why the Sentry Service exposed API has a extra parameter requestUser, it is a protection
mechanism. If the requestUser dosen’t belong to the asked groups, it has no access get the
roles information the groups belong to. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message