Policy XACML PDP Engine

The ONAP XACML Policy PDP Engine uses an open source implementation of the OASIS XACML 3.0 Standard to support fine-grained policy decisions in the ONAP. The XACML 3.0 Standard is a language for both policies and request/response for access control decisions. The ONAP XACML PDP translates TOSCA Compliant Policies into the XACML policy language, loads the policies into the XACML engine and exposes a Decision API which uses the XACML request/response language to render decisions.

ONAP Supported Policy Types

In ONAP the following Policy Types are supported. Each Policy Type is implemented as an application that extends the XacmlApplicationServiceProvider. For details on each implementation, please refer to the applications submodule of the onap/xacml-pdp project.

By cloning the policy/xacml-pdp repository, one can run the JUnit tests to get a better understanding on how applications are built using translators and the XACML Policies that are generated for each Policy Type. Each application supports one or more Policy Types and an associated “action” used by the Decision API when making these calls.

Monitoring Policy Types

These Policy Types are used by Control Loop DCAE microservice components to support monitoring of VNF’s during Control Loops. The DCAE Platform makes a call to Decision API to request the contents of these policies. The implementation involves creating an overarching XACML Policy that contains the TOSCA policy as a payload that is returned to the DCAE Platform.

Policy Type Action Description
onap.policies.monitoring.cdap.tca.hi.lo.app configure TCA DCAE microservice component
onap.policies.monitoring.dcaegen2.collectors.datafile.datafile-app-server configure REST Collector

The translator used to translate these TOSCA Policy Types is the StdCombinedPolicyResultsTranslator.

This is an example Decision API payload made to retrieve a decision for a Monitoring Policy Type.

{
  "ONAPName": "DCAE",
  "ONAPComponent": "PolicyHandler",
  "ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64",
  "action": "configure",
  "resource": {
      "policy-id": "onap.scaleout.tca"
  }
}

Guard Policy Types

These Policy Types are used by Control Loop Drools Engine to support guarding of Control Loops during runtime control loop execution. NOTE: For Dublin, these policy types are not TOSCA compliant but rather a simple variation of the Casablanca legacy guard policy.

Policy Type Action Description
onap.policies.controlloop.guard.FrequencyLimiter guard Limits frequency of actions over a specified time period
onap.policies.controlloop.guard.Blacklist guard Blacklists a regexp of VNF IDs
onap.policies.controlloop.guard.MinMax guard For scaling, enforces a min/max number of VNFS

The translator used to translate these legacy Policy Types is the LegacyGuardTranslator which implements a more fine grained approach to translating the properties into a XACML policy.

This is an example Decision API payload made to retrieve a decision for a Guard Policy Type.

{
  "ONAPName": "Policy",
  "ONAPComponent": "drools-pdp",
  "ONAPInstance": "usecase-template",
  "requestId": "unique-request-id-1",
  "action": "guard",
  "resource": {
      "guard": {
          "actor": "SO",
          "recipe": "VF Module Create",
          "clname": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3",
          "target": "vLoadBalancer-00",
          "vfCount": "1"
      }
  }
}

Control Loop Coordination Policy Types

These Policy Types are similar to the guard Policy Types and are called by the Control Loop Drools PDP Engine to support guarding of Control Loops during runtime control loop execution. NOTE: For Dublin, these Policy Types are not tested by the Integration team and are available as prototypes.

Policy Type Action Description
onap.policies.controlloop.guard.coordination.FirstBlocksSecond guard Gives priority to one control loop vs another

The translator used to translate the coordination Policy Types is the CoordinationGuardTranslator which uses a XACML Policy Template in its implementation. For example, when a new policy is loaded the translator copies the template to a new policy and replaces the CONTROL_LOOP_ONE and CONTROL_LOOP_TWO values with the specified control loops. See the XAMCL Coordination Template for more details.

The same Decision API payload example for guard applies to this Policy Type.

Optimization Policy Types

These Policy Types are used by the OOF Project support placement in ONAP. The OOF Platform makes a call to the Decision API to request these Policies based on the values specified in the policyScope and policyType properties. Please refer to the OOF Project for more details on how these Policy Types are using in their platform.

Policy Type Action
onap.policies.optimization.AffinityPolicy optimize
onap.policies.optimization.DistancePolicy optimize
onap.policies.optimization.HpaPolicy optimize
onap.policies.optimization.OptimizationPolicy optimize
onap.policies.optimization.PciPolicy optimize
onap.policies.optimization.QueryPolicy optimize
onap.policies.optimization.SubscriberPolicy optimize
onap.policies.optimization.Vim_fit optimize
onap.policies.optimization.VnfPolicy optimize

The translator used to translate the optimization Policy Types is the StdMatchableTranslator.

This is an example Decision API payload made to retrieve a decision for an Optimization Policy Type.

{
  "ONAPName": "OOF",
  "ONAPComponent": "OOF-component",
  "ONAPInstance": "OOF-component-instance",
  "action": "optimize",
  "resource": {
      "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra", "vG"],
      "policyType": "zone"
  }
}

Supporting Custom Policy Types

In order to support your own custom Policy Type that the XACML PDP Engine can support, one needs to build a Java service application that extends the XacmlApplicationServiceProvider interface and implement a ToscaTranslator application. Your application should register itself as a Java service application and expose it in the classpath used to be loaded into the ONAP XACML PDP Engine. Ensure you define and create the TOSCA Policy Type according to these Policy Design and Development. You should be able to load your custom Policy Type using the Policy Lifecycle API. Once successful, you should be able to start creating policies from your custom Policy Type.

See each of the ONAP Policy Type application implementations for for ONAP re-use the StdXacmlApplicationServiceProvider class. They give simple examples on how to use various implementations of ToscaTranslator applications.

The following tutorial can be helpful to get started: Policy XACML - Custom Application Tutorial

Once your application is developed and the ONAP XACML PDP Engine can find your application via setting the classpath appropriately, then use the PAP REST API to ensure the ONAP XACML PDP is registering your custom Policy Type with the PAP. Once successful, then you should be able to start deploying the created policies to the XACML PDP Engine.

Decision API

The Decision API is used by ONAP components that enforce policies and need a decision on which policy to enforce for a specific situation. The Decision API mimics closely the XACML request standard in that it supports a subject, action and resource.

Field Required XACML equivalent Description
ONAPName True subject The name of the ONAP project making the call
ONAPComponent True subject The name of the ONAP sub component making the call
ONAPInstance False subject An optional instance ID for that sub component
action True action The action being performed
resource True resource An object specific to the action that contains properties describing the resource

It is worth noting that we use basic authorization for API access with username and password set to healthcheck and zb!XztG34 respectively. Also, the new APIs support both http and https.

For every API call, client is encouraged to insert an uuid-type requestID as parameter. It is helpful for tracking each http transaction and facilitates debugging. Mostly importantly, it complies with Logging requirements v1.2. If client does not provider the requestID in API call, one will be randomly generated and attached to response header x-onap-requestid.

In accordance with ONAP API Common Versioning Strategy Guidelines, in the response of each API call, several custom headers are added:

x-latestversion: 1.0.0
x-minorversion: 0
x-patchversion: 0
x-onap-requestid: e1763e61-9eef-4911-b952-1be1edd9812b

x-latestversion is used only to communicate an API’s latest version.

x-minorversion is used to request or communicate a MINOR version back from the client to the server, and from the server back to the client.

x-patchversion is used only to communicate a PATCH version in a response for troubleshooting purposes only, and will not be provided by the client on request.

x-onap-requestid is used to track REST transactions for logging purpose, as described above.

HealthCheck

GET /policy/pdpx/v1/healthcheck

Perform a system healthcheck

  • Produces: [u’application/json’]
  • Description: Provides healthy status of the Policy Xacml PDP component
  • Consumes: [u’application/json’]

Parameters

Name Position Description Type
X-ONAP-RequestID header RequestID for http transaction string

Responses

200 - successful operation

403 - Authorization Error

500 - Internal Server Error

401 - Authentication Error

Decision

POST /policy/pdpx/v1/decision

Fetch the decision using specified decision parameters

  • Produces: [u’application/json’]
  • Description: Returns the policy decision from Policy Xacml PDP
  • Consumes: [u’application/json’]

Parameters

Name Position Description Type
body body
X-ONAP-RequestID header RequestID for http transaction string

Responses

200 - successful operation

403 - Authorization Error

500 - Internal Server Error

401 - Authentication Error

400 - Bad Request

Statistics

GET /policy/pdpx/v1/statistics

Fetch current statistics

  • Produces: [u’application/json’]
  • Description: Provides current statistics of the Policy Xacml PDP component
  • Consumes: [u’application/json’]

Parameters

Name Position Description Type
X-ONAP-RequestID header RequestID for http transaction string

Responses

200 - successful operation

403 - Authorization Error

500 - Internal Server Error

401 - Authentication Error

End of Document