Next is the <X509SubjectName>CN=John Doe</X509SubjectName> element, which contains the
distinguished name of the service requester — in our case, simply John Doe — and finally the
X.509 certificate itself:
The final stage of WS-Security processing is to validate the Web service requester’s digital certificate.
When using a digital certificate approach, each Web service requester must have a digital certificate
which a trusted Certificate Authority (CA) has signed. The definition of a trusted certificate authority
is outside the scope of this paper, but typically either an industry-accepted, 3rd-party certificate
authority (a company like VeriSign) performs this role, or the Web service provider takes on the role
of the certificate authority for the certificates that their application uses. If the latter approach is
used, use of the open source OpenSSL toolkit from Apache, or the basic digital certificate support
provided by WebSphere Application Server’s IKEYMAN utility is recommended.
In the initial rollout of our application, our customer chose to play the role of certificate authority.
As such, they created their own, self-signed CA certificate. Prior to any Web service interactions,
the Web service requester must provide the Web service provider with a certificate that they will use
in the application. Playing the certificate authority role, the Web service provider signs the certificate
and returns it to the Web service requester.
As described above, the Web service requester includes the CA-signed digital certificate in the
SOAP message. After the digital signature has verified the integrity of the message, the certificate
is extracted from the message and validated using the CA’s public key. Once the validity of the
certificate has been achieved, the Web service requester will have been authenticated and the
processing of the WS-Security portion of the message will be complete. The owner has successfully authenticated to the receiver.
Note that if, at a later date, our service provider chooses to relinquish the role of the certificate
authority and use an industry-accepted, trusted, 3rd-party certificate authority, the logic of our
validation code does not need to change. In this scenario, prior to using the Web service, the Web
service requester will need to get a certificate issued by a trusted certificate authority. The service
requester will place this 3rd-party certificate in the SOAP message. When the service provider is
validating the digital certificate, instead of using their self-signed CA key, the public key of the 3rdparty
CA will be used. In this scenario, the service provider has established a trust relationship with the 3rd-party certificate authority, and the CA will be trusted to adequately authenticate users
before issuing certificates to them.