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 requests/responses 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 for ONAP components.

ONAP XACML PDP Supported Policy Types

The following Policy Types are supported by the XACML PDP Engine (PDP-X):

Supported Base Policy Types

Application

Base Policy Type

Action

Description

Monitoring

onap.policies.Monitoring

configure

Control Loop DCAE Monitoring Policies

Guard

onap.policies.controlloop.guard.Common

guard

Control Loop Guard and Coordination Policies

Optimization

onap.policies.Optimization

optimize

Optimization policy types used by OOF

Naming

onap.policies.Naming

naming

Naming policy types used by SDNC

Native

onap.policies.native.Xacml

native

Native XACML Policies

Match

onap.policies.Match

native

Matchable Policy Types for the ONAP community to use

Each Policy Type is implemented as an application that extends the XacmlApplicationServiceProvider, and provides a ToscaPolicyTranslator that translates the TOSCA representation of the policy into a XACML OASIS 3.0 standard policy.

By cloning the policy/xacml-pdp repository, a developer can run the JUnit tests for the applications 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.

See the Policy Platform Development Tools for more information on cloning and developing the policy repositories.

XACML-PDP applications are located in the ‘applications’ sub-module in the policy/xacml-pdp repo. Click here to view the applications sub-modules

XACML PDP TOSCA Translators

The following common translators are available in ONAP for use by developers. Each is used or extended by the standard PDP-X applications in ONAP.

StdCombinedPolicyResultsTranslator Translator

A simple translator that wraps the TOSCA policy into a XACML policy and performs matching of the policy based on either policy-id and/or policy-type. The use of this translator is discouraged as it behaves like a database call and does not take advantage of the fine-grain decision making features described by the XACML OASIS 3.0 standard. It is used to support backward compatibility of legacy “configure” policies.

Implementation of Combined Results Translator.

The Monitoring and Naming applications use this translator.

StdMatchableTranslator Translator

More robust translator that searches metadata of TOSCA properties for a matchable field set to true. The translator then uses those “matchable” properties to translate a policy into a XACML OASIS 3.0 policy which allows for fine-grained decision making such that ONAP applications can retrieve the appropriate policy(s) to be enforced during runtime.

Each of the properties designated as “matchable” are treated relative to each other as an “AND” during a Decision request call. In addition, each value of a “matchable property that is an array, is treated as an “OR”. The more properties specified in a decision request, the more fine-grained a policy will be returned. In addition, the use of “policy-type” can be used in a decision request to further filter the decision results to a specific type of policy.

Implementation of Matchable Translator.

The Optimization application uses this translator.

GuardTranslator and CoordinationGuardTranslator

These two translators are used by the Guard application and are very specific to those Policy Types. They are good examples on how to build your own translator for a very specific implementation of a policy type. This can be the case if any of the Std* translators are not appropriate to use directly or override for your application.

Implementation of Guard Translator

Implementation of Coordination Translator

Native XACML OAISIS 3.0 XML Policy Translator

This translator pulls a URL encoded XML XACML policy from a TOSCA Policy and loads it into a XACML Engine. This allows native XACML policies to be used to support complex use cases in which a translation from TOSCA to XACML is too difficult.

Implementation of Native Policy Translator

Monitoring Policy Types

These Policy Types are used by Control Loop DCAE microservice components to support monitoring of VNF/PNF entities to support an implementation of a 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.

The following policy types derive from onap.policies.Monitoring:

Derived Policy Type

Action

Description

onap.policies.monitoring.tcagen2

configure

TCA DCAE microservice gen2 component

onap.policies.monitoring.dcaegen2.collectors.datafile.datafile-app-server

configure

REST Collector

onap.policies.monitoring.docker.sonhandler.app

configure

SON Handler microservice component

Note

DCAE project deprecated TCA DCAE microservice in lieu for their gen2 microservice. Thus, the policy type onap.policies.monitoring.cdap.tca.hi.lo.app was removed from Policy Framework.

This is an example Decision API payload made to retrieve a decision for a Monitoring Policy by id. Not recommended - as users may change id’s of a policy. Available for backward compatibility.

{
  "ONAPName": "DCAE",
  "ONAPComponent": "PolicyHandler",
  "ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64",
  "action": "configure",
  "resource": {
      "policy-type": "onap.policies.monitoring.tcagen2"
  }
}

This is an example Decision API payload made to retrieve a decision for all deployed Monitoring Policies for a specific type of Monitoring policy.

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

Guard and Control Loop Coordination Policy Types

These Policy Types are used by Control Loop Drools Engine to support guarding control loop operations and coordination of Control Loops during runtime control loop execution.

Policy Type

Action

Description

onap.policies.controlloop.guard.common.FrequencyLimiter

guard

Limits frequency of actions over a specified time period

onap.policies.controlloop.guard.common.Blacklist

guard

Blacklists a regexp of VNF IDs

onap.policies.controlloop.guard.common.MinMax

guard

For scaling, enforces a min/max number of VNFS

onap.policies.controlloop.guard.common.Filter

guard

Used for filtering entities in A&AI from Control Loop actions

onap.policies.controlloop.guard.coordination.FirstBlocksSecond

guard

Gives priority to one control loop vs another

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",
          "operation": "VF Module Create",
          "clname": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3",
          "target": "vLoadBalancer-00",
          "vfCount": "1"
      }
  }
}

The return decision simply has “permit” or “deny” in the response to tell the calling application whether they are allowed to perform the operation.

{"status":"Permit"}

Guard Common Base Policy Type

Each guard Policy Type derives from onap.policies.controlloop.guard.Common base policy type. Thus, they share a set of common properties.

Common Properties for all Guards

Property

Examples

Required

Type

Description

actor

APPC, SO

Required

String

Identifies the actor involved in the Control Loop operation.

operation

Restart, VF Module Create

Required

String

Identifies the Control Loop operation the actor must perform.

timeRange

start_time: T00:00:00Z end_time: T08:00:00Z

Optional

tosca.datatypes.TimeInterval

A given time range the guard is in effect. Following the TOSCA specification the format should be ISO 8601 format

id

control-loop-id

Optional

String

A specific Control Loop id the guard is in effect.

Common Guard Policy Type

Frequency Limiter Guard Policy Type

The Frequency Limiter Guard is used to specify limits as to how many operations can occur over a given time period.

Frequency Guard Properties

Property

Examples

Required

Type

Description

timeWindow

10, 60

Required

integer

The time window to count the actions against.

timeUnits

second minute, hour, day, week, month, year

Required

String

The units of time the window is counting

limit

5

Required

integer

The limit value to be checked against.

tosca_definitions_version: tosca_simple_yaml_1_1_0
topology_template:
  policies:
    -
      guard.frequency.scaleout:
        type: onap.policies.controlloop.guard.common.FrequencyLimiter
        type_version: 1.0.0
        version: 1.0.0
        name: guard.frequency.scaleout
        description: Here we limit the number of Restarts for my-controlloop to 3 in a ten minute period.
        metadata:
          policy-id : guard.frequency.scaleout
        properties:
          actor: APPC
          operation: Restart
          id: my-controlloop
          timeWindow: 10
          timeUnits: minute
          limit: 3

Frequency Limiter Guard Policy Type

Min/Max Guard Policy Type

The Min/Max Guard is used to specify a minimum or maximum number of instantiated entities in A&AI. Typically this is a VFModule for Scaling operations. One should specify either a min or a max value, or both a min and max value. At least one must be specified.

Min/Max Guard Properties

Property

Examples

Required

Type

Description

target

e6130d03-56f1-4b0a-9a1d-e1b2ebc30e0e

Required

String

The target entity that has scaling restricted.

min

1

Optional

integer

Minimum value. Optional only if max is not specified.

max

5

Optional

integer

Maximum value. Optional only if min is not specified.

tosca_definitions_version: tosca_simple_yaml_1_1_0
topology_template:
    policies:
    -   guard.minmax.scaleout:
            type: onap.policies.controlloop.guard.common.MinMax
            type_version: 1.0.0
            version: 1.0.0
            name: guard.minmax.scaleout
            metadata:
                policy-id: guard.minmax.scaleout
            properties:
                actor: SO
                operation: VF Module Create
                id: my-controlloop
                target: the-vfmodule-id
                min: 1
                max: 2

Min/Max Guard Policy Type

Blacklist Guard Policy Type

The Blacklist Guard is used to specify a list of A&AI entities that are blacklisted from having an operation performed on them. Recommendation is to use the vnf-id for the A&AI entity.

Blacklist Guard Properties

Property

Examples

Required

Type

Description

blacklist

e6130d03-56f1-4b0a-9a1d-e1b2ebc30e0e

Required

list of string

List of target entity’s that are blacklisted from an operation.

tosca_definitions_version: tosca_simple_yaml_1_1_0
topology_template:
    policies:
    -   guard.blacklist.scaleout:
            type: onap.policies.controlloop.guard.common.Blacklist
            type_version: 1.0.0
            version: 1.0.0
            name: guard.blacklist.scaleout
            metadata:
                policy-id: guard.blacklist.scaleout
            properties:
                actor: APPC
                operation: Restart
                id: my-controlloop
                blacklist:
                - vnf-id-1
                - vnf-id-2

Blacklist Guard Policy Type

Filter Guard Policy Type

The Filter Guard is a more robust guard for blacklisting and whitelisting A&AI entities when performing control loop operations. The intent for this guard is to filter in or out a block of entities, while allowing the ability to filter in or out specific entities. This allows a DevOps team to control the introduction of a Control Loop for a region or specific VNF’s, as well as block specific VNF’s that are being negatively affected when poor network conditions arise. Care and testing should be taken to understand the ramifications when combining multiple filters as well as their use in conjunction with other Guard Policy Types.

Filter Guard Properties

Property

Examples

Required

Type

Description

algorithm

blacklist-overrides

Required

What algorithm to be applied

blacklist-overrides or whitelist-overrides are the valid values. Indicates whether blacklisting or whitelisting has precedence.

filters

see table below

Required

list of onap.datatypes.guard.filter

List of datatypes that describe the filter.

Filter Guard onap.datatypes.guard.filter Properties

Property

Examples

Required

Type

Description

field

generic-vnf.vnf-name

Required

String

Field used to perform filter on and must be a string value. See the Policy Type below for valid values.

filter

vnf-id-1

Required

String

The filter being applied.

function

string-equal

Required

String

The function that is applied to the filter. See the Policy Type below for valid values.

blacklist

true

Required

boolean

Whether the result of the filter function applied to the filter is blacklisted or whitelisted (eg Deny or Permit).

tosca_definitions_version: tosca_simple_yaml_1_1_0
topology_template:
   policies:
   -  filter.block.region.allow.one.vnf:
         description: Block this region from Control Loop actions, but allow a specific vnf.
         type: onap.policies.controlloop.guard.common.Filter
         type_version: 1.0.0
         version: 1.0.0
         properties:
            actor: SO
            operation: VF Module Create
            algorithm: whitelist-overrides
            filters:
            -  field: cloud-region.cloud-region-id
               filter: RegionOne
               function: string-equal
               blacklist: true
            -  field: generic-vnf.vnf-id
               filter: e6130d03-56f1-4b0a-9a1d-e1b2ebc30e0e
               function: string-equal
               blacklist: false
   -  filter.allow.region.block.one.vnf:
         description: allow this region to do Control Loop actions, but block a specific vnf.
         type: onap.policies.controlloop.guard.common.Filter
         type_version: 1.0.0
         version: 1.0.0
         properties:
            actor: SO
            operation: VF Module Create
            algorithm: blacklist-overrides
            filters:
            -  field: cloud-region.cloud-region-id
               filter: RegionTwo
               function: string-equal
               blacklist: false
            -  field: generic-vnf.vnf-id
               filter: f17face5-69cb-4c88-9e0b-7426db7edddd
               function: string-equal
               blacklist: true

Filter Guard Policy Type

Optimization Policy Types

These Policy Types are designed to be used by the OOF Project support several domains including VNF placement in ONAP. The OOF Platform makes a call to the Decision API to request these Policies based on the values specified in the onap.policies.Optimization properties. Each of these properties are treated relative to each other as an “AND”. In addition, each value for each property itself is treated as an “OR”.

Policy Type

Action

onap.policies.Optimization

optimize

onap.policies.optimization.Service

optimize

onap.policies.optimization.Resource

optimize

onap.policies.optimization.resource.AffinityPolicy

optimize

onap.policies.optimization.resource.DistancePolicy

optimize

onap.policies.optimization.resource.HpaPolicy

optimize

onap.policies.optimization.resource.OptimizationPolicy

optimize

onap.policies.optimization.resource.PciPolicy

optimize

onap.policies.optimization.service.QueryPolicy

optimize

onap.policies.optimization.service.SubscriberPolicy

optimize

onap.policies.optimization.resource.Vim_fit

optimize

onap.policies.optimization.resource.VnfPolicy

optimize

The optimization application extends the StdMatchablePolicyTranslator in that the application applies a “closest match” algorithm internally after a XACML decision. This filters the results of the decision to return the one or more policies that match the incoming decision request as close as possible. In addition, there is special consideration for the Subscriber Policy Type. If a decision request contains subscriber context attributes, then internally the application will apply an initial decision to retrieve the scope of the subscriber. The resulting scope attributes are then added into a final internal decision call.

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": {
      "scope": [],
      "services": ["vCPE"],
      "resources": ["vGMuxInfra", "vG"],
      "geography": ["US", "INTERNATIONAL"]
  }
}

Native XACML Policy Type

This Policy type is used by any client or ONAP component who has the need of native XACML evaluation. A native XACML policy or policy set encoded in XML can be created off this policy type and loaded into the XACML PDP engine by invoking the PAP policy deployment API. Native XACML requests encoded in either JSON or XML can be sent to the XACML PDP engine for evaluation by invoking the native decision API. Native XACML responses will be returned upon evaluating the requests against the matching XACML policies. Those native XACML policies, policy sets, requests and responses all follow the OASIS XACML 3.0 Standard.

Policy Type

Action

Description

onap.policies.native.Xacml

native

any client or ONAP component

According to the XACML 3.0 specification, two content-types are supported and used to present the native requests/responses. They are formally defined as “application/xacml+json” and “application/xacml+xml”.

This is an example Native Decision API payload made to retrieve a decision for whether Julius Hibbert can read http://medico.com/record/patient/BartSimpson.

{
    "Request": {
        "ReturnPolicyIdList": false,
        "CombinedDecision": false,
        "AccessSubject": [
            {
                "Attribute": [
                    {
                        "IncludeInResult": false,
                        "AttributeId": "subject-id",
                        "Value": "Julius Hibbert"
                    }
                ]
            }
        ],
        "Resource": [
            {
                "Attribute": [
                    {
                        "IncludeInResult": false,
                        "AttributeId": "resource-id",
                        "Value": "http://medico.com/record/patient/BartSimpson",
                        "DataType": "anyURI"
                    }
                ]
            }
        ],
        "Action": [
            {
                "Attribute": [
                    {
                        "IncludeInResult": false,
                        "AttributeId": "action-id",
                        "Value": "read"
                    }
                ]
            }
        ],
        "Environment": []
    }
}

Match Policy Type

This Policy type can be used to design your own Policy Type and utilize the StdMatchableTranslator, and does not need to build your own custom application. You can design your Policy Type by inheriting from the Match policy type (eg. onap.policies.match.<YourPolicyType>) and adding a matchable metadata set to true for the properties that you would like to request a Decision on. All a user would need to do is then use the Policy Lifecycle API to add their Policy Type and then create policies from it. Then deploy those policies to the XACML PDP and they would be able to get Decisions without customizing their ONAP installation.

Here is an example Policy Type:

tosca_definitions_version: tosca_simple_yaml_1_1_0
policy_types:
   onap.policies.match.Test:
      derived_from: onap.policies.Match
      version: 1.0.0
      name: onap.policies.match.Test
      description: Test Matching Policy Type to test matchable policies
      properties:
         matchable:
            type: string
            metadata:
               matchable: true
            required: true
         nonmatchable:
            type: string
            required: true

Here are example Policies:

tosca_definitions_version: tosca_simple_yaml_1_1_0
topology_template:
    policies:
    -   test_match_1:
            type: onap.policies.match.Test
            version: 1.0.0
            type_version: 1.0.0
            name: test_match_1
            properties:
               matchable: foo
               nonmatchable: value1
    -   test_match_2:
            type: onap.policies.match.Test
            version: 1.0.0
            type_version: 1.0.0
            name: test_match_2
            properties:
               matchable: bar
               nonmatchable: value2

This is an example Decision API request that can be made:

{
  "ONAPName": "my-ONAP",
  "ONAPComponent": "my-component",
  "ONAPInstance": "my-instance",
  "requestId": "unique-request-1",
  "action": "match",
  "resource": {
      "matchable": "foo"
  }
}

Which would render the following decision response:

{
  "policies": {
    "test_match_1": {
      "type": "onap.policies.match.Test",
      "type_version": "1.0.0",
      "properties": {
        "matchable": "foo",
        "nonmatchable": "value1"
      },
      "name": "test_match_1",
      "version": "1.0.0",
      "metadata": {
        "policy-id": "test_match_1",
        "policy-version": "1.0.0"
      }
    }
  }
}

Overriding or Extending the ONAP XACML PDP Supported Policy Types

It is possible to extend or replace one or more of the existing ONAP application implementations with your own. Since the XACML application loader uses the java.util.Service class to search the classpath to find and load applications, it may be necessary via the configuration file to exclude the ONAP packaged applications in order for your custom application to be loaded. This can be done via the configuration file by adding an exclusions property with a list of the Java class names you wish to exclude.

A configuration file example is located here at Line 19

A coding example is available in the JUnit test for the Application Manager called testXacmlPdpApplicationManagerSimple at Line 143. This example demonstrates how to exclude the Match and Guard applications while verifying a custom TestGuardOverrideApplication class is loaded and associated with the guard action. Thus, replacing and extending the guard application.

Note that this XACML PDP feature is exclusive to the XACML PDP and is secondary to the ability of the PAP to group PDP’s and declare which Policy Types are supported by a PDP group. For example, even if a PDP group excludes a Policy Type for a XACML PDP, this simply prevents policies being deployed to that group using the PAP Deployment API. If there is no exclusions in the configuration file, then any application will be loaded that it is in the classpath. If needed, one could use both PDP group Policy Type supported feature and the exclusions configuration to completely restrict which Policy Types as well as which applications are loaded at runtime.

For more information on PDP groups and setting supported Policy Types, please refer to the PAP Documentation

Supporting Your Own Policy Types and Translators

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

XacmlApplicationServiceProvider

Interface for XacmlApplicationServiceProvider

See each of the ONAP Policy Type application implementations which re-use the StdXacmlApplicationServiceProvider class. This implementation can be used as a basis for your own custom applications.

Standard Application Service Provider implementation

ToscaPolicyTranslator

Your custom XacmlApplicationServiceProvider must provide an implementation of a ToscaPolicyTranslator.

Interface for ToscaPolicyTranslator

See each of the ONAP Policy type application implementations which each have their own ToscaPolicyTranslator. Most use or extend the StdBaseTranslator which contain methods that applications can use to support XACML obligations, advice as well as return attributes to the calling client applications via the DecisionResponse.

Standard Tosca Policy Translator implementation.

XACML Application and Enforcement Tutorials

The following tutorials can be helpful to get started on building your own decision application as well as building enforcement into your application. They also show how to build and extend both the XacmlApplicationServiceProvider and ToscaPolicyTranslator classes.