The client must have the WSDL (location) of the STS (as well as service + port QNames).While this type of configuration works well, it has a few drawbacks:
The following configuration (see here for a concrete example), specifies the WSDL location of the STS, as well as the Service + Port QNames to use, as well as some additional security configuration:
#Apache directory studio incompatible jvm how to#
How does it know how to contact the STS? Typically, this is defined in an STSClient bean. So the CXF client will know that it must get a SAML 1.1 token from an STS when it sees the above policy, and that it must present the STS with a X.509 Certificate, so that the STS can embed it in the issued token. In addition, the token must include the client's PublicKey, the corresponding private key of which must be used to secure the request in some way (SOAP Message Signature, TLS client authentication): The following IssuedToken policy fragment (see here for a concrete example) tells the client that it must include a SAML 1.1 token in the request. The service provider can require that a client retrieve a security token from an STS by specifying a WS-SecurityPolicy IssuedToken policy (for example, in the WSDL of the service). In this article, we will explore different ways of configuring the client with details of how to communicate with the STS, as well as how the service provider can provide these details to the client. A common SOAP security scenario is where a service provider requires that a client must authenticate itself to the service, by geting a token from an STS and including it in the service request. Apache CXF provides a Security Token Service ( STS), which can issue (as well as validate, renew + cancel) security tokens using the WS-Trust protocol.
0 kommentar(er)
