In the previous two sections, HTTP basic and digest authentication mechanisms are described. These mechanisms can be used to authenticate a user and then perform certain operations: invoking services, accessing file systems, etc. But these mechanisms do not provide message privacy. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols were designed to help protect the privacy and integrity of data while it is transferred across a network.
If the WSO2 SOA Enablement Server uses the HTTPS transport protocol, it always has its own identity and the X509 certificate that was generated during installation. It can, therefore, require mutual authentication from a client (this option is global and applies to all services). In this case, clients have to authenticate to provide their identity. The information about client identity is then stored into the org.idoox.security.server.ReceivedCredentials instance.
![]() | Note |
---|---|
If the server does not require client authentication, the client does not need to be authenticated. The option "needClientAuth" on the server side is global; that is, it is enforced for all services running on the WSO2 SOA Enablement Server. |
Steps Needed to Use SSL Authentication.
On the client side:
Create a client account using UserStoreTool
Set security provider to SSL.
Authenticate with username, password and SSL security provider
On the server side:
Create a user entry:
Save the client certificate provided by the client side into the user store entry, identified by the user name, using the UserStoreTool. This step may be done from the client side in the remote mode. The certificate authority, which signs the certificate, must be trusted. That is, its certificate chain (or root certificate) must be stored in the server-side key store. You can use PStoreTool to make the CA certificate trusted on the server side.
Do not change the accepting security provider's setting of SSL.
Set the option needClientAuth of HTTPS transport to true.