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: [Re: [xacml] obligations & error conditions] - PROPOSAL


On Wed, 14 Apr 2004, Bill Parducci wrote:

> line 3130:
> A PEP SHALL allow access to the resource only if a valid XACML response
> of "Permit" is returned by the PDP.  The PEP SHALL deny access to the
> resource in all other cases.  An XACML response of "Permit" SHALL be
> considered valid only if the PEP understands and can and will discharge
> all of the obligations contained in the response.  An XACML response of
> "Deny" may also be accompanied by obligations.  In this case, if the PEP
> understands the and can discharge the obligations it MUST deny access and
> make best efforts to discharge the obligations; otherwise the PEP MUST
> treat the decision by the PDP as an ERROR.

This still doesn't address my concerns. In the Permit case you seem to be
issuing a SHALL requirement on discharging obligations, while in the Deny
case, you are issuing a SHOULD (best-efforts).

I don't agree.

The second sentence also says that the PEP SHALL deny access "in all other
cases".  The paragraphs might as well just end after that sentence.

That single sentence alone says, if you don't get a Permit, then Deny.

which leaves absolutely no room for dealing with this "error" thingy
(which is not defined), or even NotApplicable.

Why cannot this paragraph simply state the requirements are for
interpretation of the most simple model, which governs the common
understanding that you write XACML policies, such that "Deny" means do not
grant access, and "Permit" means grant access.

A PEP that relies on a decision from a single PDP, and it receives a
decision of Permit from that PDP, this PEP SHALL allow access. If this PEP
receives a decision of Deny from that PDP, this PEP SHALL deny access.
Either decision may carry with it obligations. It is this PEP's
responsibility to discarge those obligations. Should this PEP not
understand or cannot discharge any of the obligations, this PEP shall act
as if the PDP returned a decision of Indeterminate with reasons concerning
the understandablility or discharging the offending obligations.

If this PEP receives a response of Indeterminate or NotApplicable its
action is out-of-scope as further action MAY be taken by the PEP depending
on its configuration and capabilities. Further action MAY include, but is
not limited to, denying access outright, looking up values for misssing
attributes and resubmitting the access control request, looking up
incomprehensible obligations, or requesting of an alternate PDP.


>  > What if the PDP returns an Indeterminate or NotApplicable?
>
> see below (want to get all the text changes in first ;o)
>
> line 3478:
> A PEP that receives a valid XACML response of "Permit" with obligations
> SHALL be responsible for discharging all of those obligations.  A PEP
> that receives an XACML response of "Deny" with obligations SHALL be
> responsible for discharging all of the obligations that it understands
> and is capable of discharging. If the PEP cannot understand the
> obligations provided by the PDP it must treat the decision by the PDP as
> an ERROR.

Again, this is skewed toward Deny.


> below:
> per the second sentence those will result in a "Deny" as well. this is
> not an 'obligation' issue but rather is what i believe has been the de
> facto solution to the 'default policy' issue that has swirled around
> since the first XACML meeting. what i believe is implied here is that
> while a decision of "Permit" is required for access, this may come about
> implementationally as a result of multiple attempts by the PEP to
> contact a variety of PDPs (PAPs? i always find that line confusing ;o)
> in response to some internal logic.

A default policy is the configuration issue for the particular application
that deploys it.

You can tell me how I SHOULD use your product, but You are NOT going to
tell me how to run my organization!

> so, if you were to build a PEP that had the logic of:
>
> ask PDP1 for access control decisions for the door, but ask PDP2 (the
> lenient PDP) for decisions in the event PDP1 said no and it is really
> cold outside
>
> or
>
> rephrase access control decisions to include 'it is really cold' when
> the temperature is below 50 (which invokes a kinder, gentler policy)
>
> or even
>
> ask PDP2 for an access control decisions if PDP1 returns that obligation
> gibberish
>
> and either solution  *ultimately* yielded a "Permit" you are still in
> compliance of the spec even though you received a "Deny",
> "Indeterminate" or "Error" as part of the process.

I could not follow this argument at all and how it even gets around the
second sentence. Maybe it's the fact that you have multiple PDPs?

> what can't happen--and what it is i think we are trying to say here--is
> that unless *something* tells you to "Permit" and you *fully* understand
>   that message then you *cannot* allow access. this is not a 'skew to
> deny' in the policy evaluation, but rather the default behavior of any
> system that is conformant, and is done to ensure that there is some
> level of determinism at the point of *application* of a decision.

I don't agree. Again you are writing requirements on points you have no
knowlege about and you cannot control. You're guessing, and for lack of
information, you may be making the wrong decision.  Like our current
President.

> we need to have this for the simple reason that we must have some sort
> of baseline vocabulary from which to work. in this case "Permit" = grant
> access and *any* other result is a flavor of != grant access (a
> 'normally open' relay on the old circuit board ;o)

Deny is meant to be deny access
Permit is mean to be grant access.

and further, this is only in the case where you have a signular PEP-PDP
relationship!

It may be your Policy at your organization to categorically deny when you
get anything other than a Permit.  I respect that. It's your organization,
and it's your configuration.

But don't tell me that's how I should act.

If I want to deploy a XACML eating breathing PDP in my organization, the
spec tells me how to write polciies for it, such that Deny means Deny, and
Permit means Permit. And that's only so we have some common standard
expectation if I gave the job to write policies to somebody else.

If my PEP chooses to have 27 PDPs how are you going to tell me to run
that?

You cannot. Nor can any specification, except the one I write for my
organization.

Stop trying to rule the world! :)

Cheers,
-Polar





> 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]