You can use the secure token manager plug-in to enable
server-to-server authentication, which requires you to implement
the SecureTokenManager interface.
The generateToken(Object) method takes an object protect,
and then generates a token that cannot be understood by others. The
verifyTokens(byte[]) method does the reverse process: it converts
the token back to the original object.
A simple SecureTokenManager implementation uses a simple
encoding algorithm, such as a XOR algorithm, to encode the object
in serialized form and then use corresponding decoding algorithm to
decode the token. This implementation is not secure and is easy to
break.
WebSphere® eXtreme
Scale default implementation
WebSphere eXtreme
Scale provides an immediately available implementation for this interface.
This default implementation uses a key pair to sign and verify the
signature, and uses a secret key to encrypt the content. Every server
has a JCKES type keystore to store the key pair, a private key and
public key, and a secret key. The keystore has to be the JCKES type
to store secret keys. These keys are used to encrypt and sign or verify
the secret string on the sending end. Also, the token is associated
with an expiration time. On the receiving end, the data is verified,
decrypted, and compared to the receiver secret string. Secure Sockets
Layer (SSL) communication protocols are not required between a pair
of servers for authentication because the private keys and public
keys serve the same purpose. However, if server communication is not
encrypted, the data can be stolen by looking at the communication.
Because the token expires soon, the replay attack threat is minimized.
This possibility is significantly decreased if all servers are deployed
behind a firewall.
The disadvantage of this approach is that the WebSphere eXtreme Scale administrators
have to generate keys and transport them to all servers, which can
cause security breach during transportation.