Hi Rich,



I agree that the current behaviour on the receiving side is not ideal.
The problem is that the SAMLTokenProcessor has no way of knowing for
sure whether the SAML assertion is signed or not, and so it defaults to
adding it to the results as an unsigned token. The only way we know for
sure that it's signed is in the SignatureProcessor, which will normally
be called after the SAMLTokenProcessor has been invoked. It's a tricky
problem to resolve, I'll have a think about it over the next while.



Colm.



________________________________

From: R1ch [mailto:rich.kuali@gmai...]
Sent: 27 July 2009 17:08
To: wss4j-dev@ws.a...
Subject: checkReceiverResults() in WSHandler and signed token



I have a working service configured in CXF that sends an outgoing signed
SAML token. While configuring a client interceptor (WSS4JInInerceptor in
CXF) I was getting some exceptions. I noticed that the interceptor calls
checkReceiverResults() in WSHandler.java and my actions were not
matching the wsResults in the vector. After further digging I found that
in SAMLTokenProcessor handleToken() the vector wsResults is added with

returnResults.add(
            0,
            new WSSecurityEngineResult(WSConstants.ST_UNSIGNED,
assertion)
        );

Is there a reason why WSConstants.ST_SIGNED is not also used?


I ask because when I configured the client I used the corresponding
action WSHandlerConstants.SAML_TOKEN_SIGNED but this does not work and I
had to
change it to WSHandlerConstants.SAML_TOKEN_UNSIGNED.  The CXF
interceptor has and ignore actions flag which by passes this check. Is
it a ws-sec
specification violation not to check these results?

thanks