Additional PDP Decision information in a response

[TJXACML]

hi!
   I was wondering if there are any plans to provide greater detail in a response as to which rule and/or policy was the "cause" of the permit/deny response? (Sorry if this is accessible...can't find it in my searches 

This is not a debugging issue but I was think of using this to provide some high level detail for logging.

thanks...just an inquiry.

TJ

[René Eggenschwiler]

Hi TJ

Thanks for your interest.

Yes we have plans to add more information about causes of decisions.
Unfortunately XACML 2.0 doesn't specify any information like parts in the response. So there's no standard way of delivering the cause info to the PEP.

Our solution will use obligations to transport the info messages. We will introduce an "info-obligation" which will have the cause in it.

But to be honest. Our planning doesn't specify a concrete deadline. At the moment this is more a foreseen feature than a concrete development plan.
So it will most probably not be realized by us during the next half year.

If you like to introduce that feature and develop it , we would be very interested to discuss this with you.

Maybe you can tell us a bit more about your context, project and plans....

Regards,
René

[TJXACML]

hi René
   thanks for the rapid response on this.

Your solution is interesting because it mirrors what I am doing already in that I know the policy (within the set) and what I would really like to know is which rule in the policy.

To give you feed back (and encouragement) it is possible to provide some good high level information about why a decision was made...I am particularly interested in giving user feed back...but currently the approach dictates that I keep the policy documents very short with few rules  in order to make the detail in an information obligation detailed to be useful. It would be good to have the rule name (because my rule URNs have comments associated that I can then use in my documentation.)

TJ

[René Eggenschwiler]

Hi TJ,

I think you cann do a small change/extension to our code and it will behave like described in your case.

We have the EvaluationContext which is ported through the whole evaluation process.
He is responsible for holding the obligations which are found during the evaluation.
See: http://dev.herasaf.org/source/browse/XACMLCORE/trunk/src/main/java/org/herasaf/xacml/core/context/EvaluationContext.java?r=HEAD

So here is my suggestion. Add your own RuleCombiningAlgorithms or overwrite ours.
Then there you have access to the rules during evaluation.
Have a look at: http://dev.herasaf.org/source/browse/XACMLCORE/trunk/src/main/java/org/herasaf/xacml/core/combiningAlgorithm/rule/impl/RuleDenyOverridesAlgorithm.java?r=HEAD#l125
That is our RuleDenyOverridesAlgorithm. You can see there from line 115 to 179 how we deal with the rules.

I think that's the point where you should hook in.
There you could just create a new obligation and add it to the EvaluationContext.

Below I posted some pseudo code.

Code:

ObligationType yourNewObligation = new ObligationType();
yourNewObligation.setId("your:urn");
yourNewObligation.set.....;
evaluationContext.getObligations().getObligations().add(yourNewObligation);

ObligationsType: http://dev.herasaf.org/source/browse/XACMLCORE/trunk/src/main/java/org/herasaf/xacml/core/policy/impl/ObligationsType.java?r=HEAD
ObligationType: http://dev.herasaf.org/source/browse/XACMLCORE/trunk/src/main/java/org/herasaf/xacml/core/policy/impl/ObligationType.java?r=HEAD

I hope that helps or gives you a hint. Maybe you can have a try and tell us how it's working.

If you have further questions just post again. Feel free to discuss your implementation ideas with us.

Regards,
René

[Florian Huonder]

Hi TJ,

I added an issue for this feature to our JIRA http://dev.herasaf.org/browse/XACMLCORE-171.
Do not hesitate to attach your source code (e.g. in patch-form) to the issue.
We defenitly will have a look at it.

Thanks a lot for your input.

Regards,
Florian