[
https://issues.apache.org/jira/browse/SENTRY-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
guoquanshen updated SENTRY-551:
-------------------------------
Description:
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.
> 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: guoquanshen
> Assignee: guoquanshen
>
> 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)
