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
On Tue, 8 Oct 2002, bill parducci wrote:
> Polar Humenn wrote:
> > I didn't say anything about SAML.
>
> "Polar Humenn wrote: [...] Are you going to call an application PEP compliant? Who would care?"
>
> a large portion of SAML is based upon remote authorization decision
> requests, so by questioning PEP <--> PDP interaction you are making
> statements that imply lack of value in the better part of the SAML
> spec.
Again, I didn't say anything about SAML. I could point you to all kind of
CORBA specifications in which the protocol, the types, and the
specifications are completely specified from their inputs to their
responses, but I won't use that in my argument.
But if I must, SAML is based on querying some static or dynamic database
for assertions about specific things. You make a SAML <something> request,
you get a SAML <something> response, over some unspecified protocol.
There is no remote authorization decisions going on. There is no
management interfaces, so what is left behind the interfaces is left up to
interpretation, i.e. configuration and operation.
I see nothing in the SAML specs that says anything about even how actions
based on a SAML request/response pair should behave. So, I see no
correspondence with the value or lack there of with the SAML
specification.
> > I am not arguing that. But the question is something that permits access
> > with an obligation has more power over somebody who permits plain access
> > without any obligations. This forces you to ask all PDPs for and combine
> > their obligations.
>
> this assumes that you are going to have multiple PDPs protecting the
> same resource and that these PDPs would not be configured similarly
> (an operational issue in my mind).
What is different about an "operational" view? Just because you tag it
"operational" means that it is not a concern?
> even if that were the case (it seems unlikely to me) i can also turn
> this argument around and say that if there are multiple PEPs
> protecting a resource i can get greater access to the one that doesn't
> support obligations because the PDP will return DIFFERENT RESULTS to
> it.
Multiple PEPs? Do you mean a single application using multiple PEPs?
There is no point there, because then the PEPs just become PDPs, and the
application reverts back to a single PEP with multiple PDPs. The
question is back in your court.
If you mean multiple applications defending the same resource for the same
purpose, then you have the same result. If you go to the application that
understands the obligations, you are granted access, if you go to the one
that doesn't you are denied. That's all well in good, provided you have
one PDP per PEP. If you have multiple PDPs, then what order to do you call
them in? Do you call all of them? Do the mulitple applications all call
the exact same PDPs?
We can fully eliminate this questions by stating the following:
A PEP SHALL ONLY QUERY ONE PDP. Then specify what it does for
Indeterminate and Inapplicable.
> > Not really. The PDP has a clue about what obligations it will emit. If the
> > PEP states its understandable obligations either by configuration or by
> > RequestContext input, the PDP makes decision about whether to Permit with
> > obligations or a Deny. This can be stated in a standard answer when
> > converting the result of a rule/policy combining algorthim to a PDP
> > Result.
>
> and the protocol for a PEP to 'state its understandable obligations'
> is? are you proposing an extension to the XACML context? if part of
> the XACML spec, how do you differentiate syntactically between PEPs
> that support one type of obligation over another? (e.g. encrypt: 3-DES
> vs. blowfish vs. ?) if not in the XACML lexicon, is this now a
> configuration constraint that now must be reffered to by the spec?
Well, if there were a protocol, that would be nice, wouldn't it?
I didn't say it had to be in the RequestContext, but you could configure
the PDP it will hand you only "understandable" obligations. If you base
your PDP decision on authenticating the requesting application (i.e. the
PEP), you can have a list of configured obligations that the particular
PEP understands, and return a standard decision of Permit with
obligations or Deny, accordingly.
> > However, this way everything is specified, and furthermore, the answer
> > returned from a PDP can go through compliance tests for that feature,
> > yielding MORE ASSURANCE to the Process, Methods, and Products.
>
> not sure how you come to this conclusion: conformance is now more
> difficult for the reasons stated above. rather than taking the
> position:
> "if you don't understand the decision, effectively DENY--ALL PEPs
> behave the SAME"
> and proposing:
>
> "develop a methodology by which PEPs can communicate to to PDPs their
> innate ability to understand potential decision parameters so that the
> PDPs can filter the requests using one or more algorithms -- in or out
> of the xacml specification (further extensions to the spec or
> out-of-band configuration options)--thereby creating DIFFERENT outputs
> based upon the capabilities of the PEP"
>
> you are adding a tremendous amount of complexity.
Of course, because you make it sound that way because you utter it in a
rambling sense. I mean, use a period once in a while! :) In fact, what you
just specified above is the exact behavior of a PDP enabled by an XACML
engine and policy. Let me illustrate:
"develop a methodology by which PEPs can communication to PDPs their inate
ability to understand potential decision parameters, such as resource
identifiers and attributes, resource hierarchies, action identifiers and
attributes, subject categories, subject attributes, and environmental
attributes, so that PDP can filter the requests using one or more target
matching algorithms -- in or out of the xacml specifications (further
extensions to the spec of out-of-ban configuration options)--thereby
creating DIFFERENT outputs based on the capabilities of the PEP".
How about:
Either by configuration, per PEP or in general, and/or by XACML context, a
PDP SHALL ONLY respond with Permit or Deny with obligations that a PEP
understands.
It's pretty simple. A PEP knows what obligations it can understand, and a
PDP knows what obligations it emits. Just as a PEP know what attributes is
must supply, and the PDP know what attributes it must be supplied.
If you compile and XACML policy thoroughly, you can fully imply all needed
attributes for subject, action, resource and environment, the format they
should be in, and also, the obligations that can be emitted.
However, still having the question of multiple PDPs is going to be a
problem.
-Polar
> 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