XACML for Authorization

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

<Policy PolicyId="TestPolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
 <Target>
 <Resources>
 <Resource>
 <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">foo</AttributeValue>
 <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
 </ResourceMatch>
 </Resource>
 </Resources>
 <Actions>
 <Action>
 <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">bar</AttributeValue>
 <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
 </ActionMatch>
 </Action>
 </Actions>
 </Target>
 <Rule Effect="Permit" RuleId="PermitRule">
 <Target>
 <Subjects>
 <Subject>
 <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">[0-9a-zA-Z]+@wso2.com</AttributeValue>
 <SubjectAttributeDesignator AttributeId="http://wso2.org/claims/emailaddress" DataType="http://www.w3.org/2001/XMLSchema#string"/>
 </SubjectMatch>
 </Subject>
 </Subjects>
 </Target>
 </Rule>
 <Rule Effect="Deny" RuleId="DenyRule"/>
</Policy>

in this policy, we are interested in following element now

<SubjectAttributeDesignator AttributeId="http://wso2.org/claims/emailaddress" DataType="http://www.w3.org/2001/XMLSchema#string"/>

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

In XACML you can see, there are four types of AttributeDesignator element,

SubjectAttributeDesignator, ResourceAttributeDesignator, ActionAttributeDesignator and EnvironmentAttributeDesignator

AttributeDesignator element is defined to extract the matching attribute from the XACML request

Therefore <SubjectAttributeDesignator> retrieves the matching <Subject> element from the XACML requests.

AttributeDesignator finds matching attributes based following criteria

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

If there are any matching attributes in the XACML request would returns as a Bag, (Actually a collection of attribute values)
Assume that following XACML request is send to PDP,

<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>foo</AttributeValue>
</Attribute>
</Resource>
<Subject/>
<Action>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>bar</AttributeValue>
</Attribute>
</Action>
<Environment/>
<Subject>
<Attribute AttributeId="http://wso2.org/claims/emailaddress" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>bob@wso2.com</AttributeValue>
</Attribute>
</Subject>
</Request>

As you can see following <Subject> attribute is matched with the attributes that is defined by the <SubjectAttributeDesignator> . Basically attribute id and data type are matched.

Therefore <SubjectAttributeDesignator> retrieves this attribute from the XACML request for evaluating the matching function “urn:oasis:names:tc:xacml:1.0:function:string-regexp-match” which is defined as the MatchId of the SubjectMatch element.
Therefore PDP just have to perform the “string-regexp-match” function on these two attribute values “bob@wso2.com” and “[0-9a-zA-Z]+@wso2.com”

But now we think that following XACML request is send to PDP,

<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>foo</AttributeValue>
</Attribute>
</Resource>
<Subject>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>bob</AttributeValue>
</Attribute>
</Subject>
<Action>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>bar</AttributeValue>
</Attribute>
</Action>
<Environment/>
</Request>

Here you will notice that there are no any matching element to retrieve by the <SubjectAttributeDesignator> . Although these is a subject element, it has different attribute id than that is in <SubjectAttributeDesignator> element

In that case, PDP would look for available PIPs and ask from them to find a matching attribute…

PDP would send following details to PIP

1. attribute designator   —> subject  attribute designator

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

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

4. issuer  —->   null

5. Subject Attribute value in request  —> bob

Implementation logic in PIP would know that PDP wants the email of the user Bob. Therefore PIP would contact external attribute source and find the email address of it. 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@wso2.com” and “[0-9a-zA-Z]+@wso2.com”.