Overview
In essence, a native /raw policy is a custom policy type implementation which can be native policy rules (e.g. drools /rule implementation for a specific PDP engine such as: drools DRL rules, xacml rules XML policies or apex rules) with or without configurable property values. If a set of native policy rules does not contain any configurable property, it becomes policy implementation which is directly executable in PDP engines. If it contains one or more configurable properties (e.g. marked as ${xxx}), it becomes a rule template. Its corresponding policy type defines those configurable properties and their values can be provided by particular TOSCA policy created off this policy type. In this scenario, executable policy implementation will be generated by combining TOSCA policy and this corresponding policy type implementation. The relationship among policy type, policy type implementation, TOSCA policy and policy implementation can be illustrated as below:
Taking drools rules as one example, current usecases.drl used in PDP-D is a default policy type implementation for operational policy. It is both a policy type implementation and policy implementation since it is a set of rules without any configurable property values to be populated and it can be directly run in PDP-D. However, some policy authors might prefer to compose their own drools rules in a different way even if they aim to implement the same or different use cases. 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.
Regarding this solution, I have two design options in my mind which will be explained in the following. In both options, we want to use PAP to deploy such native policies to appropriate PDP engines. Given drools rules will import some java classes and use them in action part to perform particular operations as well as in condition part to indicate the java models for I/O message events, we want to separate java class implementation and rule authoring. Java classes being used in drl rules need to be implemented separately and packaged into JARs which are deployed to internal nexus repo before implementing/deploying native policies.
Option 1: Everything being provided through policy design API (i.e. drl rules, java dependencies, drools controller configuration)
In this design option, native policy author needs to provide all necessaries in the payload of POST custom policy type impl call. The payload will use application/json or application/yaml as content-type. All the necessaries include native policy rules with or without configurable properties (e.g. drl with ${xxx}), java dependency descriptors (i.e. groupId, artifactId, version) and other configuration required by corresponding PDP engine to load/execute these new rules (e.g. drools controller configuration which includes controller-name, dmaap server, dmaap topics, java classes for serialization/deserialization, filter, custom serializer, etc.).
Policy type, policy type implementation and policy are organized as hierarchical resources in RESTful path. Policy type implementation payload should include which policy type this implementation is associated with. Likewise, policy payload should include which policy type and which type implementation this policy is created off. If policy type implementation is not present in endpoint path, it means to use default type implementation for associated policy type. Basically, the RESTful resource hierarchy can be expressed as
/policytypes/{policyTypeName}/versions/{policyTypeVersion}/policytypeimpls/{policyTypeImplName}/versions/{policyTypeImplVersion}/policies/{policyName}/versions/{policyVersion}
Some endpoint paths are exemplified in the following table:
...
application/yaml
application/json
...
Create new custom policy type implementation(s) for an existing policy type version
Retrieve custom policy type implementation(s) for an existing policy type version
...
application/yaml
application/json
...
Retrieve a particular version of policy type implementation for an existing policy type version
Update a particular version of policy type implementation for an existing policy type version
Delete a particular version of policy type implementation for an existing policy type version
...
application/yaml
application/json
...
application/yaml
application/json
...
Create new polic(ies) off existing policy type and type implementation
Retrieve polic(ies) created off existing policy type and type implementation
...
application/yaml
application/json
...
Retrieve a particular version of policy created off existing policy type and type implementation
Update a particular version of policy created off existing policy type and type implementation
Delee a particular version of policy created off existing policy type and type implementation
...
application/yaml
application/json
...
application/yaml
application/json
...
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.
| Table of Contents |
|---|
1. Native Policy Development Guidelines
1.1 Drools Native Policies
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.1.3 Drools controller configuration
Deploying a native policy to Drools PDP eseentially means assigning the policy to a Drools controller that manages the DRL rules and corresponding facts loading in desirable working memory. To avoid unnecessary fact/rule conflict, it might need to have separated working memory dedicated to the native policy required by certain use case. Hence, for some native policies (here, we assume one native policy could include multiple DRL rules), we need to instantiate independent Drools controller for each of them. Drools controller needs to be configured in terms of a custom controller name, source/sink topics, event serialization, serialization filter, etc. (more details will be presented in Sec.2.1.1). All these configurations are use case specific and can be specified in the native policy if policy designers have desirable configurations in mind already. Regarding other installation level configurations like dmaap server, aaf credentials, etc., they would be left in helm charts, instead of in native policy as they are applied over all use cases.
It is worthwhile to note that specifying Drools controller configuration in native policy is optional, which means it can be present or not. If they are not present, current native policy will be assigned to a default Drools controller that is specified in the helm charts and instantiated in Drools PDP when the PDP is up. If policy designers are aware of which existing Drools controller can work for the new native policy, they can specify the existing controller name only without replicating other configuration details. Alternatively, policy designers can also change the Drools controller configurations at runtime by calling exposed telemetry API, e.g. change a source/sink topic, if the current/default Drools controller setup cannot fit the needs.
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.
The detailed documentation can be found here - https://onap.readthedocs.io/en/latest/submodules/policy/parent.git/docs/apex/apex.html
2. Policy Lifecycle API CRUD Enhancements
Native policies can be supported by TOSCA policy type and policy. As for native Drools policy, since native DRL is packaged in JAR which has been deployed to nexus repo along with other dependency JARs, TOSCA policy for native DRL only needs to include the pointer for native JAR as well as necessary information being used by Drools PDP to instantiate a new controller instance with native DRL loaded into memory. Corresponding policy type should be defined and pre-loaded into policy framework so that TOSCA policy for native policy type can then be created off. As for native XACML policy, its contents are basically encoded in XML which is all XACML PDP needs to load into engine and run. Thus, TOSCA policy for native XACML only needs to include this XML content. An URL-encoded string can be created off composed XACML XML and is populated to a string property.
2.1 Native Drools Policy Support
2.1.1 Policy Type for Native Drools Policy
Below is the policy type defined to support native Drools policies.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
onap.policies.Native:
derived_from: tosca.policies.Root
description: a base policy type for all native PDP policies
| ||||||||
| Code Block | ||||||||
| ||||||||
policy_type_impls: - onap.policies.controlloop.operational.sampleusecase1.Impl: version: 1.0.0 type: onap.policies.controlloop.operational.Sampleusecase1 type_version: 1.0.0 onap.policies.native.Drools: pdpderived_from: droolsonap.policies.Native description: Implementationa ofpolicy sampletype usefor case1native drools rulespolicies policy_bodyversion: "<policy body>" 1.0.0 properties: dependencies: rule_artifact: - groupId: org.onap.policy.sampledomain type: onap.datatypes.native.rule_artifact artifactId: policy-sample-usecase1 versionrequired: 1.0.0-SNAPSHOTtrue controller: description: specifies rule name: sample-usecase1 artifact pointer configdrools_body: "<config body>" controller: - onap.policies.controlloop.operational.sampleusecase2.Impl: version: 1.0.0 type: onap.policiesdatatypes.controlloop.operational.Sampleusecase2 native.drools_controller type_version: 1.0.0 pdprequired: droolsfalse description: Implementation of sample use case2 drools rules description: specifies information for drools controller policy_body: "<policy body>"instantiation data_types: onap.datatypes.native.rule_artifact: properties: derived_from: tosca.datatypes.Root dependenciesproperties: - groupId: org.onap.policy.sampledomain artifactId: policy-sample-usecase2 type: string version: 1.0.0-SNAPSHOT required: controller:true name: sample-usecase2 artifactId: config_body: "<config body>" | ||||||||
| Code Block | ||||||||
| ||||||||
tosca_definitions_version: tosca_simple_yaml_1_0_0 topology_template: policies: type: string - operational.sampleusecase1: typerequired: onap.policies.controlloop.operational.Sampleusecase1true type_ version: 1.0.0 type_impl: onap.policies.controlloop.operational.sampleusecase1.Implstring type_impl_version: 1.0.0 required: true onap.datatypes.native.drools_controller: versionderived_from: 1tosca.0datatypes.0 Root metadataproperties: policy-idcontrollerName: operational.sampleusecase1 properties: null - operational.sampleusecase2type: string type: onap.policies.controlloop.operational.Sampleusecase2 type_versionrequired: 1.0.0 true type_impl: onap.policies.controlloop.operational.sampleusecase2.Impl isNewController: type_impl_version: 1.0.0 type: boolean version required: 1.0.0 true metadata description: a flag to indicate if the controller is policy-id: operational.sampleusecase2 a new one to instantiate or not properties sourceTopics: ClosedLoopControlName: sample-usecase-1 | ||||||||
| Code Block | ||||||||
| title | Policytype | payloadtosca_definitions_version: tosca_simple_yaml_1_0_0 policy_types: onap.policies.controlloop.operational.Sampleusecase1: : list derived_from: onap.policies.controlloop.Operational descriptionrequired: afalse sample use case1 specific policy type version: 1.0.0 onap.policies.controlloop.operational.Sampleusecase2 entry_schema: derived_from: onap.policies.controlloop.Operational description: a sample use case2 specific policy type versiontype: 1onap.datatypes.0native.0dmaap_config properties sinkTopics: ClosedLoopControlName: type: string list required: truefalse description: the controlloop name for sample use case2 |
Note that the preceding policy type implementation list contains two elements. One is for sample use case1 rules whereas the other is for sample use case2 rules. Here, sample use case 1 and 2 are two example use cases which use drools rules for decision making. Let's assume sample use case1 rules do not have configurable properties while sample use case 2 rules contain configurable properties (e.g. ${ClosedLoopControlName}), which justifies that in the corresponding policies created off, we can see "properties: null" for use case 1 and "properties: ClosedLoopControlName: xxx" for use case 2 as shown above.
Policy type, type implementation and policy are all stored in policy DB. As a follow-up after POST policy type impl and policy API calls, native policy author needs to call PAP policy deployment API to deploy native policies to PDP engine (e.g. drools). PAP will pull the policy and corresponding type implementation from DB then send them to appropriate PDP engine. Taking drools as one example, after PDP-D receives native policy and its type implementation from PAP, it will first pull necessary dependency artifact JARs from internal nexus based on what specified in "properties.dependencies" then copy them to local m2 repo. Next, PDP-D will package native rules into a new JAR and copy to local m2 as well. At last, PDP-D will instantiate a new drools controller instance based on what provided in "properties.controller" then invoke telemetry API to spin up the new drools controller.
Sequence diagram
Option 2: Native policy rules being provided through policy design API whereas peripheral configuration (i.e. java dependencies, drools controller configuration) being provided through PAP policy deployment API
In this design option, only native policy rules are being provided in POST policy type implementation payload via custom content-type (e.g. application/drl, application/xacml, application/apex). Other dependencies and configuration are being provided in PAP policy deployment API call. The basic idea of this design option is, in policy design phrase, native policy author just needs to focus on composing native policy rules to realize predefined decision making logic, without worrying about how to setup/configure peripheral stuffs like dmaap server/topics and new drools controller instance. After finishing up policy rule handcrafting and later in policy deployment phrase, policy author can start considering about how to setup/configure other things to make sure native rules can be running correctly in appropriate PDP engine. It implies that when PAP policy deployment API is invoked, necessary configurations required by PDP engine to correctly execute native rules need to be provided in the payload of this policy deployment POST call. Along with native policy and its type implementation, they will all be sent to PDP engine for execution.
Endpoint paths will remain the same in this option except that content-type will be customized to PDP engine specific one.
...
application/drl
application/xacml
application/apex
...
Create new custom policy type implementation(s) for an existing policy type version
Retrieve custom policy type implementation(s) for an existing policy type version
...
application/drl
application/xacml
application/apex
...
Retrieve a particular version of policy type implementation for an existing policy type version
Update a particular version of policy type implementation for an existing policy type version
Delete a particular version of policy type implementation for an existing policy type version
...
application/drl
application/xacml
application/apex
...
application/yaml
application/json
...
Create new polic(ies) off existing policy type and type implementation
Retrieve polic(ies) created off existing policy type and type implementation
...
application/yaml
application/json
...
Retrieve a particular version of policy created off existing policy type and type implementation
Update a particular version of policy created off existing policy type and type implementation
Delee a particular version of policy created off existing policy type and type implementation
...
application/yaml
application/json
...
application/yaml
application/json
...
entry_schema:
type: onap.datatypes.native.dmaap_config
onap.datatypes.native.dmaap_config:
derived_from: tosca.datatypes.Root
properties:
topicName:
type: string
required: true
serialization:
type: list
required: true
entry_schema:
type: onap.datatypes.native.dmaap.serialization
onap.datatypes.native.dmaap.serialization:
derived_from: tosca.datatypes.Root
properties:
eventCanonicalName:
type: string
required: true
eventFilter:
type: string
required: false
customSerializer:
type: string
required: false |
2.1.2 TOSCA Policy for Native Drools Rules
Below is an example of TOSCA policy for native Drools rules
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
policies:
-
Example_policy_name:
type: onap.policies.native.Drools
version: 1.0.0
metadata:
policy-id: Example_policy_name
properties:
rule_artifact:
groupId: org.onap.policy.native
artifactId: example_controlloop
version: 1.0.0-SNAPSHOT
drools_controller:
controllerName: example_controller_name
isNewController: true
sourceTopics:
-
topicName: POLICY_INPUT
serialization:
-
eventCanonicalName: org.onap.policy.controlloop.event.ControlLoopEvent
eventFilter: [?($.closedLoopControlName == 'example_controlloop_name')]
customSerializer: org.onap.policy.controlloop.utils.serializer,gson
-
topicName: SDNR_TO_POLICY
serialization:
-
eventCanonicalName: org.onap.policy.controlloop.event.Response
eventFilter: [?($.closedLoopControlName == 'example_controlloop_name' && $.action == 'example_action')]
customSerializer: org.onap.policy.controlloop.utils.serializer,gson
sinkTopics:
-
topicName: POLICY_TO_SDNR
serialization:
-
eventCanonicalName: org.onap.policy.controlloop.event.Request
eventFilter: [?($.closedLoopControlName == 'example_controlloop_name' && $.action == 'example_action')]
customSerializer: org.onap.policy.controlloop.utils.serializer,gson |
2.2 Native XACML Policy Support
2.2.1 Policy Type for Native XACML Policies
Below is the policy type defined to support native XACML policies.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
onap.policies.Native:
derived_from: tosca.policies.Root
description: a base policy type for all native PDP policies
version: 1.0.0
onap.policies.native.Xacml:
derived_from: onap.policies.Native
description: a policy type for native xacml policies
version: 1.0.0
properties:
policy:
type: String
required: true
description: The XML XACML 3.0 PolicySet or Policy
metadata:
encoding: URL |
2.2.2 TOSCA Policy for Native XACML Rules
Below is an example of TOSCA policy for native XACML rules
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
policies:
-
usecase_foo_xacml_policy:
policy: "%3CPolicy+xmlns%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Acore%3Aschema%3Awd-17%22+PolicyId%3D%22Test.policy%22+Version%3D%221%22+RuleCombiningAlgId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Arule-combining-algorithm%3Afirst-applicable%22%3E%0D%0A++++%3CTarget%2F%3E%0D%0A++++%3CRule+RuleId%3D%22Test.policy%3Arule%22+Effect%3D%22Permit%22%3E%0D%0A++++++++%3CDescription%3EDefault+is+to+PERMIT+if+the+policy+matches.%3C%2FDescription%3E%0D%0A++++++++%3CTarget%3E%0D%0A++++++++++++%3CAnyOf%3E%0D%0A++++++++++++++++%3CAllOf%3E%0D%0A++++++++++++++++++++%3CMatch+MatchId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Astring-equal%22%3E%0D%0A++++++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22%3EI+should+be+matched%3C%2FAttributeValue%3E%0D%0A++++++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Amatchable%3AmatchableString%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++++++%3C%2FMatch%3E%0D%0A++++++++++++++++%3C%2FAllOf%3E%0D%0A++++++++++++%3C%2FAnyOf%3E%0D%0A++++++++++++%3CAnyOf%3E%0D%0A++++++++++++++++%3CAllOf%3E%0D%0A++++++++++++++++++++%3CMatch+MatchId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Ainteger-equal%22%3E%0D%0A++++++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer%22%3E1000%3C%2FAttributeValue%3E%0D%0A++++++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Amatchable%3AmatachableInteger%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++++++%3C%2FMatch%3E%0D%0A++++++++++++++++%3C%2FAllOf%3E%0D%0A++++++++++++%3C%2FAnyOf%3E%0D%0A++++++++++++%3CAnyOf%3E%0D%0A++++++++++++++++%3CAllOf%3E%0D%0A++++++++++++++++++++%3CMatch+MatchId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Adouble-equal%22%3E%0D%0A++++++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23double%22%3E1.1%3C%2FAttributeValue%3E%0D%0A++++++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Amatchable%3AmatchableDouble%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23double%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++++++%3C%2FMatch%3E%0D%0A++++++++++++++++%3C%2FAllOf%3E%0D%0A++++++++++++%3C%2FAnyOf%3E%0D%0A++++++++++++%3CAnyOf%3E%0D%0A++++++++++++++++%3CAllOf%3E%0D%0A++++++++++++++++++++%3CMatch+MatchId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Aboolean-equal%22%3E%0D%0A++++++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23boolean%22%3Etrue%3C%2FAttributeValue%3E%0D%0A++++++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Amatchable%3AmatachableBoolean%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23boolean%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++++++%3C%2FMatch%3E%0D%0A++++++++++++++++%3C%2FAllOf%3E%0D%0A++++++++++++%3C%2FAnyOf%3E%0D%0A++++++++++++%3CAnyOf%3E%0D%0A++++++++++++++++%3CAllOf%3E%0D%0A++++++++++++++++++++%3CMatch+MatchId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Astring-equal%22%3E%0D%0A++++++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22%3Ematch+A%3C%2FAttributeValue%3E%0D%0A++++++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Amatchable%3AmatchableListString%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++++++%3C%2FMatch%3E%0D%0A++++++++++++++++%3C%2FAllOf%3E%0D%0A++++++++++++++++%3CAllOf%3E%0D%0A++++++++++++++++++++%3CMatch+MatchId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Astring-equal%22%3E%0D%0A++++++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22%3Ematch+B%3C%2FAttributeValue%3E%0D%0A++++++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Amatchable%3AmatchableListString%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++++++%3C%2FMatch%3E%0D%0A++++++++++++++++%3C%2FAllOf%3E%0D%0A++++++++++++%3C%2FAnyOf%3E%0D%0A++++++++%3C%2FTarget%3E%0D%0A++++++++%3CCondition%3E%0D%0A++++++++++++%3CApply+FunctionId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Aor%22%3E%0D%0A++++++++++++++++%3CDescription%3EIF+exists+and+is+equal%3C%2FDescription%3E%0D%0A++++++++++++++++%3CApply+FunctionId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Ainteger-equal%22%3E%0D%0A++++++++++++++++++++%3CDescription%3EDoes+the+policy-type+attribute+exist%3F%3C%2FDescription%3E%0D%0A++++++++++++++++++++%3CApply+FunctionId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Astring-bag-size%22%3E%0D%0A++++++++++++++++++++++++%3CDescription%3EGet+the+size+of+policy-type+attributes%3C%2FDescription%3E%0D%0A++++++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Apolicy-type%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++++++%3C%2FApply%3E%0D%0A++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23integer%22%3E0%3C%2FAttributeValue%3E%0D%0A++++++++++++++++%3C%2FApply%3E%0D%0A++++++++++++++++%3CApply+FunctionId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Astring-is-in%22%3E%0D%0A++++++++++++++++++++%3CDescription%3EIs+this+policy-type+in+the+list%3F%3C%2FDescription%3E%0D%0A++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22%3Eonap.policies.Test%3C%2FAttributeValue%3E%0D%0A++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Apolicy-type%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++%3C%2FApply%3E%0D%0A++++++++++++%3C%2FApply%3E%0D%0A++++++++%3C%2FCondition%3E%0D%0A++++%3C%2FRule%3E%0D%0A++++%3CRule+RuleId%3D%22Test.policy%3Arule%3Apolicy-type%22+Effect%3D%22Permit%22%3E%0D%0A++++++++%3CDescription%3EMatch+on+policy-type+onap.policies.Test%3C%2FDescription%3E%0D%0A++++++++%3CTarget%3E%0D%0A++++++++++++%3CAnyOf%3E%0D%0A++++++++++++++++%3CAllOf%3E%0D%0A++++++++++++++++++++%3CMatch+MatchId%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A1.0%3Afunction%3Astring-equal%22%3E%0D%0A++++++++++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22%3Eonap.policies.Test%3C%2FAttributeValue%3E%0D%0A++++++++++++++++++++++++%3CAttributeDesignator+Category%3D%22urn%3Aoasis%3Anames%3Atc%3Axacml%3A3.0%3Aattribute-category%3Aresource%22+AttributeId%3D%22urn%3Aorg%3Aonap%3Apolicy-type%22+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22+MustBePresent%3D%22false%22%2F%3E%0D%0A++++++++++++++++++++%3C%2FMatch%3E%0D%0A++++++++++++++++%3C%2FAllOf%3E%0D%0A++++++++++++%3C%2FAnyOf%3E%0D%0A++++++++%3C%2FTarget%3E%0D%0A++++%3C%2FRule%3E%0D%0A++++%3CObligationExpressions%3E%0D%0A++++++++%3CObligationExpression+ObligationId%3D%22urn%3Aorg%3Aonap%3Arest%3Abody%22+FulfillOn%3D%22Permit%22%3E%0D%0A++++++++++++%3CAttributeAssignmentExpression+AttributeId%3D%22urn%3Aorg%3Aonap%3A%3Aobligation%3Amonitoring%3Acontents%22%3E%0D%0A++++++++++++++++%3CAttributeValue+DataType%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23string%22%3E%7B%22type%22%3A%22onap.policies.Test%22%2C%22type_version%22%3A%221.0.0%22%2C%22properties%22%3A%7B%22nonmatachableString%22%3A%22I+am+NON+matchable%22%2C%22matchableString%22%3A%22I+should+be+matched%22%2C%22nonmatachableInteger%22%3A0%2C%22matachableInteger%22%3A1000%2C%22nonmatachableDouble%22%3A0%2C%22matchableDouble%22%3A1.1%2C%22nonmatachableBoolean%22%3Afalse%2C%22matachableBoolean%22%3Atrue%2C%22matchableListString%22%3A%5B%22match+A%22%2C%22match+B%22%5D%7D%2C%22name%22%3A%22Test.policy%22%2C%22version%22%3A%221.0.0%22%2C%22metadata%22%3A%7B%22policy-id%22%3A%22Test.policy%22%2C%22policy-version%22%3A%221%22%7D%7D%3C%2FAttributeValue%3E%0D%0A++++++++++++%3C%2FAttributeAssignmentExpression%3E%0D%0A++++++++%3C%2FObligationExpression%3E%0D%0A++++%3C%2FObligationExpressions%3E%0D%0A%3C%2FPolicy%3E%0D%0A" |
The native XACML rules for above TOSCA policy is:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
<Policy
xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="Test.policy" Version="1" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">
<Target/>
<Rule RuleId="Test.policy:rule" Effect="Permit">
<Description>Default is to PERMIT if the policy matches.</Description>
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">I should be matched</AttributeValue>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:matchable:matchableString" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">1000</AttributeValue>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:matchable:matachableInteger" DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="false"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:double-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#double">1.1</AttributeValue>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:matchable:matchableDouble" DataType="http://www.w3.org/2001/XMLSchema#double" MustBePresent="false"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:boolean-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#boolean">true</AttributeValue>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:matchable:matachableBoolean" DataType="http://www.w3.org/2001/XMLSchema#boolean" MustBePresent="false"/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">match A</AttributeValue>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:matchable:matchableListString" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
</Match>
</AllOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">match B</AttributeValue>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:matchable:matchableListString" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
</Match>
</AllOf>
</AnyOf>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:or">
<Description>IF exists and is equal</Description>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-equal">
<Description>Does the policy-type attribute exist?</Description>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag-size">
<Description>Get the size of policy-type attributes</Description>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:policy-type" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
</Apply>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">0</AttributeValue>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
<Description>Is this policy-type in the list?</Description>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">onap.policies.Test</AttributeValue>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:policy-type" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule RuleId="Test.policy:rule:policy-type" Effect="Permit">
<Description>Match on policy-type onap.policies.Test</Description>
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">onap.policies.Test</AttributeValue>
<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:org:onap:policy-type" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<ObligationExpressions>
<ObligationExpression ObligationId="urn:org:onap:rest:body" FulfillOn="Permit">
<AttributeAssignmentExpression AttributeId="urn:org:onap::obligation:monitoring:contents">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">{"type":"onap.policies.Test","type_version":"1.0.0","properties":{"nonmatachableString":"I am NON matchable","matchableString":"I should be matched","nonmatachableInteger":0,"matachableInteger":1000,"nonmatachableDouble":0,"matchableDouble":1.1,"nonmatachableBoolean":false,"matachableBoolean":true,"matchableListString":["match A","match B"]},"name":"Test.policy","version":"1.0.0","metadata":{"policy-id":"Test.policy","policy-version":"1"}}</AttributeValue>
</AttributeAssignmentExpression>
</ObligationExpression>
</ObligationExpressions>
</Policy> |
Note that DELETE call should remove TOSCA policy from DB as well as corresponding JAR from nexus
Pamela DragoshJorge Hernandez Question: checking existence of pointed JAR in nexus should happen in API each time new policy is created/updated, or in PAP when this policy gets deployed, or in PDP only???
Question: do we need to return native policy contents, i.e. DRL or XACML XML when GET call is invoked? If not, what if end user wants to view native policy rules???
2.3 Native Apex Policy Support
2.3.1 Policy Type for Native Apex Policy
Below is the policy type defined to support native apex policies.
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
tosca_definitions_version: tosca_simple_yaml_1_0_0,
policy_types:
onap.policies.Native:
derived_from: tosca.policies.Root
description: a base policy type for all native PDP policies
version: 1.0.0
onap.policies.native.Apex:
derived_from: onap.policies.Native
description: a policy type for native apex policies
version: 1.0.0
properties:
engine_service:
type: onap.datatypes.native.apex.EngineService
description: APEX Engine Service Parameters
inputs:
type: map
description: Inputs for handling events coming into the APEX engine
entry_schema:
type: onap.datatypes.native.apex.EventHandler
outputs:
type: map
description: Outputs for handling events going out of the APEX engine
entry_schema:
type: onap.datatypes.native.apex.EventHandler
environment:
type: list
description: Envioronmental parameters for the APEX engine
entry_schema:
type: onap.datatypes.native.apex.Environment
data_types:
onap.datatypes.native.apex.EngineService:
derived_from: tosca.datatypes.Root
properties:
name:
type: string
description: Specifies the engine name
required: false
default: "ApexEngineService"
version:
type: string
description: Specifies the engine version in double dotted format
required: false
default: "1.0.0"
id:
type: int
description: Specifies the engine id
required: true
instance_count:
type: int
description: Specifies the number of engine threads that should be run
required: true
deployment_port:
type: int
description: Specifies the port to connect to for engine administration
required: false
default: 1
policy_model_file_name:
type: string
description: The name of the file from which to read the APEX policy model
required: false
default: ""
policy_type_impl:
type: string
description: The policy type implementation from which to read the APEX policy model
required: false
default: ""
periodic_event_period:
type: string
description: The time interval in milliseconds for the periodic scanning event, 0 means don't scan
required: false
default: 0
engine:
type: onap.datatypes.native.apex.engineservice.Engine
description: The parameters for all engines in the APEX engine service
required: true
onap.datatypes.native.apex.EventHandler:
derived_from: tosca.datatypes.Root
properties:
name:
type: string
description: Specifies the event handler name, if not specified this is set to the key name
required: false
carrier_technology:
type: onap.datatypes.native.apex.CarrierTechnology
description: Specifies the carrier technology of the event handler (such as REST/Web Socket/Kafka)
required: true
event_protocol:
type: onap.datatypes.native.apex.EventProtocol
description: Specifies the event protocol of events for the event handler (such as Yaml/JSON/XML/POJO)
required: true
event_name:
type: string
description: Specifies the event name for events on this event handler, if not specified, the event name is read from or written to the event being received or sent
required: false
event_name_filter:
type: string
description: Specifies a filter as a regular expression, events that do not match the filter are dropped, the default is to let all events through
required: false
synchronous_mode:
type: bool
description: Specifies the event handler is syncronous (receive event and send response)
required: false
default: false
synchronous_peer:
type: string
description: The peer event handler (output for input or input for output) of this event handler in synchronous mode, this parameter is mandatory if the event handler is in synchronous mode
required: false
default: ""
synchronous_timeout:
type: int
description: The timeout in milliseconds for responses to be issued by APEX torequests, this parameter is mandatory if the event handler is in synchronous mode
required: false
default: ""
requestor_mode:
type: bool
description: Specifies the event handler is in requestor mode (send event and wait for response mode)
required: false
default: false
requestor_peer:
type: string
description: The peer event handler (output for input or input for output) of this event handler in requestor mode, this parameter is mandatory if the event handler is in requestor mode
required: false
default: ""
requestor_timeout:
type: int
description: The timeout in milliseconds for wait for responses to requests, this parameter is mandatory if the event handler is in requestor mode
required: false
default: ""
onap.datatypes.native.apex.CarrierTechnology:
derived_from: tosca.datatypes.Root
properties:
label:
type: string
description: The label (name) of the carrier technology (such as REST, Kafka, WebSocket)
required: true
plugin_parameter_class_name:
type: string
description: The class name of the class that overrides default handling of event input or output for this carrier technology, defaults to the supplied input or output class
required: false
onap.datatypes.native.apex.EventProtocol:
derived_from: tosca.datatypes.Root
properties:
label:
type: string
description: The label (name) of the event protocol (such as Yaml, JSON, XML, or POJO)
required: true
event_protocol_plugin_class:
type: string
description: The class name of the class that overrides default handling of the event protocol for this carrier technology, defaults to the supplied event protocol class
required: false
onap.datatypes.native.apex.Environmental:
derived_from: tosca.datatypes.Root
properties:
name:
type: string
description: The name of the environment variable
required: true
value:
type: string
description: The value of the environment variable
required: true
onap.datatypes.native.apex.engineservice.Engine:
derived_from: tosca.datatypes.Root
properties:
context:
type: onap.datatypes.native.apex.engineservice.engine.Context
description: The properties for handling context in APEX engines, defaults to using Java maps for context
required: false
executors:
type: map
description: The plugins for policy executors used in engines such as javascript, MVEL, Jython
required: true
entry_schema:
description: The plugin class path for this policy executor
type: string
onap.datatypes.native.apex.engineservice.engine.Context:
derived_from: tosca.datatypes.Root
properties:
distributor:
type: onap.datatypes.native.apex.Plugin
description: The plugin to be used for distributing context between APEX PDPs at runtime
required: false
schemas:
type: map
description: The plugins for context schemas available in APEX PDPs such as Java and Avro
required: false
entry_schema:
type: onap.datatypes.native.apex.Plugin
locking:
type: onap.datatypes.native.apex.plugin
description: The plugin to be used for locking context in and between APEX PDPs at runtime
required: false
persistence:
type: onap.datatypes.native.apex.Plugin
description: The plugin to be used for persisting context for APEX PDPs at runtime
required: false
onap.datatypes.native.apex.Plugin:
derived_from: tosca.datatypes.Root
properties:
name:
type: string
description: The name of the executor such as Javascript, Jython or MVEL
required: true
plugin_class_name:
type: string
description: The class path of the plugin class for this executor |
NOTE: The native policy type is already loaded in policy framework during installation, hence a user can directly deploy native policies in respective pdp engines without a need to create policy type first.
3. PAP Enhancements
PDP Groups must be provisioned to support the new policy types for native policies 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 Subgroup can support.
3.1 PDP Group & SubGroup
The native policy type should be added into supported policy types list to indicate which type of native policies each PDP SubGroup can support.
Below is one example of PDP Group with native policies support for xacml, drools & apex engines.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
{
"groups": [
{
"name": "defaultGroup",
"description": "The default group that registers all supported policy types and pdps.",
"pdpGroupState": "ACTIVE",
"properties": {},
"pdpSubgroups": [
{
"pdpType": "apex",
"supportedPolicyTypes": [
{
"name": "onap.policies.controlloop.operational.Apex",
"version": "1.0.0"
},
{
"name": "onap.policies.native.Apex",
"version": "1.0.0"
}
],
"policies": [],
"currentInstanceCount": 0,
"desiredInstanceCount": 1,
"properties": {},
"pdpInstances": [
{
"instanceId": "apex_35",
"pdpState": "ACTIVE",
"healthy": "HEALTHY",
"message": "Pdp Heartbeat"
}
]
},
{
"pdpType": "drools",
"supportedPolicyTypes": [
{
"name": "onap.policies.controlloop.Operational",
"version": "1.0.0"
},
{
"name": "onap.policies.native.Drools",
"version": "1.0.0"
}
],
"policies": [],
"currentInstanceCount": 0,
"desiredInstanceCount": 1,
"properties": {},
"pdpInstances": [
{
"instanceId": "dev-policy-drools-0",
"pdpState": "ACTIVE",
"healthy": "HEALTHY"
}
]
},
{
"pdpType": "xacml",
"supportedPolicyTypes": [
{
"name": "onap.policies.controlloop.guard.FrequencyLimiter",
"version": "1.0.0"
},
{
"name": "onap.policies.controlloop.guard.MinMax",
"version": "1.0.0"
},
{
"name": "onap.policies.controlloop.guard.Blacklist",
"version": "1.0.0"
},
{
"name": "onap.policies.controlloop.guard.coordination.FirstBlocksSecond",
"version": "1.0.0"
},
{
"name": "onap.Monitoring",
"version": "1.0.0"
},
{
"name": "onap.policies.monitoring.cdap.tca.hi.lo.app",
"version": "1.0.0"
},
{
"name": "onap.policies.monitoring.dcaegen2.collectors.datafile.datafile-app-server",
"version": "1.0.0"
},
{
"name": "onap.policies.monitoring.docker.sonhandler.app",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.AffinityPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.DistancePolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.HpaPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.OptimizationPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.PciPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.QueryPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.SubscriberPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.Vim_fit",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.VnfPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.native.Xacml",
"version": "1.0.0"
}
],
"policies": [],
"currentInstanceCount": 1,
"desiredInstanceCount": 1,
"properties": {},
"pdpInstances": [
{
"instanceId": "dev-policy-policy-xacml-pdp-558c478477-g85jl",
"pdpState": "ACTIVE",
"healthy": "HEALTHY"
}
]
}
]
}
]
} |
3.2 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
On one hand, Drools PDP will need to parse the information encoded in the TOSCA policy deployed from PAP in terms of native DRL JAR GAV (GroupId, ArtifactId, Version) information and Drools controller configuration if present. It will then go to the nexus to pull the native DRL JAR and corresonding dependencies. If the Drools controller configuration is present, Drools PDP needs to know first if it is a new controller to instantiate or reusing an existing one by parsing the "isNewController" flag. If reusing an existing one, what Drools PDP needs to do is just assign the native DRL JAR and dependencies to that controller. Otherwise, a new Drools controller instance should be instantiated using the configurations included in the TOSCA properties. The new Drools controller should be able to load the native DRL and corresponding facts into work memory for rule execution.
On the other hand, when Drools PDP receives a request to undeploy a native policy, it should be able to disable corresponding Drools controller and clean up the related facts from the memory.
Another thread of extension needed is to expose the telemetry API used to manage the lifecycle of Drools controller, which is to facilitate those policy designers who want to change controller setup at runtime. Current telemetry API can only be called from within policy container. One example is shown below:
| Code Block |
|---|
curl -k --silent --user ${TELEMETRY_USER}:${TELEMETRY_PASSWORD} -X POST --data @${json} --header "Content-Type: application/json" \
https://localhost:${TELEMETRY_PORT}/policy/pdp/engine/controllers |
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 already supports the native policies created using the policy type defined in section 2.3.1 above.
5. Sequence flows for native policy design, deployment and enforcement
5.1 Drools native policies supported by the PDP-D engine
5.1.1 Create native DRL
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
@startuml
autonumber
actor Drools_Policy_Designer as User
participant API
database Policy_DB as DB
participant Nexus
User -> Nexus: develop and deploy dependency JAR to nexus
User -> Nexus: develop and deploy DRL JAR to nexus
User -> API: POST - create TOSCA policy
API -> Nexus: validate JAR existence and Drools controller config
alt non-existence or invalid config
API -> User: JAR non-existence or invalid controller config
else everything is good
API -> DB: store policy in DB
DB -> API: success
API -> User: 200 Success
end
@enduml |
5.1.2 Deploy native DRL
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
@startuml
autonumber
actor Drools_Policy_Designer as User
database Policy_DB as DB
participant API
participant PAP
participant DroolsPDP as PDP
participant Nexus
User -> PAP: POST - deploy policy
PAP -> API: GET the policy
API -> DB: read from DB
DB -> API: success
API -> PAP: return the policy
PAP -> PDP: public dmaap - deploy policy
PDP -> Nexus: pull the JAR
Nexus -> PDP: success
PDP -> PDP: instantiate a new drools controller
PDP -> PDP: load DRL and facts into memory
PDP -> PAP: publish dmaap - policy deployed
PAP -> User: 200 success
PAP -> PAP: publish policy update notification
@enduml |
5.1.3 Undeploy native DRL
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
@startuml
autonumber
actor Drools_Policy_Designer as User
participant PAP
participant DroolsPDP as PDP
User -> PAP: DELETE - undeploy policy
PAP -> PDP: publish dmaap - undeploy policy
PDP -> PDP: DELETE - disable the controller
PDP -> PAP: publish dmaap - policy undeployed
PAP -> User: 200 success
PAP -> PAP: publish policy update notification
@enduml |
5.1.4 Delele native DRL
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
@startuml
autonumber
actor Drools_Policy_Designer as User
participant API
database Policy_DB as DB
participant Nexus
User -> API: DELETE - delete policy
API -> DB: remove policy from DB
DB -> API: success
API -> Nexus: remove JAR from nexus
Nexus -> API: success
API -> User: 200 success
@enduml |
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
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
5.2.2 Deploying/Undeploying XACML native policies using the Policy PAP API
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
5.2.3 Enforcement of XACML native policies done by the PDP-X engine using the Decision API
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Policy payload will remain the same as that in option 1.
Flow explanation
TBA
Sequence diagram
TBA