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] | [Elist Home]


Subject: Re: [xacml] 7.7 Obligations


>
> Michiharu Kudoh wrote:
> > I think XACML specification should basically focus on the functionality on
> > the PDP but it does not necessarily mean that it MUST NOT say anything
> > about entries other than PDP in the normative sections. For example,
> > Section 7.1 describes desirable behavior in "PEP", for example in line
> > 2636-2664. The following are excerpt:

I do agree that "desireable" behavior should be specified. But you are
trying to specify what happens without a clearly specified architecture,
it leads to vague and incomplete specification.

> > - If the "Permit" value is returned, then the PEP MAY permit access to the
> > resource.
> > - If the "Deny" value is returned, then the PEP SHALL deny access to the
> > resource.

Why is the Permit a MAY and the Deny a SHALL? This seems confusing to a
reader. If there is a reason, it should be clearly stated. Do you mean
Deny Overrides?

> > - If the "Indeterminate" value is returned, it means that the PDP could not
> > make a decision. The PDP MAY return a decision value of "Indeterminate"
> > with a status code of  "... missing-attribute", etc.

This statment seems to be missing a statement about what the PEP should do
in this case.

If the "Indeterminate" value is returned, the PEP SHOULD .....


> > - If the "NotApplicable" is returned, it means that the PDP's policy is not
> > applicable to the request, implying that the PEP should send its request to
> > another PDP.

This implies that there are always other PDPs. Which means that there is
some policy external to XACML governing the decision. What is it?

What if there are many PDPs? What if there are no PDPs?
What configuration and policy governs the result?

> > The following are the text regarding obligations and I want to add in this
> > section:
> >
> > - If the "Permit with obligations(s)" value is returned, then the PEP MAY
> > permit access to the resource and PEP is responsible for fulfilling the
> > obligation(s). If there is an obligation that is not understandable by the
> > PEP, then the PEP SHALL deny access to the resource.

I have this take on this rule, so please straighten me out if I'm wrong.

Michiharu states that when a PDP returns Permit, a PEP MAY permit access.
Also, if a PDP returns Pemit with obligations, a PEP MAY permis access.
So, this rule overrides, saying that any PDP that returns a Permit in the
case of another PDP that returns Permit with at least one
non-understandable obligation.

What if 2 PDPs return Permit with obligations, all which are
"understandable."? What happens?

> > - If the "Deny with obligations(s)" value is returned, then the PEP SHALL
> > deny access to the resource and PEP is still responsible for fulfilling the
> > obligation(s). If there is an obligation that is not understandable by the
> > PEP, then the PEP SHALL raise an error. How and which error should be
> > raised is outside the scope of XACML.

What does an ERROR mean? Does the PEP deny access or what? Can you just
push the problem out to somebody else? Sounds like a cop-out, or a "we
don't know". To be consistent, it should probably be Deny and satisfy all
the obligations you can. Again, this forces you to ask all PDPs.

A real clean up to this problem, would be to list the understandable
obligations (URIs) in the RequestContext input, and let the PDP make the
decision in a compliant manner.

You still need a "desirable" mode of operation, such as Permit intends to
permit access, and deny intends to deny access, and you are guarranteed
that the obligations whether for Deny or Permit returned will be
understandable.

I'm still leary about forcing a Deny overrides policy on the PEP for
multiple PDPs, but it can certianly be strongly suggested that a PEP act
that way. If you require that behavior, then you better specify the
behavior for non-applicable, and indeterminate.

-Polar

> > Michiharu Kudo
> >
> > IBM Tokyo Research Laboratory, Internet Technology
> > Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>




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


Powered by eList eXpress LLC