Re: [xacml-users] Validating XACML policies and requests against XSD

[Seth Proctor <Seth.Proctor@sun.com>]

Hi Oleg.
 
> 'Dangerous' mode is taken from your prior email:
> 
> > > to be valid, to enforce validation of all content, or,
> > umm, live
> > > dangerously :)
> 
> It means running PDP without validating requests and policies against XSD.

The comment was meant as a joke, thus the smiley face :) My whole point
is that if you're not working with valid inputs, you're putting the
security and correctness of your system in danger.

If you want to keep the SunXACML-specific discussion going, let's do that
on the project discussion list. I'm going to respond more generally to
your questions..
 
> 1. Is XSD provided in XACML document a part of specification?
 
Of course. I don't speak "officially" for the TC, but I have to believe
that most members would agree.

> 2. Is it a mandatory or optional part of specification?

That's harder to answer. Technically, XACML is really two specifications:
a set of semantics for a language, and a standard way of expressing this
in XML. Technically, a PDP can be written that never deals in XML, and
still evaluates rules correctly.

There's another way of looking at this too (note: I'm not crazy about this
point of view, but for full-disclosure I'm raising it here). I've talked
with many commercial PDP vendors who don't support XACML policies at all.
They have a custom policy language, but they do accept XACML Requests,
XACML Requests through the SAML profile, etc. Their claim is that these
are XACML PDPs because they can interoperate on the Request/Response
interface, and to some degree I suppose this is a valid (if mis-leading)
argument.

All this said, I would say that if you're implementing an XACML PDP that
you want to work with any other PDPs, tools, or other users of XACML, then
it should obviously support the standard XML encoding of XACML policies.

> 3. If it's mandatory, but somebody runs your library in the 'dangerous' mode, is it compliant with the specification?

For any tool, application, library, etc. to accept invalid input you have
to expect the result to be unknown. This is why I have now said several times
that policies and requests must always be known to be valid through some
mechanism before they are evaluated. I think I've made my thoughts on this
as clear as possible, and you and I seem to be in agreement on this point,
if not on the point at which validation should occurr.

I'd like to come back to an issue that Craig (I think) very correctly
raised. Schema validation is just a first-step. Looking at the content
of a policy is also important. Back in the earlier days of XACML, we
had a long-running debate about whether a semantically invalid policy
should be allowed to be evaluated by a PDP, or whether a PDP must reject
such a policy. An example of this is an Apply statement with children
that return the wrong data types for evaluation. This can't be enforced
in the schema, but an XACML implementation can catch this case.

I argued very strongly (and still believe) that such a policy should be
caught and rejected; a PDP should not be allowed to try evaluating an
invalid policy. The argument on the other side is that it requires
extra processing to verify a policy, as opposed to verifying the
type-matching as evaluation proceeds down a tree, and that if a given
invalid branch is never evaluated then why reject the policy? This
comes back to the original ideaology of how XACML was designed, which
was as a language and set of semantics first, and an XML encoding
second. Given this, the idea that you should only worry about the
validity of what you actually process makes a lot of sense. Given that
most people think of the XML as the "true" representation of XACML,
however, I still think this is very dangerous practice.

If you look at the conformance tests, you'll see IIA004Special.txt, which
is a set of notes to implementors for the IIA004 test case. It includes
this language:

  If an initial policy with invalid syntax MAY EVER be evaluated by
  the implementation's XACML PDP at the time a Request is received
  ...
  If the implementation's XACML PDP CAN NEVER attempt to evaluate
  an initial policy with invalid syntax, then the implementation
  ...

In other words, a PDP may operate in one of two states, but it should be
clear which kind it is, and it should choose to implement one of these
behaviors. Strange, I know, but true and from the language-theory point
of view I've described above it does make some sense in my opinion.

I hope this has provided some useful context for what my feelings are,
and what some of the discussions have been from the TC in the past. To
re-cap, I believe strongly that input should always be valid, and that
means not only schema-valid but also semantically valid. SunXACML is
built with the assumption that the schema validation must happen at
some point before evaluation, and based on this does the semantic
check to make sure that a policy is valid before evaluation proceeds.


seth