roband915 wrote > Nice work Colm! I´ll try It out right away for sure! > But when using the "ws-security.sts.client" again then I suspect that an > old problem will occur. The "wsdlLocation" will not work because I don't > have two STS's. Only ADFS and that uses only ws-mex. So probably I will > recieve the StackOverflow-exception that you helped me with earlier in > this thread. > > /Robert
In a previous post, you indicated that there were in fact two STS instances? roband915 wrote > The somewhat complex environment consist of the web application (on > Tomcat) that is configured using a proxy Shibboleth SP (on an Apache) and > this in turn is configured to request a SAML-assertion from the ADFS. The idea here is that the CXF client uses WS-MEX (via the service WSDL) to get the WSDL of the ADFS STS instance. This in turn has an IssuedToken policy, so the CXF client needs to get a token from "some other" STS instance and send it in turn to the ADFS STS. So the STSClient configuration you configure via "<entry key="ws-security.sts.client">..." is the STS that you get the first IssuedToken from. It is assumed that you know the WSDL of this STS instance. You also need to set the property I mentioned previously to ensure that CXF ignored the "ws-security.sts.client" configuration for the ADFS STS communication (via WS-MEX). Colm. -- View this message in context: http://cxf.547215.n5.nabble.com/Issue-with-WS-Trust-using-security-tokens-SAML-assertions-tp5744142p5745822.html Sent from the cxf-user mailing list archive at Nabble.com.
