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

[Oleg Gryb <oleg_gryb@yahoo.com>]

Yoichi,

It looks like your understanding of obligations differs from mine because you think:

1. That obligations make sense only for "Permit" decisions
2. That the final decision always depends on fulfilling obligations by PEP if obligations are sent by PDP

I think that the first statement above is not correct for XACML 2.0 because there is FulfillOn attribute in XACML 2.0 <Obligation> element. Why would we need it if Obligations are valid for "Permit" only?

I think that the second statement is not valid either because Seth wrote that my exampple with "show-deny-reason" obligation is compliant with XACML model and fulfilling that obligation is not going to affect the final decision according to the logic that I've implemented.

I would agree though that in your Use Case with "sign up agreement" obligation final decision does depend on the successful fulfillment of obligation and this is compliant with XACML 2.0's non-normative section 2, which says that if PEP doesn't understand or can't fulfill the obligation the access should be denied.

I didn't find anything that would tell me what should happen if on-deny obligation is not understood or can't be fulfilled. I think it would be logical to make an assumption that on-deny obligation can't affect the final decision. It means that unlike on-permit obligation it is "informative" rather than "assertive".

TC, it would be great if somebody could confirm that my assumption is correct. If it's not, it would be great if you provide a Use Case where on-deny obligations can change a final decision.

I think this fundamental difference between "assertive" on-permit obligations and "informative" on-deny obligations is the very same difference that Bill was writing about and that's why it probably makes perfect sense to divide these two types of obligations syntactically. The "Message" element looks good enough to me when it comes to "informative" obligations.


--- On Fri, 12/12/08, Yoichi Takayama <yoichi@melcoe.mq.edu.au> wrote:

> From: Yoichi Takayama <yoichi@melcoe.mq.edu.au>
> Subject: Re: [xacml-users] Help on Condition ? <-- Obligations
> To: oleg@gryb.info
> Cc: "Bill Parducci" <bill@parducci.net>, "Tyson, Paul H" <PTyson@bellhelicopter.textron.com>, xacml-users@lists.oasis-open.org
> Date: Friday, December 12, 2008, 7:48 PM
> Hi Oleg,
> 
> I think that you may be getting it wrong. (Or, I am wrong
> that is totally possible).
> 
> PDP has made the Permit or Deny decision already.
> 
> Obligation does not change the Decision on PEP which has
> got the reply from the PDP. Policy Decision is PDP matter on
> the server side, the Obligation is PEP matter on the user
> side, so to speak. (Although Bill suggests that now Rules
> may wrap around Obligations more rightly, that may
> invalidate this statement in terms of Obligation involvement
> in PDP??).
> 
> To me it makes sense that it only determines whether it
> FulFills the Decision (of Permit) or not. If the user
> Obliges, the Permit takes effect. If the user declines the
> Obligation (or negative conditions for FullFill are met),
> the Permit is not FullFiled.
> 
> For Deny, nothing should happen. There is no Obligation if
> the Decision was Denied, since there is no Action to be
> taken. Is this changed in 2.0 or 3.0?
> 
> If someone Obliges to the Denied Policy Decision, are you
> going to overturn the Policy Decision to Permit? What
> justification is there unless you already considered such
> conditions in the Policy Decision making? (Of course,
> denying some Action itself is some sort of Action logically
> or philosophically, but I think that that does not apply in
> this case).
> 
> By definition, Denied means there is no Action to be taken
> by the end user. Therefore, there is no question about a
> further Obligation.
> 
> Can someone clarify because of the philosophical no-action
> is an action?
> 
> Also, if your business logic is to deny the Action (such as
> buying something) if the user account exceeds and requires
> the user to sign extension agreement, IMO, shouldn't you
> be doing it as a part of the Rule, rather than in
> Obligation? It can be a part of Policy Set. That should make
> more sense.
> 
> As I understand it, the Policy is primarily to allow or
> deny (authorization cross-cutting concern), not to demand
> users to do something. Obligation is a part of it and it is
> to do with authorization. The User License Agreement Use
> Case is an additional authorization, but in this case,
> user-determined authorization condition.
> 
> The original Action carried out is still the same. But, in
> your use case, the original Action is expanded to increase
> the account limit.
> 
> I think that there should be some Policy or application
> logic you should ask before (e.g. Is enough of my account
> limit left to buy more?), that may make the application to
> ask the user to increase the account limit first before the
> user can buy something more.
> 
> I think that the Obligation is a bit of black sheep that it
> may demand something of the user or the application, but I
> take it from the "authorization" point of view,
> not application Action or logic point of view.
> 
> 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 4:03 PM, Oleg Gryb wrote:
> 
> >> Also, please note that Oracle, for example, states
> that
> >> Obligation is only triggered if the Decision was
> Permit.
> > 
> > I think, it's a weak argument. It could mean only
> that Oracle implementation is not compliant with XACML 2.0:
> > 
> > "FulfillOn [Required]
> > The effect for which this obligation must be fulfilled
> by the PEP."
> > 
> > There are other implementations though that do support
> the spec in this area.
> > 
> >> 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.
> > 
> > Yes, after "permit" decision is made it
> would not have any sense, but it does have perfect sense for
> "deny" - I don't know what else I could use
> from XACML 2.0 stack to achieve my business goals.
> > 
> >> 
> >> 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).
> > 
> > Not necessary. Consider the following scenario:
> > 
> > 1. PEP fulfilled the obligation of presenting the deny
> reason and a new agreement to the user
> > 2. User has signed the new agreement
> > 3. PEP created a new modified request to PDP by
> incorporating the fact that the new agreement has been
> signed
> > 4. PDP returned "Permit" for the new request
> > 5. The user got access to the service
> > 
> > The initial decision has not been changed, but
> additional information entered by the user has been used by
> PEP to create a new request and for the user it will look
> like the decision has been changed.
> > 
> >> 
> >> As Bill was saying, "message" seems to
> be more
> >> appropriate place.
> > 
> > Yes,  I think we need to separate a "quantified
> explicit action", and an "abstract informal
> message" that can be anything including an expression.
> The qs that remains is "where to put the
> message"...
> > 
> >> 
> >> 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
> >>> 
> > 
> > 
> >