This article describes the necessary steps in order to run PicketLink 2.1.x in JBoss Application Server 7.1.x.
Problems and Solutions
Most of the problems described in this article are related with the version upgrade of org.apache.santuario.xmlsec module. Until JBoss AS 7.1.0 the version used for xmlsec was 1.4.5. With the JBoss AS 7.1.1 release this version was upgraded to 1.5.1.
There's been some refactoring in Santuario 1.5 which imply changes to be applied on the JBoss AS modules.
PicketLink relies on apache xmlsec (santuario) to get xml encryption.
Problem 1: XMLSEC ClassNotFoundException and ClassCastException when deploying applications
What this problem impacts ?
- Download of PicketLink IDPs, SPSs, STS and PDP;
When deploying PicketLink applications (idp, sp, sts and pdp) some exceptions are raised claiming for classes (ClassNotFoundException) or cast problems (ClassCastExceptions). Althought PicketLink 2.1.x was updated to use xmlsec 1.5.1.
The solution for this issues are described in the following thread and JIRA:
Users need to use JBoss AS 7.1.2 (git clone and build from scratch) or apply the changes associated with the JIRA above. These changes are related with problems in both javaee.api and javax.api modules.
This problem is already solved and is fixed for future AS7 releases.
Problem 2: ClassNotFoundException: com.sun.org.apache.xml.internal.security.transforms.implementations.TransformBase64Decode
What this problem impacts ?
- Use of PicketLink STS;
When using digital signatures a ClassCastException is raised claiming for a class com.sun.org.apache.xml.internal.security.transforms.implementations.TransformBase64Decode.
The first solution for this was make the change bellow at the javax.api module:
<module xmlns="urn:jboss:module:1.1" name="javax.api"> <dependencies> <system export="true"> <paths> ... <path name="com/sun/org/apache/xml/internal/security/transforms/implementations"/> <!-- This line was added --> </paths> </system> </dependencies> </module>
The second solution and the best one, because require no changes in AS7 core modules, is change the order of the dependencies for the org.picketlink module making the javax.api be the last dependency and not the first one:
<module xmlns="urn:jboss:module:1.1" name="org.picketlink"> <resources> <resource-root path="picketlink-jbas7-2.1.0-SNAPSHOT.jar" /> <resource-root path="picketlink-core-2.1.0-SNAPSHOT.jar" /> </resources> <dependencies> <module name="javax.security.auth.message.api" /> <module name="javax.security.jacc.api" /> <module name="javax.transaction.api" /> <module name="javax.xml.bind.api" /> <module name="javax.xml.stream.api" /> <module name="javax.servlet.api" /> <module name="org.jboss.common-core" /> <module name="org.jboss.logging" /> <module name="org.jboss.as.web" /> <module name="org.picketbox" /> <module name="javax.xml.ws.api" /> <module name="org.apache.log4j" /> <module name="org.apache.santuario.xmlsec" /> <module name="org.jboss.security.xacml" /> <module name="javax.api" /> <!-- Moved to be the last dependency--> </dependencies> </module>
This fix must be done in AS 7.1.2 in order to have digital signatures working.
Problem 3: Xalan Issues
What this problem impacts ?
- Use of PDP
When using the PDP that is shipped with PL, you may see the following problem:
rg.picketlink.identity.federation.core.saml.v2.util.DocumentUtil.getNodeFromSource(DocumentUtil.java:480) [picketlink-core-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT] ... 40 more Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at org.apache.xerces.dom.AttrNSImpl.setName(AttrNSImpl.java:106) at org.apache.xerces.dom.AttrNSImpl.<init>(AttrNSImpl.java:75) at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(CoreDocumentImpl.java:2134) at org.apache.xerces.dom.ElementImpl.setAttributeNS(ElementImpl.java:657) at org.apache.xalan.xsltc.trax.SAX2DOM.startElement(SAX2DOM.java:148) at org.apache.xml.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:206) at org.apache.xml.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:279) at org.apache.xml.serializer.ToXMLSAXHandler.startElement(ToXMLSAXHandler.java:646) at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:138) at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:274) at org.apache.xalan.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:576) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:630) ... 42 more
What we have found out (still talking to JBoss AS team about it) is that this error goes away if the Apache Xalan 2.7.1 library is downloaded from apache website and added to the xalan module in JBoss AS 7.1.2
You can download the functional Apache Xalan library from this article. See the attachments.
Some discussion with Jason Greene (JBoss AS team)
(03:55:08 PM) asaldhan: Nihility: hey do u know what is the xalan-jboss version? (03:55:19 PM) asaldhan: Nihility: fixed cl issues? (03:55:27 PM) Nihility: yeah (03:55:31 PM) Nihility: cl issues (03:56:31 PM) asaldhan: Nihility: there is a bug we are encountering which goes away if we use the apache version (03:56:42 PM) asaldhan: Nihility: let me add it to the article we have and tell you. (04:00:17 PM) asaldhan: Nihility: problem 3 in https://community.jboss.org/wiki/PL21xInAS71x (04:10:57 PM) Nihility: asaldhan: can you test using the jdk version of xslt (04:11:15 PM) Nihility: asaldhan: the official apache version defaults to non-compiled translets (04:11:26 PM) Nihility: asaldhan: but ours and the jdks does compile (04:11:40 PM) asaldhan: Nihility: it is possible that the issue we are seeing may be one of rare cases (04:12:12 PM) Nihility: so it could be a compiled translet bug or something (04:32:13 PM) asaldhan: Nihility: my team member, pedro tried with the JDK version, the error exists. (04:32:52 PM) Nihility: asaldhan: ok so there is a hack you can do (04:33:13 PM) Nihility: asaldhan: the actual implementation which is used is selected by META-INF/services/javax.xml.transform.* (04:33:39 PM) Nihility: asaldhan: you could provide the ones that do not use compiled translets (04:33:49 PM) Nihility: asaldhan: and stick them in your application (04:34:28 PM) asaldhan: Nihility: in our case, few users use the PDP. So the workaround is to just download the library attached to the article.