Overview
In essence, a native policy is a custom policy/rule implementation for a specific PDP engine such as: drools DRL rules, xacml XML policies or apex JSON policies.
Taking drools rules as one example, current usecases.drl used in PDP-D is a default DRL implementation for Control Loop operational policies. It is both a TOSCA Policy Type implementation and a native drools rule implementation since it is a set of rules that directly run in the PDP-D supporting the TOSCA onap.policies.Operational Policy Type. However, some policy authors might prefer to compose their own drools rules for certain features which are partially supported by the usecases.drl such as: changing the treatment of incoming event messages, adding custom timeout logic, or adding extra processing logic. Current policy framework does not provide an interface for such policy authors to bring in their own native rules. Hence, we need to come up with a solution in Frankfurt to bridge the gap.
Taking XACML as another example, some policy authors may want to add customized guard, coordination, etc. XACML policies in which using a TOSCA Policy Type abstraction does not make sense or simply isn't required.
1. Native Rule Development Guidelines
1.1 Drools Native Rules
1.1.1 DRL development
DRL development refers to the composition of drl file which contains one or more drools rules written in drools language. These drools rules work together to fulfill policy decision making logic required by new custom application.
Policy author should develop drl rules in IDE of choice, e.g. Eclipse/IntelliJ as well as necessary junit tests to ensure it can compile and make expected decisions.
After drl rule development, policy author should submit composed rules for git review then deploy the new jar containing new drl rules to the existing nexus repos that hold the released artifacts currently supported by the runtime PDP-D engines.
1.1.2 Dependency JAR development
Dependency JAR development refers to the development of supportive java classes that will be used in drl rules. These dependency java classes could be the java models for I/O events and functional elements like eNodeB which may include necessary attributes of that element and operational functions/methods provided by that element, e.g. reboot. It could also be any other java class which has methods for processing input events and producing policy reactions, e.g. eventManager, operationManager. The drl rules will import these classes and use them in either condition or action part.
Dependency JAR developer should use development best practices/governance to test/deploy new and/or updated java artifacts to the nexus repo for drools PDP-D. These new java development should go through git review process and include necessary junit tests to make sure they will behave correctly as expected.
1.2 XACML XML
XACML Policy Designers can use a text or XML editor of their choice to design and test their XACML Policies. The Github:att/XACML project has tools and a GUI available for creating policies and testing those policies.
1.3 APEX JSON
APEX policy development includes three parts - develop the state machine transition using APEX language (i.e. .apex file), develop I/O event schema to each state (i.e. .avro files) and develop processing logic in each state/task (i.e. javascript files). APEX policy developer should follow best practices to develop APEX policies and submit for git review once they are done. Then APEX command line tool can be used to generate the executable JSON for PDP-A.
TBC with Apex team
2. Policy Lifecycle API CRUD Enhancements
3. PAP Enhancements
PDP Engines must now register with PAP the new policy types for native policies they support in order for policies to be deployed by PAP to the PDP's. This will require an additional entry to be added into supported policy types list to indicate which native policy type each specific PDP engine can support.
3.1 Example of PDP Register
Only change needed is to add a new supported policy type to PDP status message when it registers itself with PAP. For XACML PDP, new policy type "onap.policies.controlloop.native.Xacml" should be added. Likewise, new policy type "onap.policies.controlloop.native.Drools" should be added when Drools PDP registers itself with PAP. For example
3.2 Example PDP Group Deploy
Like PDP registration message, the same native policy type should be added into supported policy types list to indicate which type of native policies each pdpSubGroup can support.
Below is one example to deploy a PDP group.
3.3 Deploy/Undeploy API
No change is envisioned on current deploy/undeploy API. Still, only policy-id and version are needed to tell PAP to deploy/undeploy a native policy.
4. PDP Changes
Each PDP will need to be able to support native policies being deploy/undeployed to it as done today.
4.1 Drools PDP
4.2 XACML PDP
XACML PDP will need to be able to ingest a XACML XML Policy directly. One suggestion is to create an application specifically for the XACML natives rules by default. The opportunity exists where a policy designer could create a specific application that supports native XACML policies (with or without TOSCA Policy Types as an option) and uses the grouping of PDPs to differentiate itself from the default XACML native rule application. The XACML PDP should also be enhanced to support configuring of applications in order to provide flexibility to the policy designers as to where all of its possible policy types are deployed.
With regards to the Decision API supported by XACML, that api can be enhanced to support XACML XML requests/responses directly.
Some scenarios are listed as below:
Scenario #1: Use pre-defined XACML policies only (i.e. Guard, Coordination, Optimization, Monitoring)
This scenario is already supported today through some pre-build XACML applications which support Guard, Coordination(W.I.P), Optimization and Monitoring. We provide TOSCA Policy Types for such types of XACML policies. XACML author can use lifecyle APIs to CRUD corresponding TOSCA policies which will then be deployed to XACML PDP. XACML PDP will be able to translate these TOSCA policies into low level native XACML XML policies and then enforce them.
Scenario #2: Use native XACML policies only
This scenario requires a new XACML application to be built which particularly handles native XACML policies only.
Scenario #3: Use pre-defined XACML policies and native XACML policies together
This scenario is the most complicated one. For new use case, XACML policy author might need to use both existing types of XACML policies, e.g. guard, together with newly composed native XACML XML policies, e.g. custom access control rules. Perhaps we need to build another new XACML application for this combination. More details need to be figured out, e.g. do we need a new TOSCA policy type for this combination? how to combine the low level XACML XML policies together? what is the combining algorithm we should use? etc. etc.
4.3 Apex PDP
Apex PDP will need to be able to ingest custom Apex JSON policies. TBC with that team - may already be well-supported.
5. Sequence flows for native policy design, deployment and enforcement
5.1 Drools native policies supported by the PDP-D engine
Create native DRL
Update native DRL
Deploy native DRL
Undeploy native DRL
Delele native DRL
5.2 XACML native policies supported by the PDP-X engine
5.2.1 Getting XACML native policies into the Policy Framework via the Policy Lifecycle API CRUD
5.2.2 Deploying/Undeploying XACML native policies using the Policy PAP API
5.2.3 Enforcement of XACML native policies done by the PDP-X engine using the Decision API