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


On Tue, 8 Oct 2002, bill parducci wrote:

> > 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.
>
> give this a peep:
> http://www.oasis-open.org/committees/security/docs/cs-sstc-schema-protocol-01.xsd
>
> this is why the SAML context mapping is specifically addressed in *our* spec.

This is a XML schema document. It doesn't really mean much to me, or
explain very much about the behavior of anything that *uses* SAML.

> > What is different about an "operational" view? Just because you tag it
> > "operational" means that it is not a concern?
>
> no. what i am saying is that where the PEP *may* be located is not
> relevant to the discussion because one of the situations where it
> *will* be is on the other end of a SAML authorization decision query.
> therefore how a PEP behaves that is only 'attached' to the PDP via
> such a request is crucial to the reproducibility of the results.

The reproducibility of the results relies on the input parameters
(RequestContext, configuration, and quite possibly the authenticated
identity of the PEP), and the policy given to a PDP.

The Application may or may not give you access, sometimes you won't even
see it. I being an application, may get a Deny response from a PDP, but
decide to give you access any way, but maybe to a false object. But in any
case, you cannot bind me to deny access in a consistent manner.

> [...]
>
> > 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.
>
> keyword *configure*. now, what are the specs for that?

There aren't any, that is exactly my point. You are trying to place
"configuration" requirements down on something as well.

> > 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.
>
> no, incredibly difficult because...(ok, this time with shorter sentences :oP)
>
> ...you still must address how you maintain accurate mappings for the
> capabilities of each PEP to the PDP. the only dynamic way to do this
> is to have each PEP present its capabilities upon request (or at least
> when it comes on line/updates its skill set). that means another
> protocol entirely.

You don't think you have to do this anyway?

Of course it means another protocol entirely.

The problem here is we are not specifying protocols or interfaces, so we
are out of luck.

You can say anything you want about a PEP, but there's no way you can even
test for conformance!

> *then* once you have that figured out you must address how you extend
> the current XACML spec so that policy writers can create polices that
> take this into account (e.g. "only send a permit if PEP can do 128 bit
> encryption, *not* 56 bit bit encryption.") which, if you think about
> it takes you right back to the existing spec: don't permit unless you
> can understand the decision in its entirety.

Of course you do. If you are going to include those kind of obligations,
where do you think they are going to come from? They are just URIs.

So, your obligation has a URI:

http://www.overXeer.com/obligations/1

which states that "send with 128 bit encryption, *no* 56 bit encryption".

Your PEP sends a request

<RequestContext>
  <subject>
  <resource>
  <action>
  <Understandable Obligations>
	<Obligation> http://www.overXeer.com/obligations/1 </Obligation>
	<Obligation> http://www.overXeer.com/obligations/2 </Obligation>
	<Obligation> http://www.overXeer.com/obligations/3 </Obligation>
	<Obligation> http://www.overXeer.com/obligations/4 </Obligation>
  </Understanble Obligation>
</RequestContext>


The PDP knows to send you a response with Permit with a obligation of
http://www.overXeer.com/obligations/1. However, if the PDP evaluates the
policy and it gets a Permit with http://www.adiron.com/obligations/45.

What do you do?

You can easily make the PDP return Deny without knowing anything about the
PEP.




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


Powered by eList eXpress LLC