cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@gmail.com>
Subject Re: Regressions in WS-Trust 10 interopfest demo
Date Thu, 19 Aug 2010 15:45:37 GMT

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.

Mime
View raw message