OpenSAML user discussion

[Brent Putman <>]

Kenny Pearce wrote:
> Brent,
>         Thanks for getting back to me. I've just realized (after reading your
> email and considering the points you raise) what the problem must be,
> but I'm not sure how to fix it. I am doing my XACML processing using the
> enterprise-java-xacml engine
> (http://code.google.com/p/enterprise-java-xacml/). The author of that
> project claims that the latest version Xerces is seriously buggy and the
> version included with recent versions of the Sun JVM works properly
> (this, I realize, is exactly the opposite of what the OpenSAML team has
> told me).

Yeah.  :-)  Could be that both Sun's and latest Xerces are buggy in 
different respects and we're each basing our recommendation on the 
specific problems we've run into.  Not an ideal situation, really...


>  So he is forcing the use of the Sun version when I load in the
> policies. Then I am grabbing the policies from the PDP to send them back
> to the client in an XACMLPolicyStatementType. So that would be why
> adoptNode fails. (I have, however, seen it fail in other circumstances,
> so perhaps you should be checking for that condition anyway.)
>   


Ok, that sounds like that would cause it.  I did open a bug JXT-32 to 
update xmltooling to test for that condition.  It's possible that if the 
adoptNode fails, we could try an importNode as a fallback, and then only 
throw an error if both fail.  Don't know if that will work, there might 
be undesirable side effects, have to think about it..... but since it 
copies the node, that might avoid the case of differing impls.  In fact, 
if you *are* building and running xmltooling from source and want to 
give that a try (it's like 2 lines) and let me know...


>         At any rate, I wouldn't call it an OpenSAML bug if this weird 
> situation
> required me to release the DOM before proceeding. That's a fairly
> reasonable requirement.
>   


It may or may not be technically a bug, but if adoptNode fails (and if 
importNode as a fallback proves not workable), then that's probably the 
only solution.  Except for the total brute force approach of serializing 
what you get from the other impl, and then reparse and unmarshall using 
whatever impl is used for opensaml.  That would solve it almost 
certainly, albeit very inefficiently.  But I think this sort of 
converting between different XML implementations is often just a fact of 
life in the web services world...

> 	This still leaves the namespace bug. 

Sorry, I haven't had a chance to look at that yet.  Maybe tomorrow.

> Plus, the latest thing is that
> some of my elements are disappearing. This includes all Description
> elements and all the contents of my Subject element, at least. I've only
> tried with two policies, so I haven't been able to figure out exactly
> what the disappearing elements have in common, other than that there are
> several Description elements and all of them disappear. Do you have any
> idea what the cause of this might be?
>   

Yeah, I took a quick look, I haven't looked at the new XACML stuff much 
yet.  These appear to be just simple provider bugs and/or config file 
bugs.  The DescriptionType doesn't have any impl classes, nor a config 
file entry, so when it's unmarshalled, it gets created as the default 
provider (XSAny).  But the parent (PolicyType) doesn't handle XSAny's in 
its processChildElement and so it gets (silently) ignored.  Same for the 
SubjectMatchType which is child of SubjectType - it doesn't have a 
config entry, so becomes an XSAny.  Because you drop the DOM, you lose 
them completely and so not there when you re-marshall.  You mentioned 
something also about Rules also in an earlier message,  I didn't look at 
that, but I'll bet it's a similar bug.

If you turn on TRACE level logging for package org.opensaml.xml.io, you 
should see some messages to that effect from AbstractXMLObjectUnmarshaller.

"No unmarshaller was registered for {}, child of {}. Using default 
unmarshaller."

File a java-opensaml2 bug on those, and hopefully Håkon can take a 
look.    There don't seem to be any unit tests for the XACML stuff either.

--Brent