OpenSAML user discussion

[Brent Putman <>]

Scott Cantor wrote:

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.
    

I think I raised that issue a long time ago, but that seems like
questionable behvaior to me. Silently ignoring stuff while ending up with a
distorted tree seems like a bad outcome.

  

Yeah, I agree that this is an issue, and that we should at least have some option for handling unknown or unexpected elements or attributes.

Actually, in the rest of opensaml2, and in the xmltooling encryption and signature providers, all the unmarshallers and marshallers actually extend a specific subclass of the appropriate abstract XMLObject ones, and the unmarshallers delegate to the super if they encounter an element/attribute they can't process.  Some of those abstract supers just log it, some just ignore, but at least it's a point where we could do some kind of handling if we so chose.  Maybe we could have a flag on Configuration that determines whether unknowns are a fatal error or just logged, and then implement there.

In any case I think the XACML providers should probably follow the same model as the rest of the code, so we can implement something along those lines if we choose to.  They currently extend the abstract XMLObject marshallers and unmarshallers directly, which also means they unfortunately have to supply impls for all the abstract methods, even if not applicable to the content model.