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

[Oleg Gryb <oleg_gryb@yahoo.com>]

Seth, Yoichi,

I think I understand your point, but I can't agree with it because I'm looking at the problem from security and interop point of view while you are trying to address performance issues.

'Dangerous' mode, which is a default as I understand, is dangerous indeed because of security considerations and because by enabling it you're automatically expanding the set of requests and policies beyond the ones that are defined by the standard, so it's not clear anymore what your PDP, running in 'Dangerous' mode, implements exactly. Probably the fact that SunXACML is interoperable with other PDPs means that they don't do validation by default either?

Doing validation somewhere else won't improve the overall authorization system performance - you still need to do it and it will require time that will be added to the total system's response time.

Doing validation at 'testing' and 'development' time only is not a good solution, because what you're testing and developing is not what you'll have in production. Your production environment will support a superset of policies and requests compare with what you had in dev, so if your PEP misbehaves or somebody will extend your PEP with new requests you can end up with a wrong authorization decision ('Permit' or 'Deny' while it should've been 'Indeterminate' according to the spec).

In other words, running PDP in 'Dangerous' mode is the same as running a PDP that is not compliant with PDP specification.

Oleg.




--- On Tue, 1/13/09, Yoichi Takayama <yoichi@melcoe.mq.edu.au> wrote:

> From: Yoichi Takayama <yoichi@melcoe.mq.edu.au>
> Subject: Re: [xacml-users] Validating XACML policies and requests against XSD
> To: "Seth Proctor" <Seth.Proctor@sun.com>
> Cc: oleg@gryb.info, xacml-users@lists.oasis-open.org, xacml-comments@lists.oasis-open.org
> Date: Tuesday, January 13, 2009, 3:50 PM
> Thanks for the clarification.
> 
> I agree with you that XSDs can be checked with at the
> developing and testing time. Once XACML documents are proved
> to be conforming, there may not be a need to validate every
> time at runtime.
> 
> Particularly with Policies, if they are stored as non-XML
> once they are processed. (This depends on the PDP code?)
> 
> As to the Request and Response, though, the XACML system or
> policy designer may not know what they are in advance. They
> may be also sent from other systems which have different
> vendors etc.
> 
> In this case, if the sending systems validated them
> beforehand, they do not have to be validated again at the
> receiving end.
> 
> However, such cannot be guaranteed, even if they carried an
> additional Attribute that may ask for no validation to be
> done (can it be embedded with SOAP?).
> 
> What is your thought on this? Do we still leave it for the
> XACML system to be switched on or off, regardless?
> 
> By the way, this discussion is separate from the support of
> namespaces, which I know is supported in 1.1. So, you are
> confirming that the Sun XACML 2.0 engine code support those
> old namespaces used by XACML 1.1, but not the new ones used
> by XACML 2.0, yet. Is that right?
> 
> Thanks,
> Yoichi
> --------------------------------------------------------------------------
> Yoichi Takayama, PhD
> Senior Research Fellow
> RAMP Project
> MELCOE (Macquarie E-Learning Centre of Excellence)
> MACQUARIE UNIVERSITY
> 
> Phone: +61 (0)2 9850 9073
> Fax: +61 (0)2 9850 6527
> www.mq.edu.au
> www.melcoe.mq.edu.au/projects/RAMP/
> --------------------------------------------------------------------------
> MACQUARIE UNIVERSITY: CRICOS Provider No 00002J
> 
> This message is intended for the addressee named and may
> contain confidential information.  If you are not the
> intended recipient, please delete it and notify the sender.
> Views expressed in this message are those of the individual
> sender, and are not necessarily the views of Macquarie
> E-Learning Centre Of Excellence (MELCOE) or Macquarie
> University.
> 
> On 14/01/2009, at 7:26 AM, Seth Proctor wrote:
> 
> > 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
> > work.
> > 
> > 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
> > validation.
> > 
> > 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 :)