Authentication principle of Ranger plug-in

ranger The next two articles on plug-in development introduce how to ranger Support a new service in , And develop corresponding client-side plug-ins . But know what it is and why , Behind the simple interface calls , How to perform permission verification internally . This article will briefly talk about its internal implementation principle .

【 Policy related classes in the plug-in 】

---

from ranger Of web The console can see ：

• A specific service , There may be several different policy repositories ： Resource access control policy repository （Access）, The resulting column access control policy repository （Masking）, The resulting row access control policy repository （Row Level Filter）

• Each policy repository can be configured with multiple policies

• Each strategy contains different strategy conditions

  Policy conditions include ：

  - Permissible conditions （Allow Conditions）

  - Conditions excluded from the allowable conditions （Exclude from Allow Conditions）

  -  Veto conditions （Deny Conditions）

  -  Conditions excluded from veto conditions （Exclude from Deny Conditions）

• These policy conditions can contain multiple policy entries , Each policy entry consists of roles 、 user 、 User group 、 The access types of resources consist of .

  
  

As shown in the figure below ：

stay ranger Inside the plug-in , There are a series of related classes corresponding to this information . Class diagram information is shown in the following figure ：

• ServicePolicies

  A collection of policies for a policy repository of a service .

• RangerPolicy

  Corresponding to a specific strategy , It contains several important class members ：

  - resources： One map surface ,key Name the resource ,value by RangerPolicyResource Instance object of , Records the resource information contained in the policy .

  - policyItems： The set of policy entries in the allowed conditions in the corresponding policy

  - denyPolicyItems： Set of policy entries corresponding to the veto condition in the policy

  - allowException： Set of policy entries corresponding to the conditions excluded from the allowed conditions in the policy

  - denyException： Set of policy entries corresponding to the conditions excluded in the veto conditions in the policy

  Be careful ：policyItems、denyPolicyItems、allowException、denyException Are different instance objects of the same class .

• RangerPolicyResource

  Corresponding to a specific resource , Its class members value Indicates a list of specific values for this resource . Because in web Console , Multiple values can be configured for the same resource .

• RangerPolicyItem

  Corresponding to a specific policy entry . Its class members users、groups、roles They are users 、 User group 、 Character list ;access It's a RangerPolicyItemAccess List of instance objects , Indicates which resource access types the policy entry contains ;conditions It's a RangerPolicyItemCondition List of instance objects , Indicates which custom condition policies the policy entry contains .

• RangerPolicyItemAccess

  Describe a specific resource access type . Its class members type Indicates the type of access .

• RangerPolicyItemCondition

  Policy entries for custom policy conditions .

【 Related classes in the authentication process 】

---

The above classes only describe permission related policies , These descriptions alone , It is not enough to complete the access control of resource permissions . therefore , stay ranger The internal implementation of the plug-in , It includes a policy engine to drive the completion of specific resource access control logic .

The authentication logic in the plug-in can be divided into these layers from top to bottom , Each layer corresponds to a set of related interfaces and implementation classes .

• RangerBasePlugin

  The entry of resource access control , Finally, you need to call the isAccessAllowed Interface for permission verification

• RangerPolicyEngineImpl

  The concrete implementation class of the policy engine , Realized RangerPolicyEngine Interface

• RangerEngine

  Policy repositories that contain services , And provide interfaces by type 、Tag、Zone Get the corresponding policy warehouse .

• RangerPolicyRepository

  Represents a strategy warehouse , There is usually only one class instance . But for ranger Some advanced uses of ：SecurityZone、 be based on tag Permission verification of , There will be corresponding class instances .

• RangerPolicyEvaluator

  Abstract class of policy matching expression , from The dimension of strategy Provide authentication calculation interface , Internally, the specific authentication logic is completed by calling the interfaces of different policy items matching expression class instances .

• RangerPolicyItemEvaluator

  Abstract class of policy item expression , from The dimension of the policy entry Provide authentication calculation interface .

【 Authentication processing flow 】

---

Before authentication , The plug-in needs to be initialized first , During initialization, a thread will be started periodically from ranger Server pull strategy , Each pull strategy essentially sends one rest request ,ranger After the server receives the request , Press json Format organization sent to plug-ins .

After the plug-in receives the request, it will respond , While the local disk cache , Construct object instances of the above-mentioned related classes in memory .

After the policy is saved locally , The authentication process is shown in the figure below ：

1. In our code, we just need to call RangerBasePlugin Provided isAccessAllowed、evalDataMaskPolicies、evalRowFilterPolicy These methods trigger permission verification .

   
   

2. stay RangerBasePlugin Within these methods , Unified call RangerPolicyEngineImpl Of evaluatePolicies Method to verify permissions . Different entrances , Corresponding to different policy types （POLICY_TYPE_ACCESS、POLICY_TYPE_DATAMASK、POLICY_TYPE_ROWFILTER）

3. adopt policyengine Interface to get the correct policy repository .

4. From the policy repository , Resources on request 、 Get matching policyEvaluator list .

5. Yes policyEvaluator List one call evaluator Perform permission matching , Once there is a definite result, it returns （ End cycle , No subsequent calls ）

6. stay policyEvaluator Of evaluator Interface , Traverse policy entries in different policy conditions , And call the corresponding interface （isMatch）, Get the policy entry that matches the access action , Then determine whether access is allowed , Finally, the authority verification result is obtained .

To sum up ： This paper mainly introduces ranger Implementation classes related to policy and authentication in the plug-in , And the logic flow of authentication . In the process of source code research , I found that there are many small details , There is no explanation here . for example , How to sort multiple policies containing the same resource , How different strategy conditions in the same strategy interact （ Permissible conditions 、 Veto conditions 、 Exclusion conditions ） wait . These contents have no impact on the overall process , Later, I will take time to supplement .

Okay , That's all for this article , Originality is not easy. , give the thumbs-up , Looking at , Sharing is the best support , thank you ～

Recommended reading ：

---

ranger Plug-in development （ On ）

ranger Plug-in development （ Next ）

This article is from WeChat official account. - hncscwc（gh_383bc7486c1a）.
If there is any infringement , Please contact the [email protected] Delete .
Participation of this paper “OSC Source creation plan ”, You are welcome to join us , share .