...
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. 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.TODO
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.
...