Overview on the behavior of a PDP that has been made aware of an Attribute Provider

[OneWorld123]

Hi Cyril,

thanks for replying my question at https://stackoverflow.com/questions/50388935/where-to-double-check-attributes-of-the-xacml-request-against-attribute-provider. You have linked that wiki article in your answer at Stackoverflow: https://github.com/authzforce/core/wiki/Attribute-Providers

This project has a solid base and probably received several thousand hours of work. But as the features and possibilities are so huge, it's hard to access your tremendous work and to get an overview on how it works and on how to put things together.

As for your wiki page of Attribute Providers I'd kindly ask you to elaborate the overview a bit more.

• How exactly does the PDP take use of the Attribute Provider he is made aware of?
• In which situation does the PDP query the Attribute Provider for additional attributes?
  -- Does he double check attributes given in a Request?
  -- Does he check the attributes only if certain parameters in the xacml-policy are set?

Maybe a data flow chart or just a textual description on the data flow would be useful. Example code (JAVA and XACML) could also be useful.

[cdanger]

Initialization

The PDP is initialized with attribute providers based on the 'attributeProvider' elements in the PDP (XML) configuration, if there is any. (You can also do it programmatically if you really need to, but it is rather for more advanced users.) As the XML schema says, there may be zero, one or many of these. Indeed, using Attribute Providers is not mandatory. They are unnecessary if you expect all attributes to be provided in the requests (from PEP), or computed directly by the PDP like the current date/time as I mention in the next paragraph.

There is a special case for the standard current date/time attributes (§10.2.5 of XACML spec):

• If and only if the PDP configuration has the standardEnvAttributeSource set to PDP_ONLY, the PDP will always provide the current date/time attributes on its own (internally) for each request.
• If set to REQUEST_ELSE_PDP, same thing but only if the attribute is not present in the request.
• Else the PDP never provides it on its own.

Attribute providers implement Java interface CloseableNamedAttributeProvider; and during initialization, the PDP constructor calls method getProvidedAttributes() (defined by superinterface NamedAttributeProvider) on each one, in order to know which attributes it supports / can provide. Therefore, at the end of initialization, the PDP knows which attribute provider to call depending on the attribute it needs. (This avoids looping over all of them every time until it finds the good one.)

Request evaluation

After the PDP is initialized, it is ready to handle xacml requests.
For each request, the PDP initializes a request context (represented by Java class EvaluationContext) and puts in it all request attributes, and the current date/time attributes if necessary, depending on the standardEnvAttributeSource configuration parameter mentioned previously, and whether these attributes are in the request already. Then begins the evaluation of the request against the policy (XACML Policy or PolicySet). During the evaluation, the PDP will query Attribute Providers - calling their method get (...) in the following cases:

1. The PDP comes upon an AttributeDesignator and cannot find a matching attribute in the current request context.
2. The PDP comes upon an AttributeSelector with a ContextSelectorId and cannot find a matching attribute in the current request context.
3. An attribute provider is being called but requires/depends on another attribute X to proceed, and X cannot be found in the current request context. This is the edge case. For example, the PDP is calling an Attribute Provider to get the subject role attribute. But this Attribute Provider needs the subject ID attribute in order to find the subject role. However, there is no subject ID in the request context (again, this is an edge case just for example). Therefore it calls another Attribute Provider that can provide the subject ID based on the MAC address attribute (assuming there is a one-to-one relationship between the two), and this time the MAC address happens to be in the request context. All's well that ends well.

In all cases, the new attribute (category, ID...) is added to the request context with the result returned by AttributeProvider#get(...) as value, so that it can be retrieved from there directly if needed again.

[OneWorld123]

Thank you for the excellent answer! Now, I can go further with my design of the system. You could use parts of your answer to enrich your wiki article of this github repo.