WSO2 Identity Server – How to write a XACML Policy for an Extended PIP

Question

A PIP extension code using a "RedAttributeFinder" class is working now. It correctly register its claims into the WSO2 PDP extension console display.

I start to create a XACML policy now, addressing the field that returns the dynamic data value delivered by the extension program (for example a field named "http://w3.red.com/subject/employeeCountryCode").

The key field for a data look-up is: urn:oasis:names:tc:xacml:1.0:resource:resource-id , which maps a user identity in an email format.

Question 1: How is invocation of the “getAttributesValues” method done at the "RedAttributeFinder" class, registered at the start of WSO2. What triggers the call of the method from the PDP process (or its incoming requests)?

In the sample code, as well as at my implementation, the key field is the resource-id which is loaded as part of the PEP request implementation.

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

This is the key input for the "getAttributesValues()" and will return a country code (similar to the role [blue, silver, gold] definition in the WSO2 example code [ available here https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.samples.entitlement.pip/ ] .

In the sample, I see that the required resolution of roles value, for example "blue" is part of the Policy target definition.

Question 2: Is this placement inside target section a requirement to call the dynamic PIP look-up, one per requests, or can it also be placed at other parts of the policy, like for example inside a rule?

I was able to test the PEP to PDP interaction with a rule definition, only by defining static variables, receiving "permit", a rule that I would like to change to the dynamic data obtained from the PIP implementation and its extension, addressing the new fields added by the code.

David Brossard David Brossard · Accepted Answer · 2015-09-25T14:10:04

In a standard implementation that complies with the XACML standard, the PDP will invoke the PIP any time it finds an attribute designator in its policies that is also published by the PIP (it means the PIP must advertise which attributes it can provide e.g. it provides role, citizenship...).

The PDP could choose not to call a PIP and to use an attribute cache instead. The placement of the attribute in the policy is irrelevant. Whether the attribute is used inside a target or a condition should not matter - according to spec at least - and that is how the Axiomatics, SunXACML, and ATT engines all work.

Cheers, David.

WSO2 Identity Server – How to write a XACML Policy for an Extended PIP

2 Answers