[jira] [Resolved] (RANGER-1961) Fixed spelling error "condtion"

[Zsombor Gegesy (JIRA)]

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

Zsombor Gegesy resolved RANGER-1961.

Resolution: Fixed

Thanks Willie for your contribution!

> Fixed spelling error "condtion"
> ---
>
> Key: RANGER-1961
> URL: https://issues.apache.org/jira/browse/RANGER-1961
> Project: Ranger
>  Issue Type: Bug
>  Components: tagsync
>Affects Versions: master
>Reporter: Willie Engelbrecht
>Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fixed-spelling-mistake-of-condtion-to-condition.patch
>
>
> When creating a new tag policy, under "Add conditions" there is an input box 
> with the text: Please enter condtion.. 
> The patch corrects the spelling to _condition_



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (RANGER-2003) On Report page 'User, Group and Access' details are not shown for policyItem exceeding more than 25 policies

[Nitin Galave (JIRA)]

Nitin Galave created RANGER-2003:


 Summary: On Report page 'User, Group and Access' details are not 
shown for policyItem exceeding more than 25 policies
 Key: RANGER-2003
 URL: https://issues.apache.org/jira/browse/RANGER-2003
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Nitin Galave
Assignee: Nitin Galave
 Fix For: 1.0.0


On Report page 'User, Group and Access' details are not shown for policyItem 
exceeding more than 25 policies



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-2003) On Report page 'User, Group and Access' details are not shown for policyItem exceeding more than 25 policies

[Nitin Galave (JIRA)]

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

Nitin Galave updated RANGER-2003:
-
Attachment: RANGER-2003.patch

> On Report page 'User, Group and Access' details are not shown for policyItem 
> exceeding more than 25 policies
> 
>
> Key: RANGER-2003
> URL: https://issues.apache.org/jira/browse/RANGER-2003
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Nitin Galave
>Assignee: Nitin Galave
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: RANGER-2003.patch
>
>
> On Report page 'User, Group and Access' details are not shown for policyItem 
> exceeding more than 25 policies



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (RANGER-1935) Upgrade Ranger to support Apache Hadoop 3.0.0

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh commented on RANGER-1935:
-

Yes, can we add a 1.1.0 version that I can move it to?

> Upgrade Ranger to support Apache Hadoop 3.0.0
> -
>
> Key: RANGER-1935
> URL: https://issues.apache.org/jira/browse/RANGER-1935
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1935-Upgrade-Ranger-to-support-Apache-Hadoop-.patch
>
>
> This task is to upgrade Ranger to support Apache Hadoop 3.0.0. Here are some 
> notes about the upgrade:
> a) The Hive plugin needs the Hadoop 3.0.0 jars to run the tests properly, as 
> Hive only supports the older Hadoop version, so an exclusion and some 
> additional 3.0.0 dependencies need to be added.
> b) The Storm plugin bundles the hadoop-auth jars in storm-core (although they 
> really should be renamed here). Therefore, we have no option but to package 
> Storm with the Hadoop 2.7.x jars, until such time that Storm upgrades the 
> Hadoop dependency.
> This is an initial patch to get some feedback. If there is broad agreement on 
> the upgrade I will test the distributions properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1738) RangerYarnAuthorizer not compatible with Hadoop-3.0.0

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh updated RANGER-1738:

Fix Version/s: (was: 1.0.0)

> RangerYarnAuthorizer not compatible with Hadoop-3.0.0
> -
>
> Key: RANGER-1738
> URL: https://issues.apache.org/jira/browse/RANGER-1738
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 0.7.1
>Reporter: Hong Shen
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Attachments: 
> 0001-RANGER-1738-RangerYarnAuthorizer-not-compatible-with.patch
>
>
> In the newest hadoop version 3.0.0, YarnAuthorizationProvider has changed.
> The new YarnAuthorizationProvider.java has change the methods checkPermission 
> and setPermission, 
> {code:title=YarnAuthorizationProvider.java|borderStyle=solid}
>   /**
>* Check if user has the permission to access the target object.
>* 
>* @param accessRequest
>*  the request object which contains all the access context info.
>* @return true if user can access the object, otherwise false.
>*/
>   public abstract boolean checkPermission(AccessRequest accessRequest);
>   /**
>* Set permissions for the target object.
>*
>* @param permissions
>*A list of permissions on the target object.
>* @param ugi User who sets the permissions.
>*/
>   public abstract void setPermission(List permissions,
>   UserGroupInformation ugi);
> {code}
> But the RangerYarnAuthorizer extends YarnAuthorizationProvider impletement 
> the old method.
> {code:title=RangerYarnAuthorizer.java|borderStyle=solid}
>   @Override
>   public void setPermission(PrivilegedEntity entity, Map AccessControlList> permission, UserGroupInformation ugi) {
>...
>   @Override
>   public boolean checkPermission(AccessType accessType, PrivilegedEntity 
> entity, UserGroupInformation ugi) {
> {code}
> I think yarn plugin should also impletement the new method. I will add a 
> patch for it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1935) Upgrade Ranger to support Apache Hadoop 3.0.0

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh updated RANGER-1935:

Fix Version/s: (was: 1.0.0)

> Upgrade Ranger to support Apache Hadoop 3.0.0
> -
>
> Key: RANGER-1935
> URL: https://issues.apache.org/jira/browse/RANGER-1935
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Attachments: 
> 0001-RANGER-1935-Upgrade-Ranger-to-support-Apache-Hadoop-.patch
>
>
> This task is to upgrade Ranger to support Apache Hadoop 3.0.0. Here are some 
> notes about the upgrade:
> a) The Hive plugin needs the Hadoop 3.0.0 jars to run the tests properly, as 
> Hive only supports the older Hadoop version, so an exclusion and some 
> additional 3.0.0 dependencies need to be added.
> b) The Storm plugin bundles the hadoop-auth jars in storm-core (although they 
> really should be renamed here). Therefore, we have no option but to package 
> Storm with the Hadoop 2.7.x jars, until such time that Storm upgrades the 
> Hadoop dependency.
> This is an initial patch to get some feedback. If there is broad agreement on 
> the upgrade I will test the distributions properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1824) Upgrade Spring Framework to 3.2.18

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh updated RANGER-1824:

Fix Version/s: (was: 1.0.0)

> Upgrade Spring Framework to 3.2.18
> --
>
> Key: RANGER-1824
> URL: https://issues.apache.org/jira/browse/RANGER-1824
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Attachments: 0001-RANGER-1824-Upgrade-Spring-Framework-to-3.2.18.patch
>
>
> When starting the Admin console, the following appears in the logs:
> 2017-10-02 10:00:35,651 [localhost-startStop-1] WARN  
> org.springframework.security.core.SpringSecurityCoreVersion 
> (SpringSecurityCoreVersion.java:60) -  You are advised to use Spring 
> 3.2.18.RELEASE or later with this version. You are running: 3.2.10.RELEASE
> We should update Spring to 3.2.18



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Review Request 65860: RANGER-2003: On Report page 'User, Group and Access' details are not shown for policyItem exceeding more than 25 policies

[Nitin Galave]

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

Review request for ranger, Gautam Borad, Mehul Parikh, Pradeep Agrawal, and 
Velmurugan Periasamy.


Bugs: RANGER-2003
https://issues.apache.org/jira/browse/RANGER-2003


Repository: ranger


Description
---

On Report page 'User, Group and Access' details are not shown for policyItem 
exceeding more than 25 policies


Diffs
-

  security-admin/src/main/webapp/scripts/views/reports/UserAccessLayout.js 
e0470cf 


Diff: https://reviews.apache.org/r/65860/diff/1/


Testing
---

1.Validated Whether Users/Groups/permissions associated with policy(which is 
available on Next page) are getting displayed for particular service under 
Reports tab.
2.Validated whether Users/Group/Access Details are getting displayed even 
though user moves Forward/Backward and vice versa
3.Also validated for other components.


Thanks,

Nitin Galave

[jira] [Commented] (RANGER-1958) [HBase] Implement getUserPermissions API of AccessControlService.Interface to allow clients to access HBase permissions stored in Ranger

[Ankit Singhal (JIRA)]

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

Ankit Singhal commented on RANGER-1958:
---

bq. do you have patch ready for this?
Not yet, but I can check if I can put up something soon.
 
bq. But incase that is a long way to go and want to leverage on 
RangerHBasePlugin what is the expected implementation on getUserPernissions 
API? Could you please elaborate on the Phoenix request and what is expected out 
from Ranger? That will help us to move forward on this.

getUserPermissions API is expected to return all permission of the requesting 
user on the particular resource(table/namespace/global only) specified in the 
request. 



> [HBase] Implement getUserPermissions API of AccessControlService.Interface to 
> allow clients to access HBase permissions stored in Ranger
> 
>
> Key: RANGER-1958
> URL: https://issues.apache.org/jira/browse/RANGER-1958
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Ankit Singhal
>Priority: Major
>
> We have added the support of ACLs in Phoenix as part of PHOENIX-4198. 
> Currently, the implementation relies on some of the APIs provided by 
> AccessControlService.Interface to get the user permission of the table but we 
> see that the API "AccessControlService.Interface#getUserPermissions"  is not 
> yet implemented in Ranger authorization module for HBase and thus, we are 
> unable to access permissions stored for HBase Table in Phoenix.
> In class RangerAuthorizationCoprocessor
> {code}
> @Override
>   public void getUserPermissions(RpcController controller, 
> AccessControlProtos.GetUserPermissionsRequest request, 
> RpcCallback done) {
>   LOG.debug("getUserPermissions(): ");
>   }
> {code}
> If we just implement this API, we can leverage the current HBase Ranger 
> plugin for Phoenix too.
> Although the long-term solution for Ranger could be to implement the 
> coprocessor hooks for Phoenix as how it has been done for HBase so that we 
> can also authorize new entities like VIEW, SEQUENCES, FUNCTIONs  (which can 
> not be supported with native HBase ACLs) along with Table and Schema. 
> Let me know your thoughts, I can try to put up a patch soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review Request 65858: RANGER-2001:Similar to RANGER-1469, we should check whether the user or group has existed before the installer create a new user or group when user install usersync

[Colm O hEigeartaigh]

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


Ship it!




Ship It!

- Colm O hEigeartaigh


On March 1, 2018, 7:06 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65858/
> ---
> 
> (Updated March 1, 2018, 7:06 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, pengjianhua, Ramesh Mani, 
> Selvamohan Neethiraj, sam  rome, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2001
> https://issues.apache.org/jira/browse/RANGER-2001
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Similar to RANGER-1469, we should check whether the user or group has existed 
> before the installer create a new user or group when user install usersync
> 
> 
> Diffs
> -
> 
>   unixauthservice/scripts/setup.py 5ae9123 
> 
> 
> Diff: https://reviews.apache.org/r/65858/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 65777: RANGER-1967 - Kafka 1.0 support

[Colm O hEigeartaigh]

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



Looks good, I tested Kerberos + Kafka 1.0.0 + Ranger authorization.

- Colm O hEigeartaigh


On Feb. 27, 2018, 11:17 a.m., Zsombor Gegesy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65777/
> ---
> 
> (Updated Feb. 27, 2018, 11:17 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-1967
> https://issues.apache.org/jira/browse/RANGER-1967
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The API changes are not too big, however running Kafka in embedded mode 
> turned out to be a bit trickier beast. I had to add a couple of new flags, 
> otherwise it would wait for 2 other broker to join.
>  The commit also contains logging changes, even a test log4j configuration, 
> just to make the debugging easier.
> 
> 
> Diffs
> -
> 
>   agents-audit/pom.xml 4fa44c5f 
>   plugin-kafka/pom.xml f644646b 
>   
> plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java
>  b3d5a74d 
>   
> plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerGSSTest.java
>  4ea39ed7 
>   
> plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerSASLSSLTest.java
>  fb541cd3 
>   
> plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerTest.java
>  fb0a2c0f 
>   plugin-kafka/src/test/resources/log4j.properties PRE-CREATION 
>   pom.xml 294c422f 
>   ranger-kafka-plugin-shim/pom.xml f1aeee6f 
> 
> 
> Diff: https://reviews.apache.org/r/65777/diff/3/
> 
> 
> Testing
> ---
> 
> Unit & local tests
> 
> 
> Thanks,
> 
> Zsombor Gegesy
> 
>

Re: Review Request 65777: RANGER-1967 - Kafka 1.0 support

[Colm O hEigeartaigh]

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


Ship it!




Ship It!

- Colm O hEigeartaigh


On Feb. 27, 2018, 11:17 a.m., Zsombor Gegesy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65777/
> ---
> 
> (Updated Feb. 27, 2018, 11:17 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-1967
> https://issues.apache.org/jira/browse/RANGER-1967
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The API changes are not too big, however running Kafka in embedded mode 
> turned out to be a bit trickier beast. I had to add a couple of new flags, 
> otherwise it would wait for 2 other broker to join.
>  The commit also contains logging changes, even a test log4j configuration, 
> just to make the debugging easier.
> 
> 
> Diffs
> -
> 
>   agents-audit/pom.xml 4fa44c5f 
>   plugin-kafka/pom.xml f644646b 
>   
> plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java
>  b3d5a74d 
>   
> plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerGSSTest.java
>  4ea39ed7 
>   
> plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerSASLSSLTest.java
>  fb541cd3 
>   
> plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerTest.java
>  fb0a2c0f 
>   plugin-kafka/src/test/resources/log4j.properties PRE-CREATION 
>   pom.xml 294c422f 
>   ranger-kafka-plugin-shim/pom.xml f1aeee6f 
> 
> 
> Diff: https://reviews.apache.org/r/65777/diff/3/
> 
> 
> Testing
> ---
> 
> Unit & local tests
> 
> 
> Thanks,
> 
> Zsombor Gegesy
> 
>

Configuration fields in ranger-kafka-security.xml

[Colm O hEigeartaigh]

Hi all,

I noticed when installing the Kafka plugin from 1.0.0-SNAPSHOT, that it
adds the following in ranger-kafka-security.xml:



ranger.plugin.kafka.policy.rest.client.connection.timeoutMs
12

RangerRestClient Connection Timeout in Milli Seconds




ranger.plugin.kafka.policy.rest.client.read.timeoutMs
3

RangerRestClient read Timeout in Milli Seconds



ranger.policy.rest.client.connection.timeoutMs
12


ranger.policy.rest.client.read.timeoutMs
3


What is the difference between
"ranger.plugin.kafka.policy.rest.client.connection.timeoutMs" and
"ranger.policy.rest.client.connection.timeoutMs"?




-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

[jira] [Assigned] (RANGER-2000) Policy & policy item effective dates to support time-bound and temporary authorization

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni reassigned RANGER-2000:
--

Assignee: Abhay Kulkarni

> Policy & policy item effective dates to support time-bound and temporary 
> authorization
> --
>
> Key: RANGER-2000
> URL: https://issues.apache.org/jira/browse/RANGER-2000
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Srikanth Venkat
>Assignee: Abhay Kulkarni
>Priority: Blocker
> Fix For: 1.0.0
>
>
> Currently Ranger policies have effectiveness period that is permanent i.e. 
> once authored they can only be disabled or enabled. There are many use cases 
> where such policies or even a policy condition needs to be time bound. For 
> example certain financial information about earnings that is sensitive and 
> restricted only until the earnings release date. 
> it would be great to have the ability to specify with each policy or policy 
> condition a time horizon when it is effective (i.e.) either be effective 
> after a certain date and/or expire after a specific date or only valid within 
> a certain time window and have Ranger check whether the policy is effective 
> before evaluating in the policy engine. Therefore, policy authoring can be 
> simplified and does not require any subsequent action from the user, 
> basically making policy authoring a one time effort and users do not have to 
> go back disable the policies once it is past the expiration date.
> This means that:
>  # Ranger policy engine needs to be able to recognize the start and end times 
> for policies or specific policy items (conditions) and enforce them based on 
> period of validity specified by the user.
>  # Active policies should be checked not only based on the resource, user and 
> environment context but also whether the policy itself or policy item 
> condition is effective.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-2000) Policy & policy item effective dates to support time-bound and temporary authorization

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni updated RANGER-2000:
---
Fix Version/s: (was: 1.0.0)
   master

> Policy & policy item effective dates to support time-bound and temporary 
> authorization
> --
>
> Key: RANGER-2000
> URL: https://issues.apache.org/jira/browse/RANGER-2000
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Srikanth Venkat
>Assignee: Abhay Kulkarni
>Priority: Major
> Fix For: master
>
>
> Currently Ranger policies have effectiveness period that is permanent i.e. 
> once authored they can only be disabled or enabled. There are many use cases 
> where such policies or even a policy condition needs to be time bound. For 
> example certain financial information about earnings that is sensitive and 
> restricted only until the earnings release date. 
> it would be great to have the ability to specify with each policy or policy 
> condition a time horizon when it is effective (i.e.) either be effective 
> after a certain date and/or expire after a specific date or only valid within 
> a certain time window and have Ranger check whether the policy is effective 
> before evaluating in the policy engine. Therefore, policy authoring can be 
> simplified and does not require any subsequent action from the user, 
> basically making policy authoring a one time effort and users do not have to 
> go back disable the policies once it is past the expiration date.
> This means that:
>  # Ranger policy engine needs to be able to recognize the start and end times 
> for policies or specific policy items (conditions) and enforce them based on 
> period of validity specified by the user.
>  # Active policies should be checked not only based on the resource, user and 
> environment context but also whether the policy itself or policy item 
> condition is effective.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-2000) Policy & policy item effective dates to support time-bound and temporary authorization

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni updated RANGER-2000:
---
Priority: Major  (was: Blocker)

> Policy & policy item effective dates to support time-bound and temporary 
> authorization
> --
>
> Key: RANGER-2000
> URL: https://issues.apache.org/jira/browse/RANGER-2000
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Srikanth Venkat
>Assignee: Abhay Kulkarni
>Priority: Major
> Fix For: master
>
>
> Currently Ranger policies have effectiveness period that is permanent i.e. 
> once authored they can only be disabled or enabled. There are many use cases 
> where such policies or even a policy condition needs to be time bound. For 
> example certain financial information about earnings that is sensitive and 
> restricted only until the earnings release date. 
> it would be great to have the ability to specify with each policy or policy 
> condition a time horizon when it is effective (i.e.) either be effective 
> after a certain date and/or expire after a specific date or only valid within 
> a certain time window and have Ranger check whether the policy is effective 
> before evaluating in the policy engine. Therefore, policy authoring can be 
> simplified and does not require any subsequent action from the user, 
> basically making policy authoring a one time effort and users do not have to 
> go back disable the policies once it is past the expiration date.
> This means that:
>  # Ranger policy engine needs to be able to recognize the start and end times 
> for policies or specific policy items (conditions) and enforce them based on 
> period of validity specified by the user.
>  # Active policies should be checked not only based on the resource, user and 
> environment context but also whether the policy itself or policy item 
> condition is effective.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-2000) Policy & policy item effective dates to support time-bound and temporary authorization

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni updated RANGER-2000:
---
Description: 
Currently Ranger policies have effectiveness period that is permanent i.e. once 
authored they can only be disabled or enabled. There are many use cases where 
such policies or even a policy condition needs to be time bound. For example 
certain financial information about earnings that is sensitive and restricted 
only until the earnings release date. 

it would be great to have the ability to specify with each policy a time 
horizon when it is effective (i.e.) either be effective after a certain date 
and/or expire after a specific date or only valid within a certain time window 
and have Ranger check whether the policy is effective before evaluating in the 
policy engine. Therefore, policy authoring can be simplified and does not 
require any subsequent action from the user, basically making policy authoring 
a one time effort and users do not have to go back disable the policies once it 
is past the expiration date.

This means that:
 # Ranger policy engine needs to be able to recognize the start and end times 
for policies  and enforce them based on period of validity specified by the 
user.
 # Active policies should be checked not only based on the resource, user and 
environment context but also whether the policy is effective.

  was:
Currently Ranger policies have effectiveness period that is permanent i.e. once 
authored they can only be disabled or enabled. There are many use cases where 
such policies or even a policy condition needs to be time bound. For example 
certain financial information about earnings that is sensitive and restricted 
only until the earnings release date. 

it would be great to have the ability to specify with each policy or policy 
condition a time horizon when it is effective (i.e.) either be effective after 
a certain date and/or expire after a specific date or only valid within a 
certain time window and have Ranger check whether the policy is effective 
before evaluating in the policy engine. Therefore, policy authoring can be 
simplified and does not require any subsequent action from the user, basically 
making policy authoring a one time effort and users do not have to go back 
disable the policies once it is past the expiration date.

This means that:
 # Ranger policy engine needs to be able to recognize the start and end times 
for policies or specific policy items (conditions) and enforce them based on 
period of validity specified by the user.
 # Active policies should be checked not only based on the resource, user and 
environment context but also whether the policy itself or policy item condition 
is effective.


> Policy & policy item effective dates to support time-bound and temporary 
> authorization
> --
>
> Key: RANGER-2000
> URL: https://issues.apache.org/jira/browse/RANGER-2000
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Srikanth Venkat
>Assignee: Abhay Kulkarni
>Priority: Major
> Fix For: master
>
>
> Currently Ranger policies have effectiveness period that is permanent i.e. 
> once authored they can only be disabled or enabled. There are many use cases 
> where such policies or even a policy condition needs to be time bound. For 
> example certain financial information about earnings that is sensitive and 
> restricted only until the earnings release date. 
> it would be great to have the ability to specify with each policy a time 
> horizon when it is effective (i.e.) either be effective after a certain date 
> and/or expire after a specific date or only valid within a certain time 
> window and have Ranger check whether the policy is effective before 
> evaluating in the policy engine. Therefore, policy authoring can be 
> simplified and does not require any subsequent action from the user, 
> basically making policy authoring a one time effort and users do not have to 
> go back disable the policies once it is past the expiration date.
> This means that:
>  # Ranger policy engine needs to be able to recognize the start and end times 
> for policies  and enforce them based on period of validity specified by the 
> user.
>  # Active policies should be checked not only based on the resource, user and 
> environment context but also whether the policy is effective.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (RANGER-2002) Ranger support for time based classifications and business terms from Apache Atlas

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni reassigned RANGER-2002:
--

Assignee: Abhay Kulkarni

> Ranger support for time based classifications and business terms from Apache 
> Atlas
> --
>
> Key: RANGER-2002
> URL: https://issues.apache.org/jira/browse/RANGER-2002
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Srikanth Venkat
>Assignee: Abhay Kulkarni
>Priority: Blocker
> Fix For: master
>
>
> Currently classifications and business glossary terms in Apache Atlas are 
> treated as being valid permanently in Ranger. There are use cases where such 
> classifications are time bound based on customer input (such as financial 
> information about earnings that is sensitive and restricted only until the 
> earnings release) (i.e) either be effective after a certain date/time and/or 
> expire after a specific date/time or valid only during an interval from a 
> start date/time to an end date/time
> Ranger policy engine needs to be able to recognize the start and end times 
> for tags/classifications received from Apache Atlas via tag sync and enforce 
> tag-based policies depending on attributes of the tags that represent its 
> validity period.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-2002) Ranger support for time based classifications and business terms from Apache Atlas

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni updated RANGER-2002:
---
Priority: Major  (was: Blocker)

> Ranger support for time based classifications and business terms from Apache 
> Atlas
> --
>
> Key: RANGER-2002
> URL: https://issues.apache.org/jira/browse/RANGER-2002
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Srikanth Venkat
>Assignee: Abhay Kulkarni
>Priority: Major
> Fix For: master
>
>
> Currently classifications and business glossary terms in Apache Atlas are 
> treated as being valid permanently in Ranger. There are use cases where such 
> classifications are time bound based on customer input (such as financial 
> information about earnings that is sensitive and restricted only until the 
> earnings release) (i.e) either be effective after a certain date/time and/or 
> expire after a specific date/time or valid only during an interval from a 
> start date/time to an end date/time
> Ranger policy engine needs to be able to recognize the start and end times 
> for tags/classifications received from Apache Atlas via tag sync and enforce 
> tag-based policies depending on attributes of the tags that represent its 
> validity period.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-2002) Ranger support for time based classifications and business terms from Apache Atlas

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni updated RANGER-2002:
---
Fix Version/s: (was: 1.0.0)
   master

> Ranger support for time based classifications and business terms from Apache 
> Atlas
> --
>
> Key: RANGER-2002
> URL: https://issues.apache.org/jira/browse/RANGER-2002
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Srikanth Venkat
>Assignee: Abhay Kulkarni
>Priority: Major
> Fix For: master
>
>
> Currently classifications and business glossary terms in Apache Atlas are 
> treated as being valid permanently in Ranger. There are use cases where such 
> classifications are time bound based on customer input (such as financial 
> information about earnings that is sensitive and restricted only until the 
> earnings release) (i.e) either be effective after a certain date/time and/or 
> expire after a specific date/time or valid only during an interval from a 
> start date/time to an end date/time
> Ranger policy engine needs to be able to recognize the start and end times 
> for tags/classifications received from Apache Atlas via tag sync and enforce 
> tag-based policies depending on attributes of the tags that represent its 
> validity period.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review Request 65854: RANGER-1999: Ranger policy engine updates to support list-of-values in access reource

[Madhan Neethiraj]

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

(Updated March 1, 2018, 8:41 p.m.)


Review request for ranger, Don Bosco Durai, Abhay Kulkarni, Nixon Rodrigues, 
and Ramesh Mani.


Changes
---

fix for PMD violations (unused import), optimizations


Bugs: RANGER-1999
https://issues.apache.org/jira/browse/RANGER-1999


Repository: ranger


Description
---

Updated policy engine module to handle resources with multiple values


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/authorization/utils/StringUtil.java
 2835cddd 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessResource.java
 2ee616a1 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessResourceImpl.java
 58004862 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessResourceReadOnly.java
 18bb1f44 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerMutableResource.java
 9fcefbe0 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyresourcematcher/RangerDefaultPolicyResourceMatcher.java
 415263ee 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/RangerAbstractResourceMatcher.java
 acd599a7 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/RangerDefaultResourceMatcher.java
 a7399eed 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/RangerResourceMatcher.java
 8183dedb 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/ResourceMatcher.java
 eab9dbc7 
  
agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
 aad78340 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/RangerResourceTrie.java
 f6c1e4d5 
  
agents-common/src/test/java/org/apache/ranger/plugin/policyengine/TestPolicyEngine.java
 bcd15779 
  
agents-common/src/test/java/org/apache/ranger/plugin/resourcematcher/RangerAbstractResourceMatcherTest.java
 e2c7c270 
  agents-common/src/test/resources/policyengine/test_policyengine_atlas.json 
PRE-CREATION 
  
hive-agent/src/main/java/org/apache/ranger/authorization/hive/authorizer/RangerHiveResource.java
 e4eafc69 
  
ranger-tools/src/main/java/org/apache/ranger/policyengine/perftest/v2/RangerPolicyFactory.java
 0008808e 
  security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 5b7d0859 


Diff: https://reviews.apache.org/r/65854/diff/2/

Changes: https://reviews.apache.org/r/65854/diff/1-2/


Testing
---

- added unit tests to validate the enhancements


Thanks,

Madhan Neethiraj

[jira] [Updated] (RANGER-1999) Policy evaluation to support multiple values for accessed resource

[Madhan Neethiraj (JIRA)]

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

Madhan Neethiraj updated RANGER-1999:
-
Attachment: RANGER-1999-2.patch

> Policy evaluation to support multiple values for accessed resource
> --
>
> Key: RANGER-1999
> URL: https://issues.apache.org/jira/browse/RANGER-1999
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: RANGER-1999-2.patch, RANGER-1999.patch
>
>
> While evaluating access requests, Ranger policy engine picks policies based 
> on the resource value specified in the access request. Currently 
> access-resource abstraction only supports a single value for each 
> resource-type - like database/table/column. Authorization of access to some 
> resources might require the policy engine to pick policies based on multiple 
> values for a resource.
> For example, consider access authorization for an entity in Apache Atlas. An 
> entity has a specific-type and a number of super-types - example: 
> type=database super-types=[dataset, asset]. While authorizing access to a 
> database entity, policies specified for its super-types, dataset and asset, 
> should also be evaluated.
> To enable such usecases, Ranger policy evaluation needs to be enhanced to 
> support a list of value for a resource. Policies that match for any of the 
> given values should be evaluated to determine the access result. Note that 
> this enhancement doesn't require any updates to the policy model; the changes 
> are needed only in the policy-engine.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (RANGER-2004) Update Ranger Atlas Authorizer for the authorization model changes in Atlas

[Madhan Neethiraj (JIRA)]

Madhan Neethiraj created RANGER-2004:


 Summary: Update Ranger Atlas Authorizer for the authorization 
model changes in Atlas
 Key: RANGER-2004
 URL: https://issues.apache.org/jira/browse/RANGER-2004
 Project: Ranger
  Issue Type: Improvement
  Components: plugins
Reporter: Madhan Neethiraj


Apache Atlas authorization model was updated in master branch, in ATLAS-2459, 
for upcoming 1.0 release. This requires corresponding updates in Ranger Atlas 
Authorizer implementation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (RANGER-2004) Update Ranger Atlas Authorizer for the authorization model changes in Atlas

[Madhan Neethiraj (JIRA)]

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

Madhan Neethiraj reassigned RANGER-2004:


Assignee: Nixon Rodrigues

> Update Ranger Atlas Authorizer for the authorization model changes in Atlas
> ---
>
> Key: RANGER-2004
> URL: https://issues.apache.org/jira/browse/RANGER-2004
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Nixon Rodrigues
>Priority: Major
>
> Apache Atlas authorization model was updated in master branch, in ATLAS-2459, 
> for upcoming 1.0 release. This requires corresponding updates in Ranger Atlas 
> Authorizer implementation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review Request 65871: RANGER-2004: updated Ranger authorization plugin for Atlas for the changes in ATLAS-2459

[Madhan Neethiraj]

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

(Updated March 1, 2018, 9:52 p.m.)


Review request for ranger, Gautam Borad, Abhay Kulkarni, Mehul Parikh, Nixon 
Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
Periasamy.


Bugs: RANGER-2004
https://issues.apache.org/jira/browse/RANGER-2004


Repository: ranger


Description (updated)
---

Apache Atlas updated the authorization model in ATLAS-2459, to support 
authroization at instance level. Ranger authorization plugin for Atlas has been 
updated to support this model.
(publishing review for the patch from Nixon)


Diffs
-

  agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
4a550c64 
  plugin-atlas/pom.xml 54917f66 
  
plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
 90e75a1a 


Diff: https://reviews.apache.org/r/65871/diff/1/


Testing
---

Deployed the updated plugin and verified authorization and audit logs for 
various scenarios (entity-read, entity-add-classification, 
entity-remove-classification, ..).


Thanks,

Madhan Neethiraj

Review Request 65871: RANGER-2004: updated Ranger authorization plugin for Atlas for the changes in ATLAS-2459

[Madhan Neethiraj]

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

Review request for ranger, Gautam Borad, Abhay Kulkarni, Mehul Parikh, Nixon 
Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
Periasamy.


Bugs: RANGER-2004
https://issues.apache.org/jira/browse/RANGER-2004


Repository: ranger


Description
---

Apache Atlas updated the authorization model in ATLAS-2459, to support 
authroization at instance level. Ranger authorization plugin for Atlas has been 
updated to support this model.


Diffs
-

  agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
4a550c64 
  plugin-atlas/pom.xml 54917f66 
  
plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
 90e75a1a 


Diff: https://reviews.apache.org/r/65871/diff/1/


Testing
---

Deployed the updated plugin and verified authorization and audit logs for 
various scenarios (entity-read, entity-add-classification, 
entity-remove-classification, ..).


Thanks,

Madhan Neethiraj

[jira] [Updated] (RANGER-2004) Update Ranger Atlas Authorizer for the authorization model changes in Atlas

[Madhan Neethiraj (JIRA)]

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

Madhan Neethiraj updated RANGER-2004:
-
Attachment: RANGER-2004.patch

> Update Ranger Atlas Authorizer for the authorization model changes in Atlas
> ---
>
> Key: RANGER-2004
> URL: https://issues.apache.org/jira/browse/RANGER-2004
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Nixon Rodrigues
>Priority: Major
> Attachments: RANGER-2004.patch
>
>
> Apache Atlas authorization model was updated in master branch, in ATLAS-2459, 
> for upcoming 1.0 release. This requires corresponding updates in Ranger Atlas 
> Authorizer implementation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review Request 65871: RANGER-2004: updated Ranger authorization plugin for Atlas for the changes in ATLAS-2459

[Ramesh Mani]

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




plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
Lines 98 (patched)


Why auditing is not done for certain request like AtlasAdminAccessRequest, 
AtlasTypeAccessRequest?


- Ramesh Mani


On March 1, 2018, 9:52 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65871/
> ---
> 
> (Updated March 1, 2018, 9:52 p.m.)
> 
> 
> Review request for ranger, Gautam Borad, Abhay Kulkarni, Mehul Parikh, Nixon 
> Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-2004
> https://issues.apache.org/jira/browse/RANGER-2004
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Apache Atlas updated the authorization model in ATLAS-2459, to support 
> authroization at instance level. Ranger authorization plugin for Atlas has 
> been updated to support this model.
> (publishing review for the patch from Nixon)
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
> 4a550c64 
>   plugin-atlas/pom.xml 54917f66 
>   
> plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
>  90e75a1a 
> 
> 
> Diff: https://reviews.apache.org/r/65871/diff/1/
> 
> 
> Testing
> ---
> 
> Deployed the updated plugin and verified authorization and audit logs for 
> various scenarios (entity-read, entity-add-classification, 
> entity-remove-classification, ..).
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 65871: RANGER-2004: updated Ranger authorization plugin for Atlas for the changes in ATLAS-2459

[Velmurugan Periasamy]

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




agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json
Lines 12 (patched)


Madhan - I believe existing atlas service definition needs to be updated 
during upgrades, right?


- Velmurugan Periasamy


On March 1, 2018, 9:52 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65871/
> ---
> 
> (Updated March 1, 2018, 9:52 p.m.)
> 
> 
> Review request for ranger, Gautam Borad, Abhay Kulkarni, Mehul Parikh, Nixon 
> Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-2004
> https://issues.apache.org/jira/browse/RANGER-2004
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Apache Atlas updated the authorization model in ATLAS-2459, to support 
> authroization at instance level. Ranger authorization plugin for Atlas has 
> been updated to support this model.
> (publishing review for the patch from Nixon)
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
> 4a550c64 
>   plugin-atlas/pom.xml 54917f66 
>   
> plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
>  90e75a1a 
> 
> 
> Diff: https://reviews.apache.org/r/65871/diff/1/
> 
> 
> Testing
> ---
> 
> Deployed the updated plugin and verified authorization and audit logs for 
> various scenarios (entity-read, entity-add-classification, 
> entity-remove-classification, ..).
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 65871: RANGER-2004: updated Ranger authorization plugin for Atlas for the changes in ATLAS-2459

[Abhay Kulkarni]

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




agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json
Line 15 (original), 48 (patched)


Mandatory attribute is not needed any more. Removing it will keep 
service-def less cluttered.



agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json
Lines 59 (patched)


This attribute will be internally computed based on the resource-hierarchy 
(isValidLeaf=true if the resource is a leaf resource, false otherwise). 
Consider specifying this explicitly only if override is desired. It will keep 
service-def less cluttered.


- Abhay Kulkarni


On March 1, 2018, 9:52 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65871/
> ---
> 
> (Updated March 1, 2018, 9:52 p.m.)
> 
> 
> Review request for ranger, Gautam Borad, Abhay Kulkarni, Mehul Parikh, Nixon 
> Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-2004
> https://issues.apache.org/jira/browse/RANGER-2004
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Apache Atlas updated the authorization model in ATLAS-2459, to support 
> authroization at instance level. Ranger authorization plugin for Atlas has 
> been updated to support this model.
> (publishing review for the patch from Nixon)
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
> 4a550c64 
>   plugin-atlas/pom.xml 54917f66 
>   
> plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
>  90e75a1a 
> 
> 
> Diff: https://reviews.apache.org/r/65871/diff/1/
> 
> 
> Testing
> ---
> 
> Deployed the updated plugin and verified authorization and audit logs for 
> various scenarios (entity-read, entity-add-classification, 
> entity-remove-classification, ..).
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 65871: RANGER-2004: updated Ranger authorization plugin for Atlas for the changes in ATLAS-2459

[Madhan Neethiraj]

> On March 1, 2018, 11:16 p.m., Velmurugan Periasamy wrote:
> > agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json
> > Lines 12 (patched)
> > 
> >
> > Madhan - I believe existing atlas service definition needs to be 
> > updated during upgrades, right?

Vel - given the scope of the authorization model changes, current service-def 
can't be migrated to the new model. We will have to rename it (better delete 
it) and register the new service-def as 'atlas'


- Madhan


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


On March 1, 2018, 9:52 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65871/
> ---
> 
> (Updated March 1, 2018, 9:52 p.m.)
> 
> 
> Review request for ranger, Gautam Borad, Abhay Kulkarni, Mehul Parikh, Nixon 
> Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-2004
> https://issues.apache.org/jira/browse/RANGER-2004
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Apache Atlas updated the authorization model in ATLAS-2459, to support 
> authroization at instance level. Ranger authorization plugin for Atlas has 
> been updated to support this model.
> (publishing review for the patch from Nixon)
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
> 4a550c64 
>   plugin-atlas/pom.xml 54917f66 
>   
> plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
>  90e75a1a 
> 
> 
> Diff: https://reviews.apache.org/r/65871/diff/1/
> 
> 
> Testing
> ---
> 
> Deployed the updated plugin and verified authorization and audit logs for 
> various scenarios (entity-read, entity-add-classification, 
> entity-remove-classification, ..).
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 65871: RANGER-2004: updated Ranger authorization plugin for Atlas for the changes in ATLAS-2459

[Madhan Neethiraj]

> On March 1, 2018, 11:15 p.m., Ramesh Mani wrote:
> > plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
> > Lines 98 (patched)
> > 
> >
> > Why auditing is not done for certain request like 
> > AtlasAdminAccessRequest, AtlasTypeAccessRequest?

Default audit handler is used for AdminAccessRequest and TypeAccessRequest. 
Since EntityAccessRequest is more complicated, a custom audit handler is used. 
All access requests are indeed audited.


- Madhan


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


On March 1, 2018, 9:52 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65871/
> ---
> 
> (Updated March 1, 2018, 9:52 p.m.)
> 
> 
> Review request for ranger, Gautam Borad, Abhay Kulkarni, Mehul Parikh, Nixon 
> Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-2004
> https://issues.apache.org/jira/browse/RANGER-2004
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Apache Atlas updated the authorization model in ATLAS-2459, to support 
> authroization at instance level. Ranger authorization plugin for Atlas has 
> been updated to support this model.
> (publishing review for the patch from Nixon)
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
> 4a550c64 
>   plugin-atlas/pom.xml 54917f66 
>   
> plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
>  90e75a1a 
> 
> 
> Diff: https://reviews.apache.org/r/65871/diff/1/
> 
> 
> Testing
> ---
> 
> Deployed the updated plugin and verified authorization and audit logs for 
> various scenarios (entity-read, entity-add-classification, 
> entity-remove-classification, ..).
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 65871: RANGER-2004: updated Ranger authorization plugin for Atlas for the changes in ATLAS-2459

[Madhan Neethiraj]

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

(Updated March 1, 2018, 11:50 p.m.)


Review request for ranger, Gautam Borad, Abhay Kulkarni, Mehul Parikh, Nixon 
Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
Periasamy.


Changes
---

updates for the review comments


Bugs: RANGER-2004
https://issues.apache.org/jira/browse/RANGER-2004


Repository: ranger


Description
---

Apache Atlas updated the authorization model in ATLAS-2459, to support 
authroization at instance level. Ranger authorization plugin for Atlas has been 
updated to support this model.
(publishing review for the patch from Nixon)


Diffs (updated)
-

  agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
4a550c64 
  plugin-atlas/pom.xml 54917f66 
  
plugin-atlas/src/main/java/org/apache/ranger/authorization/atlas/authorizer/RangerAtlasAuthorizer.java
 90e75a1a 


Diff: https://reviews.apache.org/r/65871/diff/2/

Changes: https://reviews.apache.org/r/65871/diff/1-2/


Testing
---

Deployed the updated plugin and verified authorization and audit logs for 
various scenarios (entity-read, entity-add-classification, 
entity-remove-classification, ..).


Thanks,

Madhan Neethiraj

Re: Review Request 65739: RANGER-1985: Auditing for Ranger usersync operations

[Sailaja Polavarapu]

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

(Updated March 2, 2018, 12:17 a.m.)


Review request for ranger, Ankita Sinha, Gautam Borad, Abhay Kulkarni, Madhan 
Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja 
Polavarapu, and Velmurugan Periasamy.


Changes
---

Fixed a minor issue with postgres db script as well as added indexes for 
event_time, sync_source, and user_name for all db flavors


Bugs: RANGER-1985
https://issues.apache.org/jira/browse/RANGER-1985


Repository: ranger


Description
---

Added code to support auditing for Ranger Usersync operations. This includes 
auditing for all the sync sources (unix, file, and LDAP/AD) for every sync 
interval. Also includes Rest API for showing these audits in Ranger UI.


Diffs (updated)
-

  security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql d516d64e 
  security-admin/db/mysql/patches/031-create-schema-for-usersync-audit-info.sql 
PRE-CREATION 
  security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql abc7d593 
  
security-admin/db/oracle/patches/031-create-schema-for-usersync-audit-info.sql 
PRE-CREATION 
  security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
88629463 
  
security-admin/db/postgres/patches/031-create-schema-for-usersync-audit-info.sql
 PRE-CREATION 
  
security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql 
bf3d954b 
  
security-admin/db/sqlanywhere/patches/031-create-schema-for-usersync-audit-info.sql
 PRE-CREATION 
  security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
56e2e99a 
  
security-admin/db/sqlserver/patches/031-create-schema-for-usersync-audit-info.sql
 PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 034053d2 
  security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 71298a41 
  security-admin/src/main/java/org/apache/ranger/common/AppConstants.java 
4a02e26b 
  security-admin/src/main/java/org/apache/ranger/db/RangerDaoManagerBase.java 
d61cbc7b 
  security-admin/src/main/java/org/apache/ranger/db/XXUgsyncAuditInfoDao.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/entity/XXUgsyncAuditInfo.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/rest/AssetREST.java 3c274e3f 
  security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java a07c243a 
  
security-admin/src/main/java/org/apache/ranger/security/context/RangerAPIList.java
 460c7fda 
  
security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoService.java
 PRE-CREATION 
  
security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoServiceBase.java
 PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/view/VXFileSyncSourceInfo.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/view/VXLdapSyncSourceInfo.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/view/VXUgsyncAuditInfo.java 
PRE-CREATION 
  
security-admin/src/main/java/org/apache/ranger/view/VXUgsyncAuditInfoList.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/view/VXUnixSyncSourceInfo.java 
PRE-CREATION 
  security-admin/src/main/resources/META-INF/jpa_named_queries.xml 35ba30d9 
  security-admin/src/main/resources/META-INF/persistence.xml 20f5bbac 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapDeltaUserGroupBuilder.java
 2852b320 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapPolicyMgrUserGroupBuilder.java
 18366ef1 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapUserGroupBuilder.java
 6b2648d9 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/model/FileSyncSourceInfo.java
 PRE-CREATION 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/model/LdapSyncSourceInfo.java
 PRE-CREATION 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/model/UgsyncAuditInfo.java 
PRE-CREATION 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/model/UnixSyncSourceInfo.java
 PRE-CREATION 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/FileSourceUserGroupBuilder.java
 713c8688 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
 864d884d 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/UnixUserGroupBuilder.java
 60ce08d1 
  ugsync/src/main/java/org/apache/ranger/usergroupsync/UserGroupSink.java 
494efc21 


Diff: https://reviews.apache.org/r/65739/diff/5/

Changes: https://reviews.apache.org/r/65739/diff/4-5/


Testing
---

1. Tested with different types of sync sources (Unix, File, and LDAP/AD)
2. Also tested with incremental sync enabled for AD sync source.
3. Tested the Rest API for showing audits in Ranger UI.


Thanks,

Sailaja Polavarapu

Re: Review Request 65858: RANGER-2001:Similar to RANGER-1469, we should check whether the user or group has existed before the installer create a new user or group when user install usersync

[pengjianhua]

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


Ship it!




Ship It!

- pengjianhua


On 三月 1, 2018, 7:06 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65858/
> ---
> 
> (Updated 三月 1, 2018, 7:06 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, pengjianhua, Ramesh Mani, 
> Selvamohan Neethiraj, sam  rome, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2001
> https://issues.apache.org/jira/browse/RANGER-2001
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Similar to RANGER-1469, we should check whether the user or group has existed 
> before the installer create a new user or group when user install usersync
> 
> 
> Diffs
> -
> 
>   unixauthservice/scripts/setup.py 5ae9123 
> 
> 
> Diff: https://reviews.apache.org/r/65858/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

[jira] [Resolved] (RANGER-2001) Similar to RANGER-1469, we should check whether the user or group has existed before the installer create a new user or group when user install usersync

[Qiang Zhang (JIRA)]

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

Qiang Zhang resolved RANGER-2001.
-
   Resolution: Fixed
Fix Version/s: master

> Similar to RANGER-1469, we should check whether the user or group has existed 
> before the installer create a new user or group when user install usersync
> 
>
> Key: RANGER-2001
> URL: https://issues.apache.org/jira/browse/RANGER-2001
> Project: Ranger
>  Issue Type: Improvement
>  Components: usersync
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Major
> Fix For: master
>
> Attachments: 
> 0001-RANGER-2001-Similar-to-RANGER-1469-we-should-check-w.patch
>
>
> Similar to RANGER-1469, we should check whether the user or group has existed 
> before the installer create a new user or group when user install usersync



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)