[
https://issues.apache.org/jira/browse/WSS-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044170#comment-13044170
]
Jeremy Tadman commented on WSS-282:
-----------------------------------
The attached jar does not completely fix the problem.
When running only one application on the server, the problem will appear to be
gone as each time that application will refresh the copy of the STR Transform
which is in the JCE provider list. When running two applications, the problem
still occurs under the following use:
Start both applications.
Generate SAML token in app 1 (causes init to occur and App 1's STRTransform is
added to provider list). - Works fine
Generate SAML token in app 2 (causes init to occur and App 2's STRTransform is
added to provider list). - Works fine
Generate SAML token in app 1 (init does not occur. App 2's STRTransform is the
copy which is in provider list). - Class cast exception as two different
org.jcp.xml.dsig.internal.dom.DOMSubTreeData classes are compared.
I've tried that approach in the past (removing the STRTransform provider before
init). The only way I got it to work was if the STR transform was removed and
replaced in the list EVERY time STRTransform is called. This would probably not
hold up under load (thread safety?) and just seems dodgy to me.
We did end up solving this by placing WSS4j and all of its dependencies in the
WebSphere "extension" class loader (WAS_BASE/lib/ext). This is non-ideal as
we're introducing about 10 new jars to a classloader shared by all
applications, but it works in my development environment (yet to be tested with
the actual apps which will be running). It'd be great if we were able to
isolate just the STRTransform in a separate JAR without any unnecessary such as
OpenSAML. That way the JCE provider and the necessary dependencies (santuario,
xalan, xerces) could be placed in the extensions classloader relatively cleanly.
I'll post a list of JARs we've included in the ext classloader when I get back
to work on Monday.
> STRTransform JCE provider throws java.lang.ClassCastException:
> org.jcp.xml.dsig.internal.dom.DOMSubTreeData incompatible with
> javax.xml.crypto.OctetStreamData in Websphere
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WSS-282
> URL: https://issues.apache.org/jira/browse/WSS-282
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core
> Affects Versions: 1.6
> Environment: WebSphere 7.0.0.15
> Reporter: Jeremy Tadman
> Assignee: Colm O hEigeartaigh
>
> When using WSS4J to generate signed sender-vouches SAML tokens involving an
> STRTransform I get the below exception (right at the end). It only happens
> when there are multiple applications using WSS4J or the application is
> restarted.
> Seems to be related to the fact that the STRTransformProvider is added to
> WebSphere's JCE provider list using Security.addProvider(provider) but is
> loaded using the WAR module's classloader. When an app is restarted, this
> classloader hangs around and causes issues because
> org.jcp.xml.dsig.internal.dom.DOMSubTreeData loaded by the new module
> instance's classloader is not considered an instance of the
> org.jcp.xml.dsig.internal.dom.DOMSubTreeData class loaded by the STRTransform
> instance. I tested this by modifying the source code and printing out which
> classloader had loaded the class. In the case where things work (first
> startup of the first application to use WSS4J) the classloaders are the same.
> In cases where things don't work the classloader of the DOMSubTreeData
> instance passed into the transform is different to the classloader of the
> DOMSubTreeData class itself. Similar result when trying from one application
> then another.
> This seems loosely related to https://issues.apache.org/jira/browse/WSS-82
> and
> http://bouncy-castle.1462172.n4.nabble.com/Bug-in-Cipher-class-td1465452.html.
> Seems there are problems running custom JCE providers on WebSphere (and IBM
> say they don't support custom JCE providers).
> Adding WSS4j to a higher level classloader causes all kinds of other errors
> to come up.
> Is there any way we can get this to work or are we WebSphere users out of
> luck? (Or am I just doing something horrible wrong?). I've already applied
> the fixes shown in https://issues.apache.org/jira/browse/WSS-273 (I got those
> errors before I got this one).
> [5/4/11 16:41:04:379 EST] 00000029 SystemErr R
> org.apache.ws.security.WSSecurityException: Signature creation failed; nested
> exception is:
> javax.xml.crypto.dsig.XMLSignatureException:
> javax.xml.crypto.dsig.TransformException:
> javax.xml.crypto.dsig.TransformException: java.lang.ClassCastException:
> org.jcp.xml.dsig.internal.dom.DOMSubTreeData incompatible with
> javax.xml.crypto.OctetStreamData
> [5/4/11 16:41:04:379 EST] 00000029 SystemErr R at
> org.apache.ws.security.saml.WSSecSignatureSAML.computeSignature(WSSecSignatureSAML.java:529)
> [5/4/11 16:41:04:379 EST] 00000029 SystemErr R at
> org.apache.ws.security.saml.WSSecSignatureSAML.build(WSSecSignatureSAML.java:155)
> ... servlet stack trace components ....
> [5/4/11 16:41:04:392 EST] 00000029 SystemErr R Caused by:
> javax.xml.crypto.dsig.XMLSignatureException:
> javax.xml.crypto.dsig.TransformException:
> javax.xml.crypto.dsig.TransformException: java.lang.ClassCastException:
> org.jcp.xml.dsig.internal.dom.DOMSubTreeData incompatible with
> javax.xml.crypto.OctetStreamData
> [5/4/11 16:41:04:393 EST] 00000029 SystemErr R at
> org.jcp.xml.dsig.internal.dom.DOMReference.transform(DOMReference.java:412)
> [5/4/11 16:41:04:393 EST] 00000029 SystemErr R at
> org.jcp.xml.dsig.internal.dom.DOMReference.digest(DOMReference.java:304)
> [5/4/11 16:41:04:393 EST] 00000029 SystemErr R at
> org.jcp.xml.dsig.internal.dom.DOMXMLSignature.digestReference(DOMXMLSignature.java:467)
> [5/4/11 16:41:04:393 EST] 00000029 SystemErr R at
> org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:361)
> [5/4/11 16:41:04:393 EST] 00000029 SystemErr R at
> org.apache.ws.security.saml.WSSecSignatureSAML.computeSignature(WSSecSignatureSAML.java:524)
> [5/4/11 16:41:04:393 EST] 00000029 SystemErr R ... 66 more
> [5/4/11 16:41:04:394 EST] 00000029 SystemErr R Caused by:
> javax.xml.crypto.dsig.TransformException:
> javax.xml.crypto.dsig.TransformException: java.lang.ClassCastException:
> org.jcp.xml.dsig.internal.dom.DOMSubTreeData incompatible with
> javax.xml.crypto.OctetStreamData
> [5/4/11 16:41:04:394 EST] 00000029 SystemErr R at
> org.apache.ws.security.transform.STRTransform.transformIt(STRTransform.java:267)
> [5/4/11 16:41:04:394 EST] 00000029 SystemErr R at
> org.apache.ws.security.transform.STRTransform.transform(STRTransform.java:122)
> [5/4/11 16:41:04:395 EST] 00000029 SystemErr R at
> org.jcp.xml.dsig.internal.dom.DOMTransform.transform(DOMTransform.java:147)
> [5/4/11 16:41:04:395 EST] 00000029 SystemErr R at
> org.jcp.xml.dsig.internal.dom.DOMReference.transform(DOMReference.java:409)
> [5/4/11 16:41:04:395 EST] 00000029 SystemErr R ... 70 more
> [5/4/11 16:41:04:395 EST] 00000029 SystemErr R Caused by:
> javax.xml.crypto.dsig.TransformException: java.lang.ClassCastException:
> org.jcp.xml.dsig.internal.dom.DOMSubTreeData incompatible with
> javax.xml.crypto.OctetStreamData
> [5/4/11 16:41:04:395 EST] 00000029 SystemErr R at
> org.apache.ws.security.transform.STRTransform.transformIt(STRTransform.java:163)
> [5/4/11 16:41:04:396 EST] 00000029 SystemErr R ... 73 more
> [5/4/11 16:41:04:396 EST] 00000029 SystemErr R Caused by:
> java.lang.ClassCastException: org.jcp.xml.dsig.internal.dom.DOMSubTreeData
> incompatible with javax.xml.crypto.OctetStreamData
> [5/4/11 16:41:04:397 EST] 00000029 SystemErr R at
> org.apache.ws.security.transform.STRTransform.transformIt(STRTransform.java:160)
> [5/4/11 16:41:04:397 EST] 00000029 SystemErr R ... 73 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
