|Applies To||RSA ClearTrust 5.0.x|
RSA ClearTrust 5.5.x
RSA Access MAnager 6.0
|Issue||What causes "Token errors" in the Cleartrust/AXM aserver logs and how can they be reduced|
Error: "result_action=User Token Failed,result_reason=Token error" within Authorization Server log file.
Users are forced to re-authenticate in the middle of a session.
Users re-challeneged for authentication without reaching the idle timeout.
The "Token error" is caused when the ClearTrust tries to decrypt a users token from the CTSESSION cookie. However, the Authorization Server does not have the original session key which is what encrypts the user's token. These errors are primarily caused by these reasons:
1. The cleartrust.agent.idle_timeout parameter in the webagent.conf file was set to higher value than the cleartrust.keyserver.token_lifetime parameter within the keyserver.conf file. The ClearTrust KeyServer will discard the session_key after the token_lifetime value is reached yet the ClearTrust Agent will still believe this session is active and pass the token to the ClearTrust Authorization Server for decryption.
2. With cleartrust.agent.idle_timeout parameter correctly configured, User leaves browser idle for an extended period, overnight for example, the following morning the user refreshes the page or clicks a link for another protected page and is rechallenged for authentication. The user's token has since expired and the key to decrypt no longer exists would therefore result in a "Token error"
3. Distributed Keyservers are mis-configured.
4. Corrupted key server message results in ClearTrust cookie decryption errors. For Cleartrust 5.5.3 only, a hotfix is required
5. Restarted all keyservers in envirnoment while users were still active
|Resolution||The cleartrust.agent.idle_timeout parameter must be set to equal or less than the value of cleartrust.keyserver.token_lifetime. As stated above, token errors can still occur if both token and key expired. To reduce token errors further, make the token_lifetime much greater than the idle.timeout. When tuning this parameter, tweak in increments, as having too large a token_lifetime leads to possible security issues.|
Distributed Keyservers are mis-configured. The token_lifetime has to be double the session_key_ life. Keyserver.sec and Keyclient.sec files are created correctly.
Implement hotfix 18.104.22.168 and higher for Corrupted key server message error. This hotfix can be obtained by contacting RSA technical support.
In a situation where a user logs into CT the day before, but then leaves their browser open overnight. Upon attempting to refresh the page or clicking on a link for another protected page, the user will be rechallenged for authentication. Since the user's token has since expired, and the key to decrypt no longer exists, this will result in a "Token error" in the logs. This is well within the scope of normal behavior, and a certain percentage of token errors will appear in the logs as part of a user passing exipired tokens during normal usage.
|Notes||Note: when a users token has exceeded cleartrust.agent.idle_timeout parameter in the webagent.conf, but whose decryption key is still maintained in the authserver, they will NOT generate a token error, however the user will still be re-challeneged for authentication.|
|Legacy Article ID||a29184|