Hi Colm, After hooking up the debugger, I see that the SAMLTokenProvider is actually being registered as a token provider. While debugging through the request, I added a watch to the incoming tokenType parameter.
>From the watch, inside the SAMLTokenProvider.canHandleToken(String) method I get: *"tokenType" http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1\n\t\t\t\t\t\t\t\t\t\t * which would definitely be the issue since the tokenType is compared using .equals(...) to the straight up trimmed constant. This is also an issue for the KeyType as well, with the whitespace causing the comparison to fail. I'm unsure at this time whether or not the Address tags would have the same issue, but fixed them for safety's sake. Should the TokenType and KeyType not be trimmed at some point in the CXF code before being compared against the various key and token type constants? I have attached the WSDL Policy snippet which causes this issue, as well as a corrected snippet. http://cxf.547215.n5.nabble.com/file/n5646972/wsdl-policy-snippet-bad.txt wsdl-policy-snippet-bad.txt http://cxf.547215.n5.nabble.com/file/n5646972/wsdl-policy-snippet-works.txt wsdl-policy-snippet-works.txt Thanks for all the help Colm & Oliver it was much appreciated, Dan. -- View this message in context: http://cxf.547215.n5.nabble.com/No-Token-Provider-for-Saml-Token-V1-1-tp5643904p5646972.html Sent from the cxf-user mailing list archive at Nabble.com.
