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

[Oleg Gryb <oleg_gryb@yahoo.com>]

Hi Seth,

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

Here are some simple questions that might clarify my point of view and may narrow the gap in opinions:

1. Is XSD provided in XACML document a part of specification?

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

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

4. Can you formally define the set of policies and requests that your library, running in 'dangerous' mode, supports?

5. Are you sure (if you are - please explain why) that other PDPs running in the 'dangerous' mode will support the same set of requests and policies as SunXACML?

Actually, it would be good to hear TC's opinion in regards qs #1 & #2.

PS> I'm taking out security at this moment, because it has been discussed in a different thread.

--- On Wed, 1/14/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: Wednesday, January 14, 2009, 2:06 PM
> Hi Oleg. 
>  
> > 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.
> 
> Respectfully, I don't think you quite understood my
> point. As a *library*
> author, I don't know how people will use the code I
> write. So in the specific
> case of SunXACML, I don't have anything enforcing a
> schema check or other
> validation routine.
> 
> This said, any production system should of course ensure
> that all policies
> are valid; the question is how this is done. There are may
> projects where
> people have built code around the SunXACML library to
> provide an application
> or service of some kind. These auto-generate correct
> policies, or
> schema-validate policies, or otherwise verify that the
> input to SunXACML
> is correct. To provide an invalid policy would be a bug.
> 
> I don't know what this "Dangerous mode" is
> that you talked about, but any
> application that accepts invalid input in running
> environments and still
> tries to work with that input is certainly dangerous, and
> clearly a
> security risk. 
> 
> To be clear, I am not thinking about this or any other
> project I work on
> as performance instead of security or interoperability. I
> have worked on
> many standards, and have spent years doing deep security
> research because
> these are areas that I believe are critical to building
> good systems. I
> also understand the reality of enterprise systems, and know
> that good
> library code needs to be flexible.
> 
> One other note..
>  
> > 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.
> 
> You're thinking about this the wrong way around.
> I'm not trying to force
> people to do validation somewhere else, I'm assuming
> that (as is the case
> in many systems I've looked at) validation may already
> be happening
> somewhere else. In that case, forcing validation to happen
> again is
> certainly a performance hit that isn't needed.
> 
> 
> seth
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
> xacml-users-help@lists.oasis-open.org