Hi Alex, This is exactly right. Users, groups and their associations in Ranger (specifically Ranger Admin) are props for being able to define policies. They are not the Œsource of truth¹. It is expected that the correct user <‹-> group associations will be available in the component (service) from appropriate authentication system, and provided to Ranger Plugin as part of authorization request.
Thanks! -Abhay On 3/24/17, 11:51 AM, "Alexander Denissov" <adenis...@pivotal.io> wrote: >Hi Ranger experts, > >We are developing a custom Ranger Plugin for Apache HAWQ(incubating) and >noticed that group policies are not behaving as we expected. > >In Ranger, we define a user U (actually synched from OS). We then manually >define group G and enroll user U into it. We then define a policy and >grant >a privilege to the group G in this policy. > >On the client side, we do not know that user U belongs to group G, as this >information is only defined in Ranger. When we request policy evaluation, >we send an empty set for the userGroups API parameter, assuming Ranger >will >use its internal mapping. But the access is denied by Ranger. > >So, it seems Ranger will not use the information from its internal user ><--> group mapping when evaluating policies and would rely on client >providing the set of groups for the user explicitly ? > >This also means user <--> group mapping in Ranger is NOT the source of >truth, but rather a mirror of some other authentication system (OS, LDAP, >etc) and a service will need to fetch this information upon user >authentication and provide to Ranger ? > >I will appreciate clarification on these points. >-- >Thanks, >Alex.
