OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Obligations rear their ugly head.



I just remember from very early on, that we did not want obligations to
mean "provided that" as far as access control goes. We have rules to
govern that access. Unfortunately, it seems that "provided that" (which is
a decision completely made by some other entity, which is what I don't
like) is what they have become.

I believe an obligation means that the PEP has an obligation to fulfill,
and that was up to the PEP or some delegated entity to get them fulfilled.
Remember the "must delete file in 30 days" scenario? You'd have to wait 30
days and delete the file even before you were allowed to read it!

I guess, I can get around saying my PEP understands "strings", and
therefore, all obligations, as they are just "strings" and "discharges"
all of them to the bit bucket.

Cheers,
-Polar


On Thu, 8 Apr 2004, Bill Parducci wrote:

> Polar Humenn wrote:
> > And that is a policy of the PEP. Not a mandate from the definition of a
> > PDP.
>
> if you do not have consistency of enforcement than consistency of policy makes
> little sense. since v1.0 of XACML an obligation has been an optional component
> of a decision, NOT an optional component of decision *enforcement*.
>
> > I agree with that approach. However, stating that a "PEP MUST Deny" when
> > it encounters an obligation is doesn't "understand", leads to a "provided
> > that" scenario, in the case of Permit. In Deny? well it doesn't mean much
> > does it.
>
> i think the real issue here is 'Deny' vs. 'DENY'. in reality what we have is an
> ERROR condition on the PEP. what i believe the text of the specification intends
> to say is 'access by subject to resource is not allowed because this is
> considered an error condition' (aka 'deny'). the applied effect is the same but
> i can see how there is concern that these 'shorthand' semantics are not clean.
>
> again, let's step back and look at the larger picture: an enforcement device is
> not allowed to take action without FULLY understanding its directives; 'non
> action' is generally considered a DENY, but i personally have no problem taking
> the extra step of having such a scenario more fully expanded so as to explicitly
> call this an ERROR condition leaving the [obvious?] conclusion that this will
> ultimately prevent the subject from access the resource.
>
> on the other hand, what i don't think is acceptable is the use of SHOULD in the
> specification since that has far reaching implications outside of the intended
> message because it reduces the *application* of obligations to optional status
> because, BY DEFINITION, obligations are a decision directive IF provided.
>
> > Obligations are not Access Control items.
>
> they are in XACML when issued as part of a decision.
>
> > Obligations should be things that need to be carried out by the PEP or its
> > delegates.  The definition in my mind is more like:
> >
> > If the PEP allows access on a Permit with Obligation X then it SHOULD
> > allow access and carry out Obligation X. If the PEP denies access on a
> > Deny with Obligation X, then it SHOULD deny access and carry out
> > Obligation X.
>
> fine, but the portion that is missing is: 'however, the PEP MUST understand the
> obligations as part of the consumption of the decision'.
>
> > which is what I thought we agreed on a long time ago, to avoid the
> > "provided that" syndrome.
>
> my recollection of this is that the decision came down to the concept that the
> PEP must have the intention of, and make every effort to, fulfill the obligation
> as part of implementing the decision. however, in order to do so it MUST
> understand what is being asked of it first.
>
> for example, if the obligation is 'permit, encrypt:3DES' and the PEP doesn't
> know what '3DES' is then, the PEP will deny access (in what is for all practical
> terms an ERROR condition). note that the *decision* has NOT be changed to DENY,
> rather the PEP has denied access based on it inability to understand the decision.
>
> > Obligations should not embody the contra positive of the above statement
> > which is "On a response of Permit with Obligation X, if the PEP can carry
> > out Obligation X then PEP allows Access, otherwise deny.
>
> fine. let's have the PEP throw ERROR then. syntactically more precise, but the
> result is exactly the same for the subject in any sane system.
>
> >>>Second of all, what if some IT administrator added a lower level XACML
> >>>policy with that obligation without regard for all of the PEPs that might
> >>>use that policy? And then the XACML v2.0 compliant PEP denies the request.
> >>
> >>what if the same administrator slapped on a combing algorithm on the sonogram
> >>policy that was unsolvable in the affirmative?
> >
> >
> > That is a different case. Aside from human error, this administrator
> > should know the result of its policy, which is completely self contained.
> > An obligation and "its understanding" is outside of that administrator's
> > realm (upward). He doesn't know how high that obligation will get lifted
> > and whether anybody above it understands it.
>
> just because a PDP treats an obligation as an opaque entity doesn't mean that
> the policy writer doesn't know what it means. at some point we must have a
> modicum of faith that policy writers understand what it is they are doing. can
> an obligation result in an unintended deny? sure, but the policy writer added it
> there for a reason and that intent MUST be honored in a reliable system. the
> alternative is that--using the example above--data goes out unencrypted without
> the knowledge that such is occurring. the sword of 'unintended consequences'
> cuts both ways.
>
> > Deterministic results are stated by saying given a particular request and
> > a particular policy you will always get an answer and it will be the same
> > answer.
>
> ...unless the PEP discards a portion of the decision (obligation), in which case
> the real world results will be in variance with the intention of the policy writer.
>
> > Which helps a person implementing a PEP for a particular application lay
> > trust down in the PDP that it does the right thing all the time. That is
> > determinism.
>
> if an enforcement point does not take into consideration ALL aspects of a
> decision, what you have is an applied crap shoot. unless the specification is
> changed to remove obligations as components of a decision (basically reduce them
> to notations) determinism requires that the PEP be able to consume them.
>
> if that is the position that you would like to follow then i think that we
> should entertain the discussion of redefining/removing obligations altogether.
> however, i do not think that it can be boiled to a simple modification of the
> current wording (at least without a discussion on the ramifications of such
> beforehand).
>
> b
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]