Understanding PIP (Policy Information Point)

According to the XACML reference architecture, PIP is the system entity that acts as a source of attribute values. Basically if there are missing attributes in the XACML request which is sent by PEP, PIP would find them for the PDP to evaluate the policy.

To understand this better, lets go though sample XACML policy and some XACML requests.

Lets take following policy as an example.  We do not want to worry much about the policy.  In this policy;  Subject who has an email address with “xacmlinfo.com” domain, can perform “bar” action on “foo” resource.

<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="TestPolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">foo</AttributeValue>
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule Effect="Permit" RuleId="Rule-1">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">bar</AttributeValue>
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
</Match>
</AllOf>
</AnyOf>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of">
<Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match"/>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">[0-9a-zA-Z][email protected]</AttributeValue>
<AttributeDesignator AttributeId="http://wso2.org/claims/emailaddress" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="Deny-Rule"/>
</Policy>

in this policy, we are interested in following element now

<AttributeDesignator AttributeId="http://wso2.org/claims/emailaddress" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>

First lets try to understand the “<AttributeDesignator>”  element.

AttributeDesignator element has been defined to extract the matching attribute values from the XACML request

Therefore <AttributeDesignator> element with category “urn:oasis:names:tc:xacml:1.0:subject-category:access-subject”    retrieves attribute values from  <Attributes> element with category “urn:oasis:names:tc:xacml:1.0:subject-category:access-subject”  from the XACML requests.

Basically AttributeDesignator finds matching attribute values based following criteria

1. Category must be match
2. AttributeId must be match
3. DataType must be match
4. Issuer must be match . (But Issuer is an optional property AttributeDesignator)

If there are any matching attribute values in the XACML request would returns as a Bag (Actually a collection of attribute values)

Lets assume that following XACML request is send to PDP,

<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">bar</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="http://wso2.org/claims/emailaddress" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">[email protected]</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">foo</AttributeValue>
</Attribute>
</Attributes>
</Request>

As you can see  attribute values that is contains in the following  attributes element is matched with the attribute values that is defined by the <AttributeDesignator> . Basically category , attribute id and data type are matched with <AttributeDesignator> element.

<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">[email protected]</AttributeValue>
</Attribute>
</Attributes>

Therefore <AttributeDesignator> retrieves  attribute values from the XACML request for evaluating the  function “urn:oasis:names:tc:xacml:1.0:function:string-regexp-match” which is defined as the  function in rule element. Therefore PDP just have to perform the “string-regexp-match” function on these two attribute values [email protected]  (Which is XACML request) and “[0-9a-zA-Z]+@xacmlinfo.com” (Which is XACML policy).

OK,  now let assume following XACML request is send to PDP,

<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">bar</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">bob</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">foo</AttributeValue>
</Attribute>
</Attributes>
</Request>

Here you will notice that there are no any matching element to retrieve attribute values by the <AttributeDesignator> .  In XACML request, these is an element that matches the category. But not the attribute Id

In that case, PDP would look for available PIPs (Policy Information Points) and ask the help to resolve and attribute values.

PDP would send following details to PIP

  • Attribute designator

Basically content of the Attribute designator which was not able to find matching attribute values from the XACML request. In above sample,

category   —>   urn:oasis:names:tc:xacml:1.0:subject-category:access-subject

attribute id   —->  http://wso2.org/claims/emailaddress

data type  —->   http://www.w3.org/2001/XMLSchema#string

issuer  —->   null

  • XACML request

Implementation logic in PIP would know that PDP wants the resolve the  attribute Id.  And it is meant to be the email of the user.  (according to the XACML request user name is “bob”). Therefore PIP would contact external attribute source and find the email address of user. Email address of user “bob” would be returned from the PIP to the PDP

Therefore, finally PDP just have to perform the “string-regexp-match” function on these two attribute values “bob@xacmlinfo.com” and “[0-9a-zA-Z]+@xacmlinfo.com”.