Java Web Services: ws-security that do not use client certificates

Many ws-security configurations require that both the client and the server use the Public/private key pair to guarantee the identity of the public key using the X.509 certificate. This is the most widely used technique for message signing or encryption using Ws-security, and it has some advantages. In particular, client certificates provide stricter client authentication and tighter signature guarantees for requests. But it also has drawbacks, including the performance overhead of asymmetric encryption and the cumbersome management of each client acquiring and maintaining certificates.

"Ws-secureconversation Performance" describes ws-secureconversation-while still using client certificates-how symmetric encryption is used to reduce the performance overhead of continuous exchange of messages between clients and servers. In this article, you will see how you can break the current status of requiring client certificates in common ws-security and ws-secureconversation exchanges.

Do not require encryption and signing of client certificates

It is easy to sign and encrypt messages using asymmetric encryption and public/private key pairs (at least conceptually simple). As described in "Axis2 ws-security signature and encryption," You can use your private key to sign the message and encrypt the message using the recipient's public key. Anyone who gets your public key (typically packaged in a X.509 certificate) can verify the signature that you generate using the private key, but only the owner of the corresponding private key can decrypt the message that is encrypted with the public key.

If the client does not have a public/private key pair, you cannot use the complete asymmetric encryption technique. Another method is symmetric encryption, but when using symmetric encryption, you must have a key that only the parties involved in the message exchange know. How can you create such an encryption key?

The technique used by ws-security is to have the client generate an encryption key value, then encrypt it using asymmetric encryption and the server public key, and embed it in a <xenc:EncryptedKey> token's request message. The client can use this secret key (or, more securely, use a separate key generated by the secret key) to encrypt and/or sign the request message, and the server can do the same with the response message. The server does not need to send the secret key back to the client because the client already owns the secret key.

Ws-securitypolicy Configuration

The Ws-policy/ws-securitypolicy configuration of symmetric encryption using client-generated keys is simple. Listing 1 shows the version that is used in this article. This policy uses the client-generated secret key to specify how the message body is encrypted in two directions.

Listing 1. Ws-policy for encrypting all message bodies

<wsp:policy wsu:id= "symmencr"
xmlns:wsu= "Http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp= "Http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsaw= http://www.w3.org/2006/05/ ADDRESSING/WSDL "
xmlns:sp=" http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
<wsp: Exactlyone>
<wsp:all>
<sp:symmetricbinding>
<wsp:policy>
<sp:protect 　　　　　　　　Iontoken>
<wsp:policy>
<sp:x509token sp:includetoken= ".../includetoken/never"
<wsp:policy>
<sp:requirederivedkeys/>
<SP:REQUIRETHUMBPRINTREFERENCE/>
<sp:wssx509v3token10/>
</wsp:policy>
</sp:x509token>
</ws 　　　　　　　P:policy>
</sp:protectiontoken>
<sp:algorithmsuite>
<wsp:policy>
<sp:basic128rsa15/>
</wsp:policy>
</sp:algorithmsuite>
<sp:layout>
<wsp:policy>
<sp:strict/>< br> </wsp:policy>
</sp:layout>
</wsp:policy>
</sp:symmetricbinding>< br> <sp:wss11>
<wsp:policy>
<sp:mustsupportrefkeyidentifier/>
<sp:mustsu Pportrefthumbprint/>
<sp:mustsupportrefencryptedkey/>
</wsp:policy>
</SP:WSS11&G T
<sp:encryptedparts>
<sp:body/>
</sp:encryptedparts>
</wsp:all>
& Lt;/wsp:exactlyone>
</wsp:policy>

The <sp:SymmetricBinding> assertion in Listing 1 policy is to configure code that uses symmetric encryption with a secret key. The embedded <sp:X509Token> assertion indicates that a X.509 certificate will be used to protect the transmission of the secret key (that is, to encrypt the secret key transmitted), which is a certificate that is identified by using a fingerprint reference (essentially a hash value). The client-generated secret key is implicitly using the <sp:SymmetricBinding> assertion with the <sp:X509Token> protection token. Other policy assertions specify the details of the cryptographic algorithm and the necessary attributes, while the final <sp:EncryptedParts> assertion represents the SOAP body that will be encrypted using a secret key.

As you can see in previous articles, run-time parameters for security processing, such as key saving and passwords, must be defined in a way that is not implementation-independent. Here, these parameters are simple: The client needs to access the trusted store that contains the server certificate, and the server side needs to access the key store that contains the private key that matches the public key in the certificate. Read this series of articles to see how parameters are passed between protocols.