OpenSAML user discussion

["Stepan Hrbacek" <>]

Hi Brent!

2008/12/4 Brent Putman <>

I'm not sure I 100% understand what you want to do.  But if the
fundamental question is how to use AttributeValues which are
non-namespace-qualified XML:

Yes, that's exactly what we need to do. The Java code matches 1:1 to our use case.

Namespace-qualified XML values for AttributeValues are supported just
fine, however.  So my suggestion would be to just use
namespace-qualified data, declare the default namespace on the root
element of each subtree and use that default namespace on those elements
to eliminate the namespace prefix.  Then, the non-namespace-aware code
that is apparently consuming the AttributeValue data can just ignore the
xmlns attribute on the element.  That's probably the closest you can get
to what you want.

Thank you for your hint. Unfortunately we are not able to influence the AttributeValue data consumer. Simply because its' a different company and uses JAXB generated classes for parsing the data. And when we tried to send the data without prefixes and with default namespace declarions, JAXB failed to process them.
 

The reason is more fundamental than OpenSAML.  We rely under the covers
on the DOM API.  In the DOM, as far as I know, trying to mix
namespace-qualified and non-namespace-qualified XML is a non-starter.
You just can't do it, especially if you going to anything non-trivial
like XML signature and the like.

SAML is of course namespace-qualified.  So trying to use SAML data
structures via the DOM API is mutually exclusive with
non-namespace-qualified content.  If someone else knows otherwise,
please correct me.

 
I don't think that using non-namespace-qualified content inside SAML data (AttributeValue) causes some problems for DOM API or XML signatures because for our use case we have found following workaround that at the end produced valid XML data (SAML Assertion), with valid XML signatures. And these data were successfully processed by a web service running in a remote company's server and using Metro WS stack and JAXB for processing SAML Assertion.  
The workaround we used is:
- create AttributeValue with fully qualified subelements (<ns:Value xmlns:ns="my-namespace"/>)
- create SAML Assertion with this AttributeValue and signature and marshall the assertion to DOM data
- modify the DOM data - remove namespaces from the <ns:Value/> elements
- compute XML signature

Thus I think the issue we experienced is:
- either in the way we use OpenSAML to create AttributeValue with complex DOM data,
- or it's a XmlTooling issue we reported in https://bugs.internet2.edu/jira/browse/JXT-42 (but this was refused by the XmlTooling expert)

After seeing all these facts - what do you think? Does it look like an error in XmlTooling or not?

--Brent

--Stepan