MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] 7.7 Obligations
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:
- 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.
- 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.
- 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.
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.
- 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.
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
bill parducci
<bill.parducci@ov To: "'XACML TC '" <xacml@lists.oasis-open.org>
erxeer.com> cc:
Subject: Re: [xacml] 7.7 Obligations
2002/10/08 10:26
> Decision or no decision, how does it make sense?
huh? this a zen thing? :o)
> What is a PEP? We know what a PDP is. It takes a well formed input and
> evaluates it against a well formed policy and yields a well formed result
> semantically consistent with the input and policy. There is a notion of
> conformity and compliance. Furthermore that compliances is based on
> mathematic principles.
>
> A PEP is merely a point in some application somewhere, that may or may
not
> even call on a PDP, PRP, or a PIP. So, how can you place any coformance
> requirements on it? Are you going to call an application PEP compliant?
> Who would care?
so what you are saying is that SAML is a waste time because remote azn
requests will never occur amongst vendors? (remote auth is only half of
SAML).
> If you want to have compliance points based on obligations, they should
be
> placed on the component we are defining, the PDP, to give you the correct
> decision.
the issue is not if the pdp gives the correct decision, it is that the
decision may have as a component an obligation (note to daniel:
obligations may also occur for DENY). by definition any device receiving
an obligation MUST be able to comprehend that obligation in order to
permit access to a resource.
> If the intended behavior is to deny access for non-understandable
> obligcations, perhaps, we should say that the PDP should be configured
> with "understandable" obligations, and to answer Deny if a decision of
> Permit comes up with any obligations not in the "understandable" set.
that would mean policies on the PDP must reflect the capabilities of all
potential PEPs. that would break encapsulation and lead to an impossibly
difficult system to administer (the specter of tiered 'understanding
capabilities').
> Alternatively, we can put "understandable" obligations in the
> RequestContext, and the evaluation depends on those "understandable"
> obligations in the same manner.
same issue.
b
----------------------------------------------------------------
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