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

[Oleg Gryb <oleg_gryb@yahoo.com>]

--- On Thu, 1/15/09, Seth Proctor <Seth.Proctor@sun.com> wrote:

> From: Seth Proctor <Seth.Proctor@sun.com>
> Subject: Re: [xacml-users] Validating XACML policies and requests against XSD
> To: oleg@gryb.info
> Cc: xacml-users@lists.oasis-open.org
> Date: Thursday, January 15, 2009, 10:45 AM
> 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.

Yes, I understood the joke, but I've also decided to exploit the term because it seems to be very appropriate in this context :)

> 
> 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. 

If even you can't answer then ... I would consider this as a specification's flaw or area for improvements and would like to ask TC the same qs again.

>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.

I think I know at least one vendor who states that but I must disagree with them and with you. In their implementation Request/Response is compliant with XACML’s XSD, but Policies are proprietary and there is no way to export/import real XACML policy to/from their system. I think you can't de-couple XACML request from XACML policy because the rules that describe the process of evaluation refer to both request and policies. If vendor wants to use different policies they’ll need to create a new standard that would describe how XACML-compliant request is evaluated against their proprietary policies.

> 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.

I agree that PDP should validate both syntax and semantics. The problem with semantics is that there is usually no mechanism that would formally define it: many attempts have been made in the last 20+ years, but they didn't result in wide spread semantics validating tools. It's different with syntax: both formal syntax definitions and validating tools are available for many formal languages including XML-based ones. In programming languages a compiler always defines a superset of all valid (from semantic point of view) programs; the same is true about policy/request/response language defined in XACML. 

All that means that the only way to define semantics is to use plain human language and the only way to validate semantics is to write a custom code. 

Since we can't formally define the exact set of allowed requests/policies, let us at least formally define a superset using XSD. It will improve the interoperability significantly and that's why I think that XACML specification should say explicitly that if a policy or request is not compliant with a corresponding XSD then the request/policy must be rejected by a PDP. In other words: “dangerous” mode is not allowed.


> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
> xacml-users-help@lists.oasis-open.org