Thank you very much for your explanation.
On Wed, Mar 11, 2009 at 10:02:07PM +0100, Andreas Veithen wrote:
> I think there are three possible approaches to solve your issue:
>
> 1. We can try to fix specific issues you discover in DOOM to make it
> work in your particular use case, as suggested by Ruchith.
>
Well, it's apparently the exact same case as Ruchith stated.
But I see it's not a very promising alternative.
> 2. Starting with version 1.2.8, Axiom has OMSource and OMResult
> classes [1] which are implementations of JAXP's Source and Result
> classes. You can use these to transform an Axiom tree into DOM (using
> a standard implementation of DOM) and vice-versa. These two classes
> are based on SAXSource and SAXResult, which means that you loose the
> deferred parsing capabilities of Axiom, but in many cases this will be
> acceptable.
>
Ok. I'll look into this. Thank you. Aarerntly this wouldn't involve
much overhead, just the complete SAML assertion tree, but not all
the SOAP message.
> 3. Some time ago I started an alternative DOM implementation for Axiom
> which relies on a different pattern than DOOM: it implements the DOM
> nodes as lightweight proxies that are backed by an existing Axiom
> implementation (typically the default LLOM implementation). This has
> several advantages over DOOM, in particular the fact that instead of
> converting from and to DOM (which is how DOOM is used in practice),
> you can adapt an existing Axiom tree to DOM and create a new Axiom
> tree through the DOM API. The goal is to have a really DOM compliant
> implementation (including DOM 3), except for the part related to DTD
> handling and validation. The implementation is not yet complete, but
> already passes a large part of the W3C DOM test suite. I'm interested
> in testing this on real world use cases, so I would be happy if you
> could post the code that has an issue with DOOM so that I can test it.
>
How much code do you need ?
My case is basically a web service server that has to valdidate
SAML 2 assertions presents in a SOAP Header. But since they don't
follow any SAML 2 profile precisely, nor WS-Security, I have to
do some validation manually that I could otherwise use rampart
or something to do for me.
// [ quick summary of imports, in case it's relevant ]
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.impl.builder.StAXOMBuilder;
import org.apache.axiom.om.impl.dom.DOOMAbstractFactory;
import org.apache.axis2.AxisFault;
import org.apache.axis2.util.XMLUtils;
import org.opensaml.Configuration;
import org.opensaml.DefaultBootstrap;
import org.opensaml.saml2.core.Assertion;
import org.opensaml.xml.ConfigurationException;
import org.opensaml.xml.XMLObject;
import org.opensaml.xml.io.Unmarshaller;
import org.opensaml.xml.io.UnmarshallerFactory;
import org.opensaml.xml.io.UnmarshallingException;
import org.opensaml.xml.parse.BasicParserPool;
import org.opensaml.xml.validation.ValidationException;
import org.w3c.dom.Element;
import com.scs.pdcc.opensaml.FilesystemCredentialResolver;
[...]
public boolean assercioValida(OMElement assercio) {
//Throws: java.lang.UnsupportedOperationException: T O D O at
// org.apache.axiom.om.impl.dom.TextImpl.getWholeText(TextImpl.java:587))
Element assercioSAMLDOOM = (Element) new
StAXOMBuilder(DOOMAbstractFactory.getOMFactory(),
assercio.getXMLStreamReader()).getDocumentElement();
// this should be irrelevant since it fails before, but ask for
details if needed
try {
// works but I believe it's not efficient.
// Element assercioSAMLDOOM = XMLUtils.toDOM(assercio);
// Ara ja tenim un node DOM, obtindrem una Assertion OpenSAML2
UnmarshallerFactory unmarshallerFactory =
Configuration.getUnmarshallerFactory();
Unmarshaller unmarshaller =
unmarshallerFactory.getUnmarshaller(Assertion.DEFAULT_ELEMENT_NAME);
Assertion ass = (Assertion) unmarshaller.unmarshall(assercioSAMLDOOM);
valida(ass);
return true;
} catch (ValidationException e) {
logger.warn(e, e);
} catch (Exception e1) {
logger.error(e1,e1);
}
return false;
}
--
Xavi Drudis Ferran
[email protected]
