Hi Dan, Ok I've fixed this issue in the STS. One note on your WSDL - the Claims Element won't get copied through to the request unless it is a child element of RequestSecurityTokenTemplate as in this example:
http://svn.apache.org/viewvc/cxf/trunk/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/claims/DoubleIt.wsdl?view=markup Colm, On Tue, Apr 17, 2012 at 5:28 PM, DTaylor <[email protected]> wrote: > 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. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
