03 Fn42433en80gla0 Xacml Access Rules

XACML and Access Rules

FN42433EN80GLA0

© Nokia Solutions and Networks 2015.

1

Contents

1 XACML and Access Rules 3

2 Introduction 5

2.1 Namespaces and Schema organization 6

2.2 Data flow model 8

3 Policy language model 11

3.1 Policy and Policy Set 12

3.2 XACML context 14

3.3 Combining algorithms 17

3.4 Target 22

3.5 Subjects 24

3.6 Attribute and AttributeDesignator 26

3.7 Rule 28

3.8 Condition 30

3.9 Apply 32

3.10 Function 33

3.11 Obligation 34

3.12 Functions 36

3.13 XACML Extensions used in PCS-5000 38

3.14 Rule and Policy truth table 39

3.15 Basic steps for policy creation 40

3.16 Multilayered Policy Set Writing 42



FN42433EN80GLA0


2


FN42433EN80GLA0


3

1 XACML and Access Rules


FN42433EN80GLA0


4


FN42433EN80GLA0


5

2 Introduction


FN42433EN80GLA0


6

XACML is an access control language which is based on XML (Extensible Markup Language) and standardized by OASIS. XACML describes both:

an access control Policy language - who can do, what, when

request/response language - expresses queries whether a particular access should be allowed (requests) and describes answers to those queries (responses).

Policy is specified in XML format. The request to access resources and their corresponding response is also specified using XML.

2.1 Namespaces and Schema organization

XACML use XML Namespace and XML Schema. The Namespaces in XML Recommendation defines the syntax for naming XML

namespaces but not the syntax for defining what is in this namespace. This is left to another specification, namely XML Schema. XML namespace identifiers must also conform to a specific syntax for Uniform

Resource Identifier (URI) references. This means that XML namespace identifiers must follow the generic syntax for URIs defined by RFC 2396. Organizations which define XML namespaces is W3C working group

(http://www.w3.org/TR/xml-names/). An XML Schema describes the structure of an XML document. It defines an XML-based syntax for defining elements, attributes, and types in a namespace. XML

Schema finally makes it possible to provide a syntactic definition of a namespace. Organization which define XML Schema is W3C working group (http://www.w3.org/XML/Schema).

Namespaces and Schema organization used in XACML

The XACML Policy syntax is defined in a schema associated with the following XML namespace:

urn:oasis:names:tc:xacml:1.0:Policy

The XACML context syntax is defined in a schema associated with the following XML namespace:

urn:oasis:names:tc:xacml:1.0:context

http://www.w3.org/TR/xml-names/

http://www.w3.org/XML/Schema


FN42433EN80GLA0


7

XACML - eXtensible Access Control Markup Language, based on

XML - Extensible Markup Language

OASIS - Organization for the Advancement of Structured Information

Standards

W3C - World Wide Web Consortium

XACML describes:

• access control policy language

• request/response language

XML Namespaces and XML Schema in XACML:

• Policy syntax: urn:oasis:names:tc:xacml:1.0:policy

• Context syntax: urn:oasis:names:tc:xacml:1.0:context

Fig. 1

In PCS-5000 we use XACML version 1.

OASIS Standard can be found on the address:

http://www.oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf

http://www.oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf


FN42433EN80GLA0


8

2.2 Data flow model

Main components in the XACML domain and communication between them are shown in the data flow diagram on the next figure.

1. Policy Access Point (PAP) creates a Policy or Policy Set.

2. Subject (client) wants access a particular resource and submits its query (access

request) to the entity protecting the resource, the one which is responsible for access control. This entity is called a Policy Enforcement Point (PEP).

3. The PEP forms a request (using the XACML request language) based on the attributes of the subject, action, resource, environment and other relevant information. The PEP then sends this request to a Policy Decision Point (PDP).

4, 5. Optionally, PDP can use external or internal Data Base as Policy Information Point (PIP) and request relevant information

6. The PDP retrieves policies (written in the XACML Policy language) that are applicable to this request, and determines whether access should be granted. That is

authorization decision. According to this, response (expressed in the XACML response language) is returned to the PEP. Response can be either access permitted or denied. Optionally, with the answer, PDP can send one or more

Obligations.

7. The PEP fulfils the Obligations.

In our case, subject is a Client, PEP is GGSN/CMTS/BGF and the PDP is the PCS5000.


FN42433EN80GLA0


9

Data Flow Model

Access

Requester

PEP

(Policy Enforcement Point )

PDP(Policy Decision Point)

PAP

(Policy Administration

Point)

PIP

(Policy Information

Point)

1.Policy

2.Access Request

3.Request6.Response:

Result, Obligations

5.Attributes

PCM

PCS

GGSNClient

Set of

activated

policies

Evaluation

4.Attribute

query

EnvironmentSubject Resource

SPR

Fig. 2


FN42433EN80GLA0


10


FN42433EN80GLA0


11

3 Policy language model


FN42433EN80GLA0


12

3.1 Policy and Policy Set

At the root of all XACML policies is a Policy or a Policy Set element. A Policy Set element is a container that can hold other policies or other Policy Sets.

Components of a Policy:

Target

Set of Rules with Rule-combining algorithm identifier

Set of Obligations

Target element determines if the Policy is applicable for given request. The result of the Target can be "Match" or "No Match".

Rule element is evaluated only if the result of the Target is "Match". The result of the Rule is defined by the "Rule Effect". Two effects are possible: "Permit" and "Deny".

Obligation element defines set of operations which should be performed by the PEP according to Rule evaluation.

In case of several Rules in a Policy, result is determined according to the specified Rule-combining algorithm.

In case of Policy Set with several Policies, result is determined according to the specified Policy-combining algorithm.


FN42433EN80GLA0


13

Policy Language Model Policy set

Policy

Rule

Policy combining

algorithm

Rule combining

algorithm

Target

ActionSubject Resource

Obligation

Effect:

Permit, DenyConditions

Match,

No Match

Fig. 3

Fig. 4


FN42433EN80GLA0


14

3.2 XACML context

XACML is intended to be suitable for a variety of application environments. The core language is isolated from the application environment by the XACML context, The XACML context describing a canonical representation for the inputs and outputs of

the PDP.

3.2.1 Request

Decision request must be converted in XACML Context Request. The Request element contains Subject, Resource, Action and Environment elements.

Every of this child element contains a sequence of Attribute elements associated with

the subject, resource, action and environment respectively.

Attribute The Attribute element is the central part of the request context. The Attribute element

contains the following attributes and elements:

AttributeId - Attribute identifier

DataType

Issuer optional

IssueInstant, optional

AttributeValue

Attribute designators (e.g. SubjectAttributeDesignator) in the policy identify the attribute by subject, resource, action or environment and its identifier.

3.2.2 Result

The Result element represents an authorization decision result for the resource

specified by the ResourceId attribute. It may include a set of obligations that must be fulfilled by the PEP. If the PEP does not understand an obligation, then it must act as if the PDP had denied access to the requested resource

The Result element contains the following attributes and elements:

ResourceId, optional

Decision: The authorization decision: “Permit”, “Deny”, “Indeterminate” or

“NotApplicable”.

Status, Optional

Obligations, optional


FN42433EN80GLA0


15

XACML

Context/

Request.xml

PDPXACML

Context/

Response.xml

Xacml

Policy.xml

Domain-spec.

inputsDomain-spec.

outputs

Fig. 5


FN42433EN80GLA0


16

Example:

- <Request>

- <Subject SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-

subject">

- <Attribute AttributeId="com:nsn:com:mn:pcs:2.0:subject:IMSI"

DataType="http://www.w3.org/2001/XMLSchema#string">

<AttributeValue>244085647000003</AttributeValue>

</Attribute>

- <Attribute AttributeId="com:nsn:com:mn:pcs:2.0:subject:IP_CAN_TYPE"


<AttributeValue>NO_IP_CAN</AttributeValue>

</Attribute>

- <Attribute AttributeId="com:nsn:com:mn:pcs:2.0:subject:QCI"


<AttributeValue>I</AttributeValue>

</Attribute>

- <Attribute AttributeId="com:nsn:com:mn:pcs:2.0:subject:Billingplan"


<AttributeValue>postpaid</AttributeValue>

</Attribute> . . . . . . . . . .

. . . . . . . . . .

</Subject>

- <Resource>

- <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"

DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue />

</Attribute>

</Resource>

- <Action>

- <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>DefaultAction</AttributeValue>

</Attribute>

</Action>

</Request>

</Request>


FN42433EN80GLA0


17

3.3 Combining algorithms

XACML defines combining algorithm for Policy Set and for Policy. For Policy Set element combining algorithm is defined by attribute "PolicyCombiningAlgId". For Policy element combining algorithm is defined by attribute "RuleCombiningAlgId".

3.3.1 Rule-combining algorithms

A Policy can have multiple Rules. It is possible for different Rules to generate

conflicting results. Rule-combining algorithms are responsible for resolving such

conflicts. Rule-combining algorithms combine the effects of all the Rules in a Policy to provide a final authorization decision. Only one Rule-combining algorithm is applicable per Policy.

Following Rule-combining algorithms are defined:

Deny-overrides:

If any Rule evaluates to Deny, then the result of the Rule combination is also "Deny".

Special cases: If all Rules are found to be "NotApplicable" to the decision request, then the Rule combination is evaluated to "NotApplicable".

If an error occurs while evaluating a Rule that contains an effect value of "Deny" and no other Rule evaluates to "Deny", then the Rule combination is evaluated to "Indeterminate", with the appropriate error status.

If at least one Rule evaluates to "Permit" and no other Rule evaluates to "Deny, then the Rule combination is "Permit".

Ordered-deny-overrides:

Same as deny-overrides, except the order in which relevant Rules are evaluated is

the same as the order in which they are added in the Policy.

Permit-overrides:

If any Rule evaluates to Permit, then the Rule combination is also "Permit". Special cases:

If all Rules are found to be "NotApplicable" to the decision request, then the Rule combination is evaluated to "NotApplicable". If any Rule evaluates to "Deny" and all other Rules evaluate to "NotApplicable", then

the Rule combination is evaluate to "Deny". If an error occurs while evaluating the Target or Condition of a Rule that contains an effect of "Permit" and no other Rule evaluates to "Permit", then the Policy is

evaluated to "Indeterminate", with the appropriate error status. If at least one Rule evaluates to "Deny" and no other Rule evaluates to "Permit", then the Rule combination is "Deny".


FN42433EN80GLA0


18

Ordered-permit-overrides:

Same as permit-overrides, except that the order in which relevant Rules are evaluated is the same as the order in which they are added in the Policy.

First-applicable:

The result of the first relevant Rule encountered is the final result as well

Special cases: If all Rules are evaluated as "NotApplicable", then the Rule combination is evaluate to "NotApplicable".

If an error occurs while evaluating the Rule, then the evaluation should halt, and the Policy is evaluated to "Indeterminate", with the appropriate error status.


FN42433EN80GLA0


19

Rule-combining algorithms

Fig. 6


FN42433EN80GLA0


20

3.3.2 Policy-combining algorithms

A Policy Set can have multiple policies. It is possible for different policies to generate conflicting results. Policy-combining algorithm is responsible for resolving such

conflicts. It also provides a final authorization decision. The Decision value placed in the response context by the PDP is the result of the evaluation of the Policy Set, as defined by the Policy-combining algorithm.

Only one Policy-combining algorithm is applicable per Policy Set.

Deny-overrides:

If any Policy evaluates to Deny, then the final authorization decision is also Deny.

Special cases: If all policies are found to be "NotApplicable" to the decision request, then the Policy Set is evaluated to "NotApplicable".

If an error occurs while evaluating the Target of a Policy, or a reference to a Policy is invalid or the Policy evaluation results are "Indeterminate", then the Policy Set is evaluated to "Deny".

Ordered-deny-overrides:

Same as deny-overrides, except the order in which relevant policies are evaluated is the same as the order in which they are added in the Policy.

Permit-overrides:

If any Policy evaluates to Permit, then the final authorization decision is also Permit.

Special cases: If all policies are found to be "NotApplicable" to the decision request, then the Policy Set is evaluated to "NotApplicable".

If an error occurs while evaluating the Target of a Policy, or a reference to a Policy is invalid or the Policy evaluation results are "Indeterminate", then the Policy Set is evaluated to "Indeterminate", with the appropriate error status

Ordered-permit-overrides:

Same as permit-overrides, except the order in which relevant policies are evaluated is the same as the order in which they are added in the Policy Set.

First-applicable: The result of the first relevant Policy encountered is the final authorization decision.

Only-one-applicable

If only one Policy is considered applicable by evaluation of the Policy Targets, then

the result of this Policy is the result of Policy-combining algorithm Special cases: If all policies are found to be "NotApplicable" to the decision request, then the Policy

Set is evaluated to "NotApplicable". If more than one Policy is considered applicable by evaluation of the Policy Targets, then the result of the Policy combination algorithm is "Indeterminate".

If an error occurs while evaluating the Target of a Policy, or a reference to a Policy is


FN42433EN80GLA0


21

considered invalid or the Policy evaluation results in "Indeterminate", then the Policy Set is evaluated to "Indeterminate", with the appropriate error status.

Policy-combining algorithms

Fig. 7


FN42433EN80GLA0


22

3.4 Target

Target element belongs (appears as a "child") to the Policy Set, Policy or Rule element. It is a set of simplified conditions for the Subject, Resource and Action that must be met for a Policy Set, Policy or Rule to apply to a given request. These use

Boolean functions to compare values found in a request with those included in the Target.

Policy Target

The PDP does not evaluate all policies. If the Policy is relevant for the particular

request is determined with a help of Target.

Each Policy has only one Target. The result of Target evaluation can be "Match" or

"No Match". For result "Match", this Policy is to be evaluated.

Special case:

The Policy is applicable to any request. The value of attribute of Subject, Resource or Action is not relevant for further Policy evaluation. This will be defined in Target as any subject, any resource and any action.

Rule Target

Purpose and components of the Rule Target are the same as in case of Policy Target.

The Target element may be absent from a Rule. In this case, the Target of the Rule is the same as that of the parent Policy element.

Components of Target:

Target element contains conjunctive (AND) sequence of following element:

Subject

Resources (data, service or system component)

Actions (the action that the subject is trying to perform on the resource)

Every element of the Target is defined by one or more attributes and their value. The value of these attributes is compared with the value of the same kind of attribute in

the request. Whether they match or not is determined after we apply them with some function. If they match, then the Policy is considered relevant to the request and is evaluated.


FN42433EN80GLA0


23

Fig. 8

Fig. 9


FN42433EN80GLA0


24

3.5 Subjects

The Subjects contains one or more Subject elements.

Subject

contains one or more SubjectMatch elements.

SubjectMatch

The SubjectMatch element identifies a set of subject-related entities by matching

attribute values in a xacml-context:Subject element of the context with the embedded Attribute value. The SubjectMatch element contains the following attributes and elements:

MatchId

Specifies a matching function.

AttributeValue

Embedded attribute value.

SubjectAttributeDesignator

Identifies one or more attribute values in a Subject element of the context.

AttributeSelector

Identifies one or more attribute values in the request context.

The same format is valid for Resources and Actions element.

NOTE

Disjunctive sequence - a sequence of boolean elements combined using the logical ‘OR’ operation

Conjunctive sequence - a sequence of boolean elements combined using the logical ‘AND’ operation


FN42433EN80GLA0


25

Subjects element: disjunctive sequence of Subject elements (OR)

Fig. 10

Subject element: conjunctive sequence of SubjectMatch elements (AND)

Fig. 11


FN42433EN80GLA0


26

3.6 Attribute and AttributeDesignator

Attributes are used to present currency. Every Attributes is defined by name, known type and some value.

Name and type are specified by AttributeDesignator

Value of the attribute is specified by AtributeValue.

When a request is sent from PEP to a PDP, it is formed exclusively out of Attributes. These Attributes will be compared to corresponding attribute in a Policy.

AttributeDesignator has a function of pointer to a separate attribute in the request

context. AttributeDesignator can return from context one value or multiple values. To handle multiple values, XACML has a special data type called a bag. Bags are unordered collections that allow duplicates.

Following AttributeDesignators are possible:

Subject: SubjectAttributeDesignator

Resource: ResourceAttributeDesignator

Action: ActionAttributeDesignator

Environment: EnvironmentAttributeDesignator

SubjectAttributeDesignator

The SubjectAttributeDesignator element is used to refer to named categorized subject elements in the Request Context.

Attributes of SubjectAtributDesignator:

1. AttributeId Used to reference the Attribute in the Request Context. Example for SubjectAttributeDesignator: BillingPlan, PricingPlan, category

Example for ActionAttributeDesignator: action-id

2. DataType

Example: string

3. Issuer, optional

4. MustBePresent, optional

5. SubjectCategory


FN42433EN80GLA0


27

AttributeValue is defined by:

The AttributeValue element is defined by

Data Type

Example for SubjectAttributeDesignator: PREPAID, PlanA, TierA Example for ActionAttributeDesignator: Invoke:

Value of this Attribute Example: string

The same format is valid for ResourceAttributeDesignator,

EnvironmentAttributeDesignator and ActionAttributeDesignator element.

Fig. 12


FN42433EN80GLA0


28

3.7 Rule

The Rule element is the most important component of the Policy. Once a Policy is found and verified as applicable to a request, its Rules are evaluated. One Policy can have any number of Rules.

Elements of a Rule are:

Rule Target Resources, Subjects, Actions; Result: True or False

Condition Result: True, False or Indeterminate

Rule attributes:

RuleId

Effect: Permit or Deny

Firstly, PCS verifies Rule Target. If a Target is present and if the match returns “True” then the Rule (its Condition) is evaluated.

What Effect this Rule has if the Rule evaluates to “True” is defined by its attribute Effect. Two values of this Effect are possible: “Permit” or “Deny”

If a Rule evaluates to “False”, the result it returns will be of “NotApplicable”. If an error occurs when evaluating the Rule, the result it returns will be “Indeterminate”.


FN42433EN80GLA0


29

Rule Components

Rule target (optional)

• Resources

• Subjects

• Actions

Effect

• Permit

• Deny

Condition

• True

• False

• Indeterminate

Rule result:• Permit

• Deny

• Indeterminate

• NotApplicable

Fig. 13

Fig. 14


FN42433EN80GLA0


30

3.8 Condition

The Condition element is a Boolean function over subject, resource, action and environment attributes. Upon evaluation, Condition returns:

"True",

"False", or

"Indeterminate".

In special case, Condition element can be absent. The result will be the same as positive evaluation: "True".

If any attribute value referenced in the Condition cannot be obtained, then the Condition evaluates as "Indeterminate" The Condition must be evaluated as “True” for the Rule to be applicable!

Condition element is defined by the "FunctionId" attribute. By this "FunctionId" is defined the Function to be used for comparison over Attributes.

The Condition element is of ApplyType.


FN42433EN80GLA0


31

Fig. 15


FN42433EN80GLA0


32

3.9 Apply

The Apply element is used for a function call. The Apply element is defined by its argument, FunctionId. As argument of Apply can be any combination of following arguments: AttributeValue, SubjectAttributeDesignator, ResourceAttributeDesignator,

ActionAttributeDesignator or EnvironmentAttributeDesignator,

The Apply element contains the following attributes and elements:

FunctionId, Identification of a function

Function; Optional] The name of a function that is applied to the elements of a bag

Apply; Optional A nested function-call argument.

AttributeValue; Optional A literal value argument.

SubjectAttributeDesignator, ResourceAttributeDesignator, ActionAttributeDesignator or EnvironmentAttributeDesignator: Optional.

Fig. 16


FN42433EN80GLA0


33

3.10 Function

The Function element is used to name a function that is applied by the higher-order bag functions to every element of a bag.

The Function element is defined by the FunctionId attribute.

Fig. 17


FN42433EN80GLA0


34

3.11 Obligation

A Policy or Policy Set may contain one or more Obligations. Obligations are the actions that must be performed by the PEP in conjunction with the enforcement of an authorization decision. After a Policy has been evaluated, specific Obligations are

sent to the PEP along with the authorization decision. An Obligation may be associated with a positive ("Permit") or negative ("Deny")

authorization decision No Obligations should be returned to the PEP if the effect of the Policy or Policy Set being evaluated does not match the value of the FulfillOn attribute of the Obligation.

The Obligation element consists of:

ObligationId:

identifies an Obligation

FulfillOn:

the authorization decision value for which this Obligation must be fulfilled. Possible values: Permit and Deny

set of attribute assignments Every attribute specifies operation to be performed by the PEP


FN42433EN80GLA0


35

Fig. 18


FN42433EN80GLA0


36

3.12 Functions

Function is used is used in different elements and attributes:

MatchId attribute

defines matching function in SubjectMatch, ResourceMatch and ActionMatch element

Condition function to be used is defined by FunctionId attribute.

Apply functions can take other functions as arguments (nesting). The Apply element encodes the function call with the FunctionId attribute.

Function

XACML includes standard support for a variety of functions from simple Boolean

operation (equal, and/or/not, grater then, less then) to complex functions

XACML specifies the functions that are prefixed with the name space identifier

“urn:oasis:names:tc:xacml:1.0:function:”

Examples:

equality functions:

string-equal, integer-equal, time-equal…

Arithmetic functions

integer-add, integer-subtract, integer-multiply…

Logical functions

OR, AND, NOT…

Bag functions:

string-bag, any-of, all-of…


FN42433EN80GLA0


37

Functions

• MatchId

matching function in: SubjectMatch, ResourceMatch and ActionMatch element

• Condition

function to be used is defined by FunctionId attribute.

• Apply

function call with the FunctionId attribute.

• Function

function to be used is defined by FunctionId attribute

Examle:• Equality function: string-equal

urn:oasis:names:tc:xacml:1.0:function:string-equal

• Arithmetic function: integer-add

urn:oasis:names:tc:xacml:1.0:function:integer-add

• Logical function:OR

urn:oasis:names:tc:xacml:1.0:function:or

• Bag functions: string-bag

urn:oasis:names:tc:xacml:1.0:function:string-bag

Fig. 19


FN42433EN80GLA0


38

3.13 XACML Extensions used in PCS-5000

urn:oasis:names:tc:xacml:1.0:function:string-substr This function SHALL take two arguments of data-type “http://www.w3.org/2001/XMLSchema#string” and SHALL return an

“http://www.w3.org/2001/XMLSchema#boolean”. It SHALL return "True" if and only

if the first argument is a sub-string of the second argument. Otherwise, it SHALL return “False”. For ex: if argument1 = “string” and argument2=“sample string”, then

the result=”True”.

urn:oasis:names:tc:xacml:1.0:function:string-starts-with

This function SHALL take two arguments of data-type “http://www.w3.org/2001/XMLSchema#string” and SHALL return an


if the second argument starts with of the first argument. Otherwise, it SHALL return “False”. For ex: if argument1 = “sample” and argument2=“sample string”, then the

result=”True”.

urn:oasis:names:tc:xacml:1.0:function:string-ends-with

This function SHALL take two arguments of data-type “http://www.w3.org/2001/XMLSchema#string” and SHALL return an


if the second argument ends with of the first argument. Otherwise, it SHALL return “False”. For ex: if argument1 = “ing” and argument2=“sample string”, then the

result=”True”.

urn:oasis:names:tc:xacml:1.0:function:string-to-daytimeduration

This function SHALL take one argument of data-type "http://www.w3.org/2001/XMLSchema#string" which SHALL indicate the duration

in days and convert the same to and return an element of data-type "http://www.w3.org/TR/2002/WD-xquery-operators-20020816#dayTimeDuration".


FN42433EN80GLA0


39

3.14 Rule and Policy truth table

Rule truth table Policy truth table

Rule Value Condition Target

“Indeterminate”Don’t-care “Indeterminate”

“NotApplicable”Don’t-care “No-Match”

“Indeterminate”“Indeterminate”“Match”

“NotApplicable”“False””“Match”

Effect“True”“Match”

“Indeterminate”Don’t-care “Indeterminate”

“NotApplicable”Don’t-care “No-Match”

Specified by the

rulecombining

algorithm

At least one rulevalue

is “Indeterminate”

“Match”

“NotApplicable”All rule values

are“NotApplicable”

“Match”

Specified by the

rulecombining

algorithm

At least one rule value

is its Effect

“Match”

Policy Value Rule values Target

Fig. 20


FN42433EN80GLA0


40

3.15 Basic steps for policy creation

Step 1

Target For whom, for what is this policy is applicaple? Based

on any parameters?

Condition The logic

Effect Permit/Deny

Obligation Which actions additionally to perform, based on

the “Effect”

Fig. 21

Step 2: Define the attributes

Make a list of SPR parameters that you want to use

Make a list of Interface attributes that you want to use

Create attributes for each one of them

Fig. 22


FN42433EN80GLA0


41

Step 3: Define the policy

Use the XACML Editor to create the Policy

• The TARGET

• The RULE(S)

- The CONDITION

- The EFFECT

• The OBLIGATIONS

Save and validate the policy

Fig. 23


FN42433EN80GLA0


42

3.16 Multilayered Policy Set Writing

A whole new approach to policy writing in PCS, which essentially helps to segregate use cases into priority based layers for processing. This takes away the burden of having to parse through the entire policy to reach policy evaluation based decisions.

This feature enhances the overall performance aspect of the PCS.

PCM supports:

Creation of Multiple Policy sets.

Assigning and editing priorities for policy sets.

Assigning and editing priorities for policies/policy subsets within a policy set.

Creation and editing Targets for every policy set.

Configuring and editing Policy Combining Algorithm for every policy set.

Displaying Policies within the policy sets(policies related to particular sets should

be displayed with those sets).

Displaying policy sub sets for a policy set(policy sub sets related to particular sets should be displayed with those sets).

Activate/Deactivate policy sets or subsets.

Import/Export policy sets.

Copying a policy from one policy set to another.

Copying a policy set from one policy set to another.

Copy a policy or policy set from policy set of one project to policy set of another project.

Various ways to segregate the policies:

Based on Interfaces

Gx-Interface related policies.

Rx-Interface related policies.

Based on Conditions

Interface related policies

Profile related policies

Based on any common attributes (e.g. APN)

Backward compatibility

No impacts, if multi layered policies not required.


FN42433EN80GLA0


43

Fig. 24

Policy Set

Policies at

Policy Set level

Fig. 25


FN42433EN80GLA0


44

Documents

03 Fn42433en80gla0 Xacml Access Rules