03 fn42433en80gla0 xacml access rules
Post on 10-Apr-2016
9 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
XACML and Access Rules
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
2
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
3
1 XACML and Access Rules
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
4
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
5
2 Introduction
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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.
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
10
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
11
3 Policy language model
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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.
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
15
XACML
Context/
Request.xml
PDPXACML
Context/
Response.xml
Xacml
Policy.xml
Domain-spec.
inputsDomain-spec.
outputs
Fig. 5
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>NO_IP_CAN</AttributeValue>
</Attribute>
- <Attribute AttributeId="com:nsn:com:mn:pcs:2.0:subject:QCI"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>I</AttributeValue>
</Attribute>
- <Attribute AttributeId="com:nsn:com:mn:pcs:2.0:subject:Billingplan"
DataType="http://www.w3.org/2001/XMLSchema#string">
<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>
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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".
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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.
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
19
Rule-combining algorithms
Fig. 6
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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.
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
23
Fig. 8
Fig. 9
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
25
Subjects element: disjunctive sequence of Subject elements (OR)
Fig. 10
Subject element: conjunctive sequence of SubjectMatch elements (AND)
Fig. 11
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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”.
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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.
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
31
Fig. 15
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
35
Fig. 18
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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…
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
“http://www.w3.org/2001/XMLSchema#boolean”. It SHALL return "True" if and only
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
“http://www.w3.org/2001/XMLSchema#boolean”. It SHALL return "True" if and only
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".
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
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.
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
43
Fig. 24
Policy Set
Policies at
Policy Set level
Fig. 25
XACML and Access Rules
FN42433EN80GLA0
© Nokia Solutions and Networks 2015.
44
top related