Don, Ramesh, Abhay -- thank you for your replies. I am still quite confused, though :( While Ramesh and Abhay state that a client needs to provide group membership explicitly when calling isAccessAllowed() plugin API, Don implies that it is not necessary and we can only call with a username.
Also, one of our engineers tested with LDAP groups and says that LDAP groups work, while groups created via Ranger UI do not. By "work" I mean when a user is a member of the group and only a group policy is defined, then passing only the username results in policy evaluating correctly and granting access to the resource. I have not yet tested this LDAP scenario myself. So, I'll try asking again: - Does the client have to pass user groups to API call or passing just a username is sufficient ? - If Ranger plugin is able to get user-group membership from Ranger Admin, does it happen during policy sync or as a separate process ? If separate, how often does the sync happen ? - Might passing an empty set for roles parameter to the API circumvent automatic lookup (if such even exists) ? Should we pass null instead ? - Might there be a difference between handling LDAP groups vs. groups manually created ? -- Thanks, Alex. On 2017-03-24 16:12 (-0700), Don Bosco Durai <bo...@apache.org> wrote: > Alex > > Both Abhay and Ramesh are correct. In the Hadoop eco-system we want to ensure > that the users and groups are consistent across all components. And > generally, AD/LDAP or Unix system user/groups are the source of truth. > > > >>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 ? > > Based on some of the earlier discussion on the HAWQ/Ranger integration design > model, it was decided to run the Ranger Plugin in another process. If it is > still the case, you just need to send the user from the HAWQ side and the > Ranger Plugin would be able to get the groups from the AD/LDAP/Unix using > Hadoop Common APIs. Ranger does the same for Kafka and Solr integrations, > because both these systems call the Ranger plugin API only with the username. > > Let me know if you need additional information. > > Thanks > > Bosco > > > > > On 3/24/17, 12:50 PM, "Ramesh Mani" <rm...@hortonworks.com> wrote: > > Adding to Abhay comment, > > In most of the Ranger Plugin from the components side we use > org.apache.hadoop.security.UserGroupInformation API > > https://hadoop.apache.org/docs/r1.0.4/api/org/apache/hadoop/security/UserGr > oupInformation.html which will wrap around JAAS and provides the mechanism > to determine the User and Groups. Please check if this can be used. > > Thanks, > Ramesh > > On 3/24/17, 12:03 PM, "Abhay Kulkarni" <akulka...@hortonworks.com> wrote: > > >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. > > > > > > > > >
