The scenario: Idp/STS: Microsoft ADFS 2.0 Service provider: Shibboleth SP CXF: 2.7.8
The client logs on (with a domain username/pwd) to the web site. Once logged on the user can call a webservice that is WS-trust configured. Using the ADFS policy/endpoint “../adfs/services/trust/13/usernamemixed” it works fine, although it is just a password set between the web service and the sts client. Using SoapUI and calling the STS directly (the usernamedmixed binding) but with the domain credentials will actually give me a proper SAML assertion. When I change the sts client to any one of these policies/endpoints …/issuedtokensymmetricbasic256 or …/issuedtokenassymetric256 the sts client doesn’t seem to be able or willing to connect to the STS to retrieve the security token/SAML assertion. So the soap message to the web service will not contain any security token, hence a "Response-Code: 500” back from the web service. When I instead invoke the: stsClient.requestSecurityToken(); The client to ends up in a loop that will exhaust all of the memory = stack overflow. There is no apparent error message either. Seems like that the state machine is confused by, for me, some unknown reason. Nothing is ever sent towards the STS according to Fiddler at least. Could there be any issues with reading the WSDL from the ADFS (we have had to modify the KeyValueToken tags due to that CXF did not like to parse it "straight out of the box") making the endpoint address of the STS is a problem? Should´nt we at least see a connection attempt or endpoint address error message? Should the Shibboleth SP in some way be invoked to request the token? Why the loop? A lot of questions but no solid leads to work with right now. /Mike -- View this message in context: http://cxf.547215.n5.nabble.com/Issue-with-WS-Trust-using-security-tokens-SAML-assertions-tp5744142.html Sent from the cxf-user mailing list archive at Nabble.com.
