WSS4J uses the Crypto interface to provide a pluggable way of retrieving and converting certificates, verifying trust on certificates etc. A previous blog post described how verifying trust on PublicKeys was also moved into the Crypto interface for WSS4J 1.6.
WSS4J 1.5.x shipped with a Crypto implementation based around a KeyStore, which was configured via a properties file. A previous blog post describes some changes that were made to the property config names, as well as describing the separation between a keystore and a truststore. The code was also modified as part of this work so that the Crypto instance can be instantiated as normal, and not just via a properties file.
A big issue with the Crypto interface is that it was too closely tied in to the Java KeyStore objects which back the Merlin implementation. This makes it difficult to subclass the interface, for example to write a Crypto implementation that just stores an array of X509Certificates for signature verification, or to write a client to obtain the X509Certificates from a remote store (e.g. XKMS).
The fix for WSS-269 attempts to address these shortcomings. All of the KeyStore specific method names and arguments have been abstracted. All of the methods which locate X509Certificates have been consolidated into a single method, which takes an argument a new class which supplies the data (e.g. a SHA1 thumbprint of the certificate) used to retrieve the certificates. The abstract functionality (i.e. KeyStore independent) has been moved into the CryptoBase class, so implementation can just subclass this to avoid having to re-implement all of the generic methods in the Crypto interface.
WSS4J now ships with another Crypto implementation. CertificateStore holds an array of X509Certificates that can be used out of the box, for signature verification, or encryption. The PrivateKey methods are not implemented, so it cannot be used for decryption, or signature creation. However, CertificateStore could easily be subclassed.
No comments:
Post a Comment