[jira] [Assigned] (RANGER-1476) External users not editable through Ranger UI

[Sailaja Polavarapu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Polavarapu reassigned RANGER-1476:
--

Assignee: Nitin Galave

> External users not editable through Ranger UI
> -
>
> Key: RANGER-1476
> URL: https://issues.apache.org/jira/browse/RANGER-1476
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Anuja Leekha
>Assignee: Nitin Galave
>Priority: Critical
>  Labels: ranger
> Fix For: 0.7.1
>
>
> External users not editable through Ranger UI. Need to be able to change role.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-1476) External users not editable through Ranger UI

[Anuja Leekha (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anuja Leekha updated RANGER-1476:
-
Request participants:   (was: )
   Fix Version/s: 0.7.1

> External users not editable through Ranger UI
> -
>
> Key: RANGER-1476
> URL: https://issues.apache.org/jira/browse/RANGER-1476
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Anuja Leekha
>Priority: Critical
>  Labels: ranger
> Fix For: 0.7.1
>
>
> External users not editable through Ranger UI. Need to be able to change role.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (RANGER-1476) External users not editable through Ranger UI

[Anuja Leekha (JIRA)]

Anuja Leekha created RANGER-1476:


 Summary: External users not editable through Ranger UI
 Key: RANGER-1476
 URL: https://issues.apache.org/jira/browse/RANGER-1476
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Anuja Leekha
Priority: Critical


External users not editable through Ranger UI. Need to be able to change role.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Question about group policies

[Don Bosco Durai]

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"  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"  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"  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.
>
>

Re: Question about group policies

[Ramesh Mani]

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"  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"  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.
>
>

Re: Question about group policies

[Abhay Kulkarni]

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"  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.

Question about group policies

[Alexander Denissov]

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.

Re: Review Request 56807: RANGER-1392: Hive test connection is failing even if jdbc.url configured is correct with Kerberos authentication

[Velmurugan Periasamy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56807/#review170046
---


Ship it!




Ship It!

- Velmurugan Periasamy


On March 23, 2017, 8:51 p.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56807/
> ---
> 
> (Updated March 23, 2017, 8:51 p.m.)
> 
> 
> Review request for ranger, Ramesh Mani and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1392
> https://issues.apache.org/jira/browse/RANGER-1392
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> With kerberos authentication, hive test connection fails with an error 
> java.lang.RuntimeException: class 
> org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback not 
> org.apache.hive.org.apache.hadoop.security.GroupMappingServiceProvider. This 
> is because of the hive-jdbc*-standalone.jar is located in wrong location 
> under ranger admin.
> 
> 
> Diffs
> -
> 
>   src/main/assembly/admin-web.xml 7a18a34 
> 
> 
> Diff: https://reviews.apache.org/r/56807/diff/2/
> 
> 
> Testing
> ---
> 
> 1. Verified ranger admin tar file is built with the jar file location changes 
> as intended.
> 2. Verified manually updating the jar location in a secure cluster and test 
> connection is successful.
> 
> 
> Thanks,
> 
> Sailaja Polavarapu
> 
>