[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