It might be me. For SAML references, I switched to KeyIdentifier instead of wsse:reference because that's what a Metro web service was expecting, also that was in harmony with the relevant specifications, as discussed here[1].
To be two-thirds complete, another patch in WSS4J will need to be applied[2]. I'm trying to get CXF's stsclient to work with a Metro STS, and also have the subsequent security token received by the client to work with a Metro web service (basically, swap a Metro client with a CXF one here[3]). The older wsse:reference (at least when used to refer to SAML tokens) is not being accepted by Metro, and the Metro team appears to have the support of the relevant OASIS specifications (that probably postdate considerably the interopfest stuff we test against) that pretty much mandate KeyIdentifier in these situations (as discussed in [1]). Without this change, CXF's stsclient will not be able to work with a Metro STS, nor will the subsequent SOAP call be accepted by a Metro web service either. Granted, though, even with this change, it still won't work, as more work is needed as explained in [2] for WSS4J to understand the SOAP response returned by the Metro web service. (My changes only handle the successful acceptance of the sts request by the CXF stsclient and the subsequent SOAP request to the Metro web service, part three of getting WSS4J of understanding the Metro SOAP response with a SAML token using KeyIdentifier instead of wsse:Reference is still uncoded, as that's a bit outside my present skillset.) You can revert it in order to pass the tests (if that is indeed the problem), but you'll be back to square #1 of cxf's stsclient not being able to work with a Metro STS, greatly stunting its usefulness and harming the growth of SOAP web services in general. Next issue (since you work with RedHat): There's also a PicketLink STS -- I don't know what it is expecting for SAML assertions -- the modern KeyIdentifier or the bring-out-the-78rpm wsse:Reference, if the former, that would also speak against reverting the changes I made, if the latter, maybe I can get the Metro team to work with wsse:Reference but again the spec appears to be very much on their side. Glen [1] https://issues.apache.org/jira/browse/CXF-2894 [2] https://issues.apache.org/jira/browse/WSS-238 [3] http://www.jroller.com/gmazza/entry/metro_and_wstrust Sergey Beryozkin-5 wrote: > > All of those NoSuchMethodError exceptions have been probably caused by the > fact I was building sandbox projects depending on outdated 2.3-SNAPSHOT > views, so after removing the cxf artifacts from the maven repo I can the > exceptions gone. > > However, it does appear we have a regression in scenarios 9 and 10 : > > Scenario_9_IssuedTokenForCertificate_MutualCertificate11: Exception: > javax.xml.ws.soap.SOAPFaultException: An error occurred when verifying > security for the message. > Scenario_10_IssuedTokenForCertificateSecureConversation_MutualCertificate11: > Exception: javax.xml.ws.soap.SOAPFaultException: An error occurred when > verifying security for the message. > > Has anyone worked in this area recently ? I'm going to start looking into > it > as well... > > cheers, Sergey > -- View this message in context: http://cxf.547215.n5.nabble.com/Regressions-in-WS-Trust-10-interopfest-demo-tp2640748p2641132.html Sent from the cxf-dev mailing list archive at Nabble.com.
