Community Articles
Find and share helpful community-sourced technical articles
Labels (2)

Many access control policies require additional context outside of the resources and security principals that are used by default to evaluate policy decisions. For example, knowledge regarding the time of day and the geographic source of attempted access may dictate whether that access is allowed or denied.

Ranger policy evaluation occurs in three distinct steps, 1) request creation, 2) policy evaluation, and 3) post-evaluation. In order to extend the Ranger plugin for a particular service, the request context has to be enriched. For example, enriching the authorization request with the time of day or originating geographic location is needed to evaluate those policies effectively.

The first step to enriching the request context is to register a Context Enricher with the service in question. For this example, we will use Hive and our goal will be to enrich the context with its geographic origination. Ranger 0.6 includes the RangerFileBasedGeolocationProvider, which can be used to add this context based on a data file in the IP2Location format, as in the below example. We will store this data file on the Ranger server in /etc/ranger/geo.

     IP_FROM,IP_TO,COUNTRY_CODE,COUNTRY_NAME,REGION,CITY,,US,United States,California,Santa Clara,,US,United States,Colorado,Broomfield,,US,United States,Texas,Irving

We will register this Context Enricher for the Hive service using the Ranger API. We can first retrieve the service definition via the following GET request, where the authentication credentials and Ranger host URI are updated as appropriate.

curl -u admin:admin -X GET http://$RANGER_HOST:6080/service/public/v2/api/servicedef/name/hive

We will then post this service definition back to the Ranger API, with the following entries added

"contextEnrichers": [
      "itemId": 1,
      "name": "GeoEnricher",
      "enricher": "org.apache.ranger.plugin.contextenricher.RangerFileBasedGeolocationProvider",
      "enricherOptions": {
        "FilePath": "/etc/ranger/geo/geo.txt",
        "IPInDotFormat": "true"

We will also need to register the Policy Conditions with this service definition. The Policy Conditions will be used to evaluate the authorization request, along with the usual conditions such as security principal, type of access, and object. In this case, the condition will be based on the value of the LOCATION_COUNTRY_CODE mapped to the IP range in which the source IP falls.

"policyConditions": [
      "itemId": 1,
      "name": "location-outside",
      "label": "Accessed from outside of location?",
      "description": "Accessed from outside of location?",
      "evaluator": "org.apache.ranger.plugin.conditionevaluator.RangerContextAttributeValueNotInCondition",
      "evaluatorOptions": {
        "attributeName": "LOCATION_COUNTRY_CODE"

We will post this updated service definition by saving the changes in hiveService2.json and using the Ranger API to commit the change.

curl -v -H 'Content-Type: application/json' -u admin:admin -X PUT --data @hiveService2.json http://$RANGER_HOST:6080/service/public/v2/api/servicedef/name/hive

We can now see these Policy Conditions when adding new Hive policies to Ranger.


This policy condition uses the LOCATION_COUNTRY_CODE field, so the condition value is a country code like 'US'


New Contributor

@slachtermanThank you for this fantastic tutorial. I'm trying to restrict access based on location and time of day. Forgive my ignorance but what is the syntax once I get to this last step for "Accessed from outside of location?:" to actually define the policy? And what part of the hiveService2.json would I have to change to get time of day policy capabilities? Thank you!

Hi @Kate Shaw, you bet. I edited the answer to include the details regarding the policy condition value, it is mapped to LOCATION_COUNTRY_CODE in this case.

For Time of Day capabilities, you would register a policy condition using the RangerTimeOfDayMatcher evaluator. The time of day pattern value would look like, for example, "9 AM - 5 PM".

New Contributor

@slachtermanThank you! At bit embarrassed I wasn't able to figure that out. Where is the RangerTimeofDayMatcher evaluator set? Is it a field in the hiveService.json that needs to be set just like the Location Service? Is so where/how is it set?

My pleasure, @Kate Shaw. Yes, that's right, you would specify org.apache.ranger.plugin.conditionevaluator.RangerTimeOfDayMatcher as the evaluator value within the policyConditions array as above (with evaluatorOptions empty in this case). Policy conditions are registered via the HTTP PUT call as above, with the full JSON document as the payload.



I followed the steps above stated and I was not successful in creating dynamic context. Below are the steps.

1. I created the json file with the "contextEnrichers" and "policyConditions" in a json file (validated with json validator tool)

2. ran the curl command

"curl -v -H 'Content-Type: application/json'-u admin:admin -X PUT --data hiveService2.json http://<FQDN>:6080/service/public/v2/api/servicedef/name/hive" and got the below output.

* Server auth using Basic with user 'admin' > PUT /service/public/v2/api/servicedef/name/hive HTTP/1.1 > Authorization: Basic YWRtaW46YWRtaW4= > User-Agent: curl/7.29.0 > Host: FQDN:6080 > Accept: */* > Content-Type: application/json > Content-Length: 17 > * upload completely sent off: 17 out of 17 bytes < HTTP/1.1 404 Not Found < Server: Apache-Coyote/1.1 < Set-Cookie: RANGERADMINSESSIONID=26D6411248523A3341C7680AABC8A68A; Path=/; HttpOnly < X-Frame-Options: DENY < Content-Length: 0 < Date: Thu, 25 Jan 2018 22:24:57 GMT < * Connection #0 to host <FQDN> left intact

Let me know where I went wrong. am using HDP 2.6.3

@Sankaru Thumuluru you need to replace FQDN with the fully-qualified domain name of the host running the Ranger Admin service in your environment. Your curl command is returning a 404 because http://<FQDN>:6080/service/public/v2/api/servicedef/name/hive is not a valid URL



I did that. But for security purpose, I didn't put the server name in the post. I worked with API in earlier project and we were able to do the similar thing for kerberos client and worked fine there. But here I am getting the error.


Can you please provide me the solution?



you want anymore information from me to resolve the issue as I am struck here and not able to move with the other policy


Sorry for the late(very late) update on the this. The issue was resolved by myself.

Cloudera Employee

Hi Sankar,


Could you please post the resolution ?


Cloudera Employee

Working in CDP as well thank you!

Don't have an account?
Version history
Revision #:
2 of 2
Last update:
‎08-17-2019 09:48 AM
Updated by:
Top Kudoed Authors