How to implement Reference Loading

[d95776]

If Heras simple policy repository does not support PolicySetIdReference and PolicyIdReference, we need to write our own policy repository mechanism. My question is where we should start by using your API, e.g. do you have some kind policy finder interface such that we can implement? If not, looks like we need to write our own PDP that will extends your PDP. Then we need to know in your code where's the policy is parsed and when it sees PolicySetIdReference and PolicyIdReference how your api reacts to them. Basically, we need to know when our policy repository should get involved and how.

[Florian Huonder]

Hi,

The capabilities of the simple policy repository are described in the Javadoc and here http://dev.herasaf.org/wiki/display/XACMLCORE/Policy+Repository.

If you woud like to have a PDP that is capable of handling remote references then you have to implement that on your own because we do not provide an implementation yet.
We already made some thoughts about reference loading, these are written down here: http://dev.herasaf.org/browse/XACMLCORE-133

There are three possibilities of loading remote references

• Lazy: The references are resolved when the PDP reaches a reference during evaluation. This is the fastest method. This method may lead to inconsistencies.
• Semi-Lazy: The references are resolved when the PDP retrieves the set of policies that is contained in a Policy Set when one or more of these are references. This method is fast. This method may lead to inconsitencies.
• Eager: The references are resolved when the evaluation starts. This method is the slowest. This method cannot lead to inconsitencies.

It depends on your use case which of these three methods fits best. The Eager-solution can be implemented in the policy repository. The Lazy-versions both require some enhancements to the evaluation code. Where these extensions must be made can be seen in the printscreen that is attached to the issue.
It is imaginable that there is a mix-method where it is configurable on the policies for which references which method shall be applied.

I hope I was able to help you.

Best regards,
Florian

[d95776]

lazy way is kind of way I would like to pick. The questions regarding it are
1. What do you mean by inconsistencies?
2. Where is the code of evaluation process needed to be changed in your API. I just need you tell me the entry point. Then I can fo

[Florian Huonder]

Hi d95776,

Inconsistencies
Inconsitencies can occure when the references are loaded lazily.
Imaging the following scenario.

PDP A has deployed a set of policies a.
PDP B has deployed a set of policies b.

a contains references to policies in b.
Consider now that the evaluation on PDP A (with the policies in a) starts.
The at time x the first reference is resolved from b. At time x+1 a deployment is performed on PDP B that transforms the policies b to b'.
At time x+2 PDP A fetches another policy from PDP B. This new policy is then from set b' and not b.

Changes to the code for lazy loading
A proposal of how to implement lazy loading is described here http://dev.herasaf.org/browse/XACMLCORE-133 (see comment from 28. April 2011).
I strongly recommend that you do not change the HERAS-AF code. HERAS-AF is a very extensible framwork and this change could be implemented with writing a custom PDP implementation that enriches the evaluation context and custom combinin algorithms.


Best regards,
Florian

[d95776]

Each our PDP has its own local policy repository. So the inconsistency will not happen.
At least, we need to change your IdReferenceType implementation, am I right?

[René Eggenschwiler]

Hi,

I would try to extend our IdReferenceType with your CustomIdReferenceType.
In your CustomIdReferenceType you could then override the methods: getCombiningAlg(), getTarget(), getEvalutableVersion() and getContainedObligations().
Those methods have to return the CombinigAlg, Target, EvaluatableVersion and ContainedObligations from the referenced Policy.

Then wire up your CustomIdReferenceType so that JAXB will use your type instead of our IdReferenceType for marshalling and unmarshalling.

Hint: I suggest that your CustomIdReferenceType should ask your PolicyRepository for retrieval of the referenced policy.

I think if you implement it like that, then it's not needed to change any of our code.

Regards,
René

[d95776]

The xacml schema defines IdReferenceType as
   <xs:complexType name="IdReferenceType">
      <xs:simpleContent>
         <xs:extension base="xs:anyURI">
            <xs:attribute name="Version" type="xacml:VersionMatchType" use="optional"/>
            <xs:attribute name="EarliestVersion" type="xacml:VersionMatchType" use="optional"/>
            <xs:attribute name="LatestVersion" type="xacml:VersionMatchType" use="optional"/>
         </xs:extension>
      </xs:simpleContent>
   </xs:complexType>

Why does your implementation of it extends to Evaluatable? It is not necessary to be Evaluatable.

[Florian Huonder]

Hi,

Evaluatable is a HERAS-AF specific interface that declares an implementing class as "it can be evaluated".
Policies and PolicySets implement it. The IdReferenceType as well.

The reason is that the combining algorithms must not care.
The IdReferenceType itself is responsible of handling the resolution of the remote policy and returning the proper thing to the calling combining algorithm.

Regards,
Florian

[Florian Huonder]

Addition:

The  <xs:complexType name="IdReferenceType"> is only the base-type of
<xs:element name="PolicySetIdReference" type="xacml:IdReferenceType"/>
and
<xs:element name="PolicyIdReference" type="xacml:IdReferenceType"/>

[d95776]

IdReferenceType is the data type. PolicySetIdReference & PolicyIdReference are the elements of this type. There's only one reference type defined in xacml.

[Florian Huonder]

Hi,

Yes you are right, but this has no influence on my statement regarding why it implements Evaluatable.

Regards,
Florian

[d95776]

For your comment "Then wire up your CustomIdReferenceType so that JAXB will use your type instead of our IdReferenceType for marshalling and unmarshalling."

I need to your help to understand this more. I see 3 methods related to this in ObjectFactory class:
createIdReferenceType
createPolicyIdReference
createPolicySetIdReference

Are those 3 methods the only things I need to change to CustomIdReferenceType for jaxb wiring?

[d95776]

For your comment "this has no influence on my statement regarding why it implements Evaluatable."

The thing I tried to figure is what I should do when I implement methods  getCombiningAlg(), getTarget(), getEvalutableVersion() and getContainedObligations().
However, IdReferenceType is not PolicyType and PolicySetType. But when I look into your code there are many places in the evaluation process where executable is directly cast into PolicySet. I guess even I extend IdReferenceType to CustomReferenceType, I will still get the Cast exception. I wonder if it is possible to properly implement those methods.

[Florian Huonder]

Hi,
This is a feature that is currently not documented. I will come back to you until Monday with a small example.

Then I am going to give you also an explanation regarding the Evaluatable stuff.

Have a nice weekend.
Florian

[Florian Huonder]

Hi,

First of all, for the example I am going to need some more time. Pardon me.

Yes there are direct casts into PolicyType or PolicySetType. The reason is that the idea is that the references are replaced for the evaluation after they are resolved.
Making reference resolving the "lazy way" is not that easy due to the fact that issue http://dev.herasaf.org/browse/XACMLCORE-133 is not yet solved. This issue will introduce some API to hook into.

I will come back to you.

Best regards,
Florian