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

(A) FullfilOn

I was wrong. In XACML 2.0, the Obligations can be attached with Deny. I think that the Oracle example is perhaps based on XACML 1.0 or 1.1.

Bill, http://projectconcordia.org/images/d/d6/BoeingFineGrainedAuthorization.pdf does not tell me how exactly the Export Licensing is thought with the Obligations. Does the Obligation exports some License Information of a Resource described in XACML Request from PDP to PEP? What "Action" do they need (you were saying that they need "Actions"?)?

The XACML 2.0 defines: (http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf)

----------------------------------------------------------------------------------------------------------------------------------

3223 7.1.1. Base PEP

3224 If the decision is "Permit", then the PEP SHALL permit access. If obligations accompany the

3225 decision, then the PEP SHALL permit access only if it understands and it can and will discharge

3226 those obligations.

3227 If the decision is "Deny", then the PEP SHALL deny access. If obligations accompany the

3228 decision, then the PEP shall deny access only if it understands, and it can and will discharge

3229 those obligations.

3230 If the decision is “Not Applicable”, then the PEP’s behavior is undefined.

3231 If the decision is “Indeterminate”, then the PEP’s behavior is undefined.

3232 7.1.2. Deny-biased PEP

3233 If the decision is "Permit", then the PEP SHALL permit access. If obligations accompany the

3234 decision, then the PEP SHALL permit access only if it understands and it can and will discharge

3235 those obligations.

3236 All other decisions SHALL result in the denial of access.

3237 Note: other actions, e.g. consultation of additional PDPs, reformulation/resubmission of the

3238 decision request, etc., are not prohibited.

3239 7.1.3. Permit-biased PEP

3240 If the decision is "Deny", then the PEP SHALL deny access. If obligations accompany the

3241 decision, then the PEP shall deny access only if it understands, and it can and will discharge

3242 those obligations.

3243 All other decisions SHALL result in the permission of access.

3244 Note: other actions, e.g. consultation of additional PDPs, reformulation/resubmission of the

3245 decision request, etc., are not prohibited.

----------------------------------------------------------------------------------------------------------------------------------

I think that, these mean as follows:

(Pseudo code for Permit-based PEP as an example)

(1) Accepting Undefined

(At PEP)

decision= PDP.decide(Request)

IF decision=Decision.DENY THEN

IF Obligation.defined() THEN

IF Obligation.understood() & Obligation.discharged() THEN

Action.deny()

ELSE

{not_defined}

ELSE

Action.deny()

ELSE {all_other_decisions}

Action.execute()

{regardless_of_obligation}

But not as below:

(2) Assuming the Undefined becomes opposite of Deny (Permit)

E.g. (Permit-biased)

decision= PDP.decide(Request)

IF decision=Decision.DENY THEN

Action.deny()

ELSE IF decision=Decision.DENY & Obligation.defined() & Obligation.understood() & Obligation.discharged() THEN

Action.deny()

ELSE {all_other_decisions}

Action.execute()

{regardless_of_obligation}

In (1), as Oleg was saying, the behaviour of PEP is undefined if the PEP does not have an ability to deal with Obligation or does not understand any particular Obligation, or user has declined.

Probably that is what the PDF really intend?

In that case, regardless of Decision, the unsatisfactory Obligation does not become Permit. Although the error or inaction is the same as Deny as far as the Action is concerned, the PEP may report differently to the end user, to PDP or to the originator of the Request. (To whom the PEP reports the error or inability?)

In (2), the results will be the overturned Decision, and, IMO, it seems to make the Policy composition more complicated. Particularly if the Policy store must be backward compatible with XACML 1.0 or 1.1. I don't think that this is the case.

(B) Rethinking the Application Action logics and the Policy structure

For Oleg's Use Case:

1. Decision is Deny

2. Obligation requires the PEP to explain that the cause-for-deny and to ask the user to increase the purchase limit.

If the PEP can comply, the user is obliged to agree with increment of the spending limit, that results in Deny. Although this may increase the user limit and next time the Action may proceed, I can't see that it may lead to Permit of the original Decision in one step (in one Request-PDP-PEP cycle). Also, if the user declines, the result is in-action (i.e, Deny is not enforced but the Action does not take place, either).

???

Should the Decision be Permit but, in that case, the Rule may be using the account limit and may have to result in Deny really. That conflicts.

IMO, perhaps the spending limit should be used in a Rule not Obligation. Also, such messages as to why Deny or Permit was the Decision should be wrapped with Rules not Obligation (unless Obligations are in Rules as well) as Bill was saying.

Also, as I said before, the user does not seem to have any necessity to accept the obligation tied with this particular instance of this Decision for this Action. For example, "Agree with this license terms and conditions?" has no other place to sign with the agreement but in this Obligation for this Permission for this Action. You may not agree with a blanket "Yes" for such elsewhere.

To agree with bumping up the spending limit can be done elsewhere and another time in the application, separate from this particular instance of Permission for the Action that should be decided now whether to proceed or not. In case of the purchase, the user can increase the limit anytime and elsewhere and re-issue the purchase order Action again. The user can agree to (if he/she has to) the new Obligation (e.g. terms and conditions of the sale perhaps) of the new Action to proceed.

Can you see the difference?

To check the account spending limit seems to be an application logic than a Policy logic. Although the limit amount for the customer could be a Policy matter, perhaps the Policy queries should be divided into smaller step-wise pieces, and e.g. the account spending limit + purchase balance should be checked explicitly so that the application can feed back to indicate that there is not enough funding, rather than resort to the Obligation?

This is just my opinion about the use of Obligation.

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 13/12/2008, at 2:18 PM, bill parducci wrote:

1. Obligations may be generated for Denies (e.g. Deny + log) - as you can imagine, the inability to normatively combine Obligations makes this... Interesting :)

2. A PEP that supports Obligations is supposed to behave differently if it receives an Obligation that it doesn't understand or knows that it cannot fulfill. What is "different"? Well it depends upon the PEP's bias, but regardless of the action it takes an error should be generated.

That is my understanding.

b

xacml-users message