Data grid authentication
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 JCEKS type
keystore to store the key pair, a private key and public key, and a secret key. The keystore has to
be the JCEKS 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.