SSO using LTPA on IBM WebSphere servers (Part1)

/ / Architecture, Blog, DevOps, Digital Development en, Document Management
The DARA-Medieval Aragonese Documents project was presented today
Alfresco - Exporting a whole site from Alfresco 4.2.c to Alfresco 5.0.c

On many occasions we have to create a Single Sign On (SSO) to allow user authentication in several apps or servers without having to reenter their credentials for each of them. The most common scenario is that in which a central app is deployed and it manages authentications by generating a single token at the initial access, and then requests verification each time the user switches from one context to another.

As well as the possibility of applying the above solution in IBM WebSphere Application Servers, hereafter referred to as WebSphere, we have a token-based system that any app deployed in WebSphere servers is capable of generating and validating and which is called Lightweight Third-Party Authentication (LTPA). This system is used by the IBM WebSphere Portal for user authentication. The portal generates the token and sends it to the user as a cookie http that is validated upon each request.


Token LTPA

The LTPA token is normally sent in Base64 encryption. For example, this is the token from an IBM WebSphere Portal:




As you can see immediately it is string in Base64. More specifically it is the Base64 of the result of encrypting user information with a 3DES algorithm and the keys configured in the server (this point will be discussed later on). After decoding the token we get:




Which will always include the token expiry, the user name and a digital signature, and can also include extra information, particularly in the more modern versions of the token. The digital signature is generated with a SHA-1 hash and RSA encryption with 1024-bit keys on users’ identifying data, guaranteeing their identity.

To be able to perform encryption operations in different servers, IBM Websphere provides a mechanism for exporting keys, enabling them to be easily shared between the SSO nodes from the administration console in: Security – Global Security – LTPA :


Gestión de claves LTPA en IBM WebSphere Application Server

Gestión de claves LTPA en IBM WebSphere Application Server


Decoding the LTPA token

Decoding the token can be useful to get a better understanding of how the system works or to quickly check the format of locally generated tokens, however, in the case of apps deployed in WebSphere Application Servers there are classes that are supplied by the server itself which carry out generation and validation.

To decode an LTPA token you need the set of shared keys of the servers that can be obtained from the administration console as shown in the previous point. When you export the keys you will be asked for an export key that will be used to encrypt the keys that the file contains. The file generated has the following format:


#IBM WebSphere Application Server key file
#Wed Nov 26 13:23:12 CET 2014 Nov 26 13\:23\:12 CET 2014\=\=


Property names are self-descriptive but remember that the keys are encrypted by the password requested upon export. To get the token encryption key you have to decode the property content “”. This can be done via the following function (obtained from Alfresco LTPA authentication filter):


	private static byte[] getSecretKey(String ltpa3DESKey, String ltpaPassword)	throws Exception {

		MessageDigest md = MessageDigest.getInstance("SHA");
		byte[] hash3DES = new byte[24];
		System.arraycopy(md.digest(), 0, hash3DES, 0, 20);
		Arrays.fill(hash3DES, 20, 24, (byte) 0);
		final Cipher cipher = Cipher.getInstance(DES_DECRIPTING_ALGORITHM);
		final KeySpec keySpec = new DESedeKeySpec(hash3DES);
		final Key secretKey = SecretKeyFactory.getInstance("DESede").generateSecret(keySpec);
		cipher.init(Cipher.DECRYPT_MODE, secretKey);
		byte[] secret = cipher.doFinal(Base64.decode(ltpa3DESKey.getBytes()));

		return secret;


Once you have the token encryption key, you can decode it with the following functions (obtained from Alfresco LTPA authentication filter):


	private static byte[] decrypt(byte[] token, byte[] key, String algorithm)
			throws Exception {
		SecretKey sKey = null;

		if (algorithm.indexOf("AES") != -1) {
			sKey = new SecretKeySpec(key, 0, 16, "AES");
		} else {
			DESedeKeySpec kSpec = new DESedeKeySpec(key);
			SecretKeyFactory kFact = SecretKeyFactory.getInstance("DESede");
			sKey = kFact.generateSecret(kSpec);
		Cipher cipher = Cipher.getInstance(algorithm);

		if (algorithm.indexOf("ECB") == -1) {
			if (algorithm.indexOf("AES") != -1) {
				IvParameterSpec ivs16 = generateIvParameterSpec(key, 16);
				cipher.init(Cipher.DECRYPT_MODE, sKey, ivs16);
			} else {
				IvParameterSpec ivs8 = generateIvParameterSpec(key, 8);
				cipher.init(Cipher.DECRYPT_MODE, sKey, ivs8);
		} else {
			cipher.init(Cipher.DECRYPT_MODE, sKey);
		return cipher.doFinal(token);

	private static IvParameterSpec generateIvParameterSpec(byte key[], int size) {
		byte[] row = new byte[size];

		for (int i = 0; i < size; i++) {
			row[i] = key[i];

		return new IvParameterSpec(row);


The algorithm parameter is one of the following:

	private static final String AES_DECRIPTING_ALGORITHM = "AES/CBC/PKCS5Padding";
	private static final String DES_DECRIPTING_ALGORITHM = "DESede/ECB/PKCS5Padding";


Depending on the token version.


LTPA token versions

There are two LTPA tokens that are very similar but that differ in terms of the information they contain and the final encrypting of information:

  • LTPA:
    This is the format used in Websphere servers prior to 6.1.
  • Contents:
    • Token expiry.
    • User identity. Key-value pairs included with information on user.
    • Digital signature of user identify.
  • Encryption: 3DES.
  • LTPA2:
    This is the format used in IBM Websphere servers 6.1 and later.
  • Contents:
    • Token timeout.
    • User identity. Key-value pairs included with information on user.
    • (Optional) User authentication context.
    • Specific properties of the LTPA2 system.
  • Encryption: 3DES or AES

It is important to highlight that servers that support LTPA2 can validate tokens in both formats and in a transparent manner using the API provided by IBM in the server installation.


Conclusion and continuation

IBM provides for a SSO infrastructure in its WebSphere servers, allowing easy access to deployed apps. In the case of IBM WebSphere Portal apps user authentication and validation is carried out by the portal itself, but we can also implement authentication by LTPA token in applications deployed in WebSphere thanks to the API provided by IBM. In a forthcoming article we will look at how to use the API to generate and validate tokens.


Lightweight Third Party Authentication – (

Understanding LTPA – (

Configuring LTPA and working with keys – (

Alfresco LTPA authenticator – (