IBM Support

Token timeout behavior when LTPA is used as the authentication mechanism for WebSphere Process Server (WPS) and IBM Business Process Manager (BPM) Advanced



A Lightweight Third Party Authentication (LTPA) token-expired exception occurs even before the value of the effective LTPA timeout is reached.


The problem occurs with Service Component Architecture (SCA) asynchronous messages that use LTPA token authentication. Asynchronous SCA messages are exchanged using queues on the SI Bus. As messages can be queued for any length of time, for example in high load situations or during planned system maintenance outages, LTPA tokens can expire before the messages are processed.


LTPA token expiration is governed by two configuration settings:

  • LTPA token timeout: (value is set in minutes)

  • This value dictates the initial setting for token timeout expiration. For example, if the value of this configuration setting is 2 hours (value of 120), the expiration time, during LTPA token creation, is set to the current time plus 2 hours. This value is not the "effective timeout" that is associated with a given request.

    Refer to Configuring the Lightweight Third Party Authentication mechanism for additional configuration information about WebSphere Application Server in IBM Business Process Manager and WebSphere Process Server.
  • cacheCushionMax: (Java™ Virtual Machine [JVM] system property
    This value helps define which entries in the cache are defunct and which are still valid.

    Complete the following steps to configure this property:
    1. Start WebSphere Process Server.

    2. Launch the administrative console.

    3. Set the property.
      1. Expand Application Servers.

      2. Click the server name.

      3. Click the Configuration Tab.

      4. Under Server Infrastructure, expand Java & Process Management.

      5. Click Process Definition.

      6. Click Java Virtual Machine.

      7. Click Custom Properties.

      8. Create a new property with the following values:
        key =
        value = <as desired> (e.g. in minutes )

    The cacheCushionMax value cannot be larger than 1/5 of the LTPA timeout value.

Effective timeout or LTPA token expiration:
The derived value is based on the previous configurations.

When you log in, WebSphere Application Server checks the authentication cache to see if you have logged in previously. If so, the Subject found in the cache is the Subject that is then associated with the work item being processed. Because the Subject contains the LTPA token, that LTPA token is essentially reused. Furthermore, if the Subject was originally cached 10 minutes ago, that LTPA token has an expiration of LTPA-token-timeout-configuration-value minus 10 minutes. As such, the effective timeout duration is not always the value that is defined by the LTPA token timeout configuration value. Depending on what the server finds or does not find in the authentication cache at the time of login, the timeout duration that is associated with the LTPA token for that work item varies.

Maximum effective expiration possible
The "LTPA token timeout configuration" value (newly created Subjects get the maximum setting).

Minimum effective expiration possible
  • This setting is defined by the cacheCushionMax value. If the work items were submitted at the client side with the LTPA time remaining less than cacheCushionMax value (described below), then a new Subject with a new LTPA timeout is configured. For example:

    LTPA timeout = 120 mins,
    cacheCushionMax = 3 mins (this is the default value)
    First Login occurs at = 10:00 AM. (LTPA timeout set to 12:00 PM)

  • Assuming that the login is reused from the cache, then work items submitted at 11:56 AM also have an expiration of 12:00 PM and might expire in a little under 4 minutes.
  • When a fresh login fetches a Subject entry in the cache, if the entry has an expiration of less than the cacheCushionMax value, the entry is thrown away and automatic entry refresh is performed; that is, auto-revalidation results in a new Subject with an LTPA token that is configured with an expiration of the current time plus the LTPA token timeout configuration value. For example:

    LTPA timeout = 120 mins,
    cacheCushionMax = 3 mins (this is the default value)
    First Login occurs at = 10:00 AM. (LTPA timeout set to 12:00 PM)

  • The work items that are submitted after 11:57 AM have an LTPA timeout left that is less than cacheCushionMax, and the LTPA timeout is refreshed.

Cache Timeout Configuration
(Click Security > Global Security > Configuration Tab > Cache Timeout)
This setting specifies the time out value in seconds for the security cache. The time out setting specifies how often to refresh the security-related caches. The default security cache time out value is 10 minutes.

Note: Do not set the LTPA Timeout value to less than the security Cache Timeout value.

Resolving The Problem

If you want a longer LTPA expiration, set a higher cacheCushionMax value to ensure that the tokens are refreshed when a submitted work item has an LTPA timeout of less than cacheCushionMax. For example:

Desired LTPA token expiration = x
Set the LTPA timeout = 5x
Set cacheCushionMax = x

[{"Product":{"code":"SSQH9M","label":"WebSphere Process Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.0;6.2;6.1.2;6.1","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}},{"Product":{"code":"SSFTN5","label":"IBM Business Process Manager Advanced"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"8.5;8.0.1;8.0;7.5.1;7.5","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Product Synonym


Document Information

Modified date:
15 June 2018