Re: [xacml-users] Help on Condition ? <-- Obligations

[Yoichi Takayama <yoichi@melcoe.mq.edu.au>]

I think that I agree with Bill.

On 12/12/2008, at 9:47 AM, Oleg Gryb wrote:
>

> consider adding expressions to obligations as I and other
> people had suggested in the past. It would make the
> obligations more dynamic. Example: I want to return an error
> message: "The access to the bill pay service has been
> denied because you exceeded the total maximum of $10000 in
> 6-month period" where $10000 and 6-month are
> environment attributes.

Also, please note that Oracle, for example, states that Obligation is  
only triggered if the Decision was Permit. How is it in XACML 3.0?

It is not triggered if the Decision was Denied, as your Use Case. It  
can express Obligations that may results in a further Permit or Deny,  
depending on whether and what Obligation(s) was/were meet or not. (You  
can have a few Obligation clauses).

Also, I think that the use of user account balance (or using user Role  
in Oracle Use Case) AFTER the Permit Decision is made by the Policies  
as Obligation is not appropriate.

They are not related ONLY with this particular Policy Permit Decision,  
as a very specific Post-Condition to be met. They are the conditions  
already exist BEFORE the policy decision Permit was made. So, if you  
have not used those conditions for making Policy Decisions, what the  
Policies are about is not clear. The Obligation is an additional  
Action (that Paul Tyson was referring?), which occurs only AFTER the  
Policy Decision and it is required ONLY for that particular instance.  
Can you see that the attribute "Do you agree to this license  
agreement" did not exist before in any attributes before?

In my opinion, the account balance or Role is an application logic and  
it has to be determined with your application or the Policy Decision  
BEFORE Obligation.


On 12/12/2008, at 12:03 PM, Oleg Gryb wrote:
> The difference between "action" and "information/advice" elements  
> still look vague to me. Adding Obligations to a Rule is something  
> that I would like to see too. I had to wrap each rule to a policy in  
> the past because rule-level obligations were not available.


As I said, of course, it is totally legitimate to make Obligation to  
make it present the cause-for-deny (as I said, Oracle XACML PEP never  
does this because the Decision was Deny), but what PEP does is to ask  
the user whether user WILL oblige a condition.

What the condition can be? That must be enforceable with PEP.

One example may be: "Your Action was denied because of .... Do you  
oblige to increase the limit?" I imagine that it is impossible to  
reduce the spending (?) less than $10000 in 6-month period, that has  
already incurred. As Bill (?) was saying that this brings in the  
application logic to be performed inside the XACML (changing the value  
of Attributes within), and I think that it is not an appropriate place.

Simply the Obligation asking to "oblige" to have read the failure  
message is not that meaningful in this case as the Action. Regardless  
whether the user agreed that he has read it or not, it has been  
already presented and the Decision does not change by whether the user  
has agreed or not. Also, if you mean that PEP MUST oblige to present  
it, it is not the Obligation of the user. I don't think that there is  
a mechanism for that (as it must still ask the user to agree that he  
has read it).

As Bill was saying, "message" seems to be more appropriate place.

Yoichi



--------------------------------------------------------------------------
Yoichi Takayama, PhD
Senior Research Fellow
RAMP Project
MELCOE (Macquarie E-Learning Centre of Excellence)
MACQUARIE UNIVERSITY

Phone: +61 (0)2 9850 9073
Fax: +61 (0)2 9850 6527
www.mq.edu.au
www.melcoe.mq.edu.au/projects/RAMP/
--------------------------------------------------------------------------
MACQUARIE UNIVERSITY: CRICOS Provider No 00002J

This message is intended for the addressee named and may contain  
confidential information.  If you are not the intended recipient,  
please delete it and notify the sender. Views expressed in this  
message are those of the individual sender, and are not necessarily  
the views of Macquarie E-Learning Centre Of Excellence (MELCOE) or  
Macquarie University.

On 12/12/2008, at 1:12 PM, Bill Parducci wrote:

>
> On Dec 12, 2008, at 12:26 PM, Tyson, Paul H wrote:
>> Isn't "Cause" already addressed by PolicyIdentifierList?  I can see  
>> two
>> other plausible instantiations of "Cause": 1) a natural-language
>> explanation for each rule; or 2) a reproduction of the logical schema
>> that implied the decision.  Either of these might be useful while
>> developing or debugging a XACML system, but are there good use  
>> cases for
>> a production system?  What would you want a PEP to do differently  
>> (with
>> respect to enforcement) if the decision came from Rule1 or from  
>> Rule2?
>
> The Use Cases that spurred the [re]investigation of this  
> functionality were reviewed with the TC as noted here (from the  
> 12/4/08 TC minutes):
>
> Mike Beach from Boeing reviewed his authz Use Cases
>  http://projectconcordia.org/images/d/d6/BoeingFineGrainedAuthorization.pdf
>  (starting at slide 8)
>  The basis of the talk is the ability of XACML to deal with export
>  licensing using Obligations or is additional machinery needed?
>
>> We have a use case that will require logging of certain decisions.   
>> We
>> could get by with logging just certain decisions (e.g. "Permit"
>> decisions from a certain policy), but at this point it does not  
>> appear
>> to be a problem to log all decisions.  Technically, we can't use
>> "Obligation" for this because it has no bearing on whether the  
>> resource
>> is shown to the user or not.  (That is, if for some reason the  
>> logging
>> failed, we wouldn't deny access to the resource.)
>>
>> I suggest "Message" instead of "Advice", because "Advice" implies at
>> least a small component of intended behavior for the PEP, and that
>> behavior is outside the scope of XACML.  "Message", on the other  
>> hand,
>> is neutral with respect to expected behavior.  It would meet  
>> everyone's
>> needs if Message could contain expressions to be evaluated within the
>> decision context, as well as foreign namespace elements to describe
>> anything else the policy writer wants the PDP to communicate to the  
>> PEP.
>> That would allow implementors to use application-specific contracts
>> between PDPs and PEPs without mucking up the XACML model.
>
> Works for me. We can call it FYI for all I care so long as the spec  
> is explicit in what it is used for (refreshingly in this case there  
> is absolutely no issue with combination beyond blind aggregation :)
>
> thanks
>
> b
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
>

smime.p7s