STS fails to validate tokens when JBossWS-Metro is used

[sguilhen]

When PicketLink STS is deployed on top of JBossWS-Metro stack, all issued tokens fail the XML digital signature validation. The XML document is getting tempered after the token is generated and this of course causes the signature to become invalid.

I'm starting this thread to record our findings and discuss the possible solutions.

A Jira has already been flagged: https://jira.jboss.org/browse/PLFED-74

[raycardillo]

I have some progress to report - mostly good news.  I don't think anyone will have problems starting with CR4 as long as they are using a "properly configured" JBossWS-Metro environment, and assuming there aren't any regressions.  From my experience, I can verify that the key factors were issues that have already been discussed in the previous thread.  In particular, if you are using JDK 6, it is best to use special JDK 6 build of JBoss AS 5.1 that already has the endorsed libs.  I also believe there were some source code changes that were important (probably PLFED-60 and PLFED-63).

At any rate, just to document my success, I was able to perform an Issue and Validate using soapUI (instead of the test client project) with JBoss AS 5.1 (JDK 6), JBoss ESB 4.8, JBossWS-Metro 3.2.2, and the PicketLink STS with PicketLink-Federation 1.0.3.CR3.SNAPSHOT.  The only problem I encountered ended up being something that Anil already warned about in one of his previous responses.  When using something like soapUI, or your own custom client, you have to realize that portions of the message are digitally signed, and because WS-Trust uses <xsd:any> heavily with "mixed" content, the contents of the Assertion element must not be changed in any way that would change the digital signature.  For example, whitespace between tags matters with a "mixed" content model.  That is quite easy to avoid once you understand this, but it was tricky "on my eyes" because it looks like it's semantically equivalent XML, but will produce a different signature after it was pretty printed (for example).  Once I realized this (after much debugging) it was easy to fix by simply making sure that the <Assertion> element from the Issue response was unaltered when copied into the <ValidateTarget> for the Validate request message.

---

Based on my experience with this, I do have a suggestion for improvement regarding the handling of the token extraction on the request messages (e.g., Validate, Renew, Cancel).  The following error was the cause for most of my debugging frustrations...

When the digital signature problem is within the <Assertion> element, a reasonable exception response is returned explaining that the digital signature did not match.  No problems there.  So for example, if you change a timestamp in the assertion, or add whitespace after the <Assertion> element, you will get an error like that.  However, if the error happens within the <ValidateTarget> element, we just get an exception that is very misleading saying that the SecurityTokenProvider cannot be found for null:null because the parser got a null node back.  Digging deeper, the source of this problem is that the code being used to extract the contents of the <ValidateTarget> element simply asks for the first item, which can be whitespace or plain text with a "mixed" content model.  It should use the same node finding helper that is used in other areas of the code to walk through the nodes looking for the <ValidateTarget> element.  Furthermore, if the node still ends up being null, it would be better to state that in an exception meant to help the user understand that, instead of making it an issue relating to SecurityTokenProvider.

I would like to contribute to the project just so I can get some attribution for the fix.    So if you don't mind giving me committ access, I would be glad to help if you contact me offline and tell me how you want me to proceed.

[anil.saldhana]

Ray,  man, you have baffled us with this amazing discovery. Looks like you made my memorial day weekend here in the US.  This is what I like about PicketLink community.  We build, complain, test, contribute together. Hail Open Source!!!

By the way, I recently made this article on contributions:  http://community.jboss.org/wiki/ContributionsCheckListforPicketLink

Once you sign the CLA, give me your jboss.org username with a private message and I will ensure that you have the commit rights.

ALSO, PLEASE RAY, I BEG YOU TO DOCUMENT YOUR DISCOVERY THROUGH A WIKI ARTICLE FOR ALL THE POOR SOULS WHO WILL GET LOST IN THE FUTURE WITH JBOSSWS-METRO/PICKETLINK.

(I made the above in caps to let you not forget it.   )

Welcome to PicketLink, Ray.