XML signatures are very sensitive to any changes in the xml. I am wondering if there is any kind of DOM/SAAJ/SOAP processing outside of Picketlink realm is messing up things. Is there any kind of marshalling/unmarshalling done? This can be one cause of problem.
Ensure that you are using apache xml security rather than the xml security implementation in the JDK. You have to use the endorsed mechanism.
You were right that it XML validation is failing due to picketlink using sun jdk's xml security implementation
I have attached the additional debug info where it is clear that the class being used is com.sun.org.apache.xml.internal.security part of JDK6. (I've verified using -verbose:class that xml sec jar is loaded from JDK/jre/lib/rt.jar)
I verified that when we start JBOSS it modifys java.endorsed.dirs to <JBOSS_HOME>\lib\endorsed
DEBUG [ServerInfo] sun.boot.library.path: C:\Java\jdk1.6.0_01\jre\bin
DEBUG [ServerInfo] jboss.home.url: file:/E:/J2EEServers/jboss-5.1.0.GA/
DEBUG [ServerInfo] java.version: 1.6.0_01
DEBUG [ServerInfo] java.util.logging.manager: org.jboss.logmanager.LogManager
DEBUG [ServerInfo] user.timezone: Asia/Calcutta
DEBUG [ServerInfo] jboss.server.home.dir: E:\J2EEServers\jboss-5.1.0.GA\server\default
DEBUG [ServerInfo] jgroups.bind_addr: 127.0.0.1
DEBUG [ServerInfo] sun.arch.data.model: 32
DEBUG [ServerInfo] java.endorsed.dirs: E:\J2EEServers\jboss-5.1.0.GA\lib\endorsed
Hence i have to place apache xmlsec in <JBOSS_HOME>\lib\endorsed
I downloaded xml-security-bin-1_4_3.zip from apache repository
xmlsec-1.4.3.jar has a dependency on commons-logging.jar
If I place both these jars in <JBOSS_HOME>\lib\endorsed JBOSS does not start.
2010-05-11 11:35:49,810 ERROR (main) Error installing to Create: name=TransactionManager state=Configuredjava.lang.ExceptionInInitializerError at com.arjuna.ats.internal.arjuna.objectstore.ShadowingStore.(tsLogger.java:58)
Tried to fix this issue using two approaches system propert and commons-logging.properties.
But the above problem persists.
Pl let me know how i can make JBOSS use apache xmlsec while using JBOSS WS Metro?
server.log.zip 5.1 K
Thanks that is the difference. I hope Stefan uses JBOSS WS Metro and tries to help me with a solution.
Can you also pl paste a picture or attach the eclipse .classpath file?
I configured a new instance of JBOSS with native but having trouble executing the client.
I read in one your posts you addressed me as he ... i'm a lady from India
Thanks & regards,
Has anyone done this JBossWS-Metro testing yet? I have experienced many of the problems mentioned in this thread while trying to experiment with PicketLink STS on system that has: JBoss AS 5.1 (JDK 6 build) with JBoss ESB 4.8 and JBossWS-Metro 3.2.2. I believe the problems must be related to either the JDK 6 build or JBossWS-Metro because even the simplest WSTrustClientTest example does not work "out of the box" without hunting problems down (as others have documented previously in this thread). The installation itself is sound, all is well, verified the installation, other services deploy and execute properly, etc. Only problems at the moment are when working through the PicketLink experiments.
In my present state, using the latest CR3 jars/wars available from the nexus site, I can obtain a token using an "Issue" request, but I cannot validate, cancel, or renew the token using their associated requests. I have been studying the exception stack and the source code, and the problem is that the token element name and namespace is coming back as "null" and a SecurityTokenProvider cannot be found for "null:null". I suspect this is related to StAX versus DOM manipulation of the message, etc, but I don't know the source code well enough to trace this down. Tracing confirms that the token element is present, so something is going on with the message somewhere in one of the parsers or maybe in the JAXB bindings. I have some experience diagnosing custom binding problems when xsd:any elements are involved in JAXB, but I would think that would be a universal problem if that were the cause (should not be unique to the JBossWS-Metro environment).
For reference, I have tried both the CR3 release from nexus and the CR3.SNAPSHOT release that contains the WS-Trust namespace fix (PLFED-63). In the latter version, I have to change my namespace reference in the requests, but I get the same error (token is null) once I do that.
At any rate, if anyone ideas about where to look, or something else to try, I would greatly appreciate it, and I'm willing to help.
Understood, but Stefan said that was being tested, and I am motivated to contribute in this regards because we need Metro for other purposes. So aside from trying to see if these problems sounded familiar to anyone, I was also trying to find out if others have done anything in this area.
I'm hoping that those interested in Metro support will be interested in participating in a new thread so we can share details about what works, what does not work, what progress has been made, etc. So was hoping to hear from Stefan to learn more about what has been learned so far, and then see how other interested developers can help.
I have unfortunatelly been busy with other issues and didn't have the time yet to look into the validation failure that is seen on metro integration. In the past we've had some issues with JAXB marshalling/unmarshalling processes messing with namespaces. Of course, any change to the XML document will result in a validation failure by the STS.
As you said, it may have to do with Stax versus DOM so we have to find out exactly where the document is getting tempered. Is it right after the STS marshalls the response? Is it after the client code unmarshalls it? What if we just use JDK6 JAX-WS classes in the client side (that is, no JBossWS classes)?
Either way, the STS has been tested with the Native stack but ideally we must be able to run it on top of CXF or Metro, have automated builds and tests on Hudson for all stacks, improve documentation, etc. Thus it is very important that you and other community members are willing to help by writting some code, reporting bugs, investigating issues, writting wiki articles that may help others deploy a particular configuration, etc. I've seen the discussion you started in the development forum and I want to ask you to post your findings there too. I will add my own considerations later this week.
I was owing you a reply about the JBossWS Metro integration. I've run some STS tests (JBAS 6.0.0.M3 and JBoss WS-Metro 3.3.1) here using Metro as the WS stack and the validation worked just fine. I used the STSClient API for both issuing and validating the security token. As Ray Cardillo stated in this thread (http://community.jboss.org/thread/152427?tstart=0), he was also having signature problems when using Metro stack and it turned out it was his client code messing with the assertion.
So you have to be absolutely sure your client app is not parsing the assertion somehow before you include it in the validation request. If the error persists, I would recommend using the STSClient API to send the WS-Trust requests.