OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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

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

Hi Oleg (et al). I'll speak from my SunXACML experience, since I'm not as
familiar with some of the other tools out there.

It's always been my personal opinion that libraries and other core tools
should not do schema validation by default. It's often the case that
enbedding or calling tools will already have done validation, or will
be generating the content, in which case enforcing validation is wasted

This said, validation should of course be supported. In the case of SunXACML,
both the process of loading a Request and a Policy is a plugin point. This
means that the author of that mechanism can choose to do validation or not
as is appropriate for their environment. The sample/default implementations
provided with the project have a property to set if you want to turn on

In a similar vein, SunXACML (and most of the tools I write which consume
XML) assumes that the content it's handed is XML/Schema valid. In other
words, there's minimal attempt to check for possible flaws while processing
any input. Can this lead to problems? Yes. Again, I feel it's up to the
user of a library like SunXACML to decide whether the content is known
to be valid, to enforce validation of all content, or, umm, live
dangerously :)

To one specific that you (quite rightly) asked:

> 2. It affects PDP's interoperability. Example that Hao has provided makes me thing that sunxacml disregards namespaces, it means that it won't be interoperable with any PDP engine that does the validation against XSD. Seth, please let me know if my observation is not correct.
I think there are two separate issues here. SunXACML has been shown to be
interoparable with many other PDPs, but you're right, namespace handling
is not SunXACML's strong point. There are known bugs/features here, but
no one has had the cycles to update this.

More specifically, however, I think this came up in the context of which
version of XACML was being used. SunXACML can (and I think any good
PDP should support this) handle mixing versions of XACML. As you've
pointed out, however, to make this work you need to make sure that
content is namespaced correctly and validated. In the previous thread,
the issue was that a 2.0 Request was provided, but the SunXACML
context-handling code hasn't been updated to know about multiple
versions, so it didn't reject the document (it should, and when/if
someone updates the code to support 2.0, this will happen pretty
much automatically). Policy handling *does* handle namespaces correctly,
since this is 2.0-compliant.

Hope this helps...definitely a good set of issues for everyone to be
thinking about..


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