...
curl -k --user "demo@people.osaaf.org:demo123456!" -X POST --data @example-controller.rest.json --header "Content-Type: application/json" https://localhost{ip or hostname}:9696/policy/pdp/engine/controllers
...
In addition, when drools PDP receives native policy deployed from PAP, given the deployment contains groupId, artifactId and version, drools PDP will need to pull the java artifact that contains drl rules as well as corresponding dependency artifacts then place them in local m2 repo. When a new controller shown above is created, it will scan local m2, search for the artifact with specified "rules.groupId", "rules.artifactId" and "rules.version" and load its contained drl rules into drools memory.
On the other hand, if drools PDP receives a request from PAP to undeploy a native policy, it will need to disable/delete the corresponding controller and remove the corresponding artifact from local m2 repo. Deleting a controller can be realized by calling exposed telemetry API. For example:
curl -k --user "demo@people.osaaf.org:demo123456!" -X DELETE https://{ip or hostname}:9696/policy/pdp/engine/controllers/example-controller
4.2 XACML PDP
XACML PDP will need to be able to ingest a XACML XML 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 and content types are deployed.
...
5. Sequence flows for native policy design and deployment
5.1 Drools
To be added by Chenfei