000021738 - AuthZ properties not exported to headers in RSA ClearTrust

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000021738
Applies ToRSA ClearTrust 5.5.3 Authorization Server (AServer)
RSA ClearTrust 5.5.3 Administrative API
IssueAuthZ properties not exported to headers in RSA ClearTrust
Failed to express updated user properties settings in the headers at authorization time after those user properties were updated through RSA ClearTrust Administrative API
CauseRSA ClearTrust AServer caches old information, and the old property value would be displayed
ResolutionTo correct this issue, ensure that the changed user object is flushed from the AServer cache subsequent to any changes to time critical values. To accomplish this, we recommend you leverage new functionality introduced in RSA ClearTrust hot fix 5.5.2.28. The hot fix includes a revised Javadoc that describes the new functionality and configuration file changes that can be implemented on the AServer.

1. The most important component of this fix is the new API calls. The new calls include a feature that allows for a particular user modification to cause that user object to be flushed from the AServer cache. Implementing these new calls is simply a matter of replacing the corresponding no cache flush call with the cache flush variant; this needs only to be done in instances where the property be modified must be updated immediately, and other calls can be left the same. Refer to the iCreatable link in the Javadocs for more information. For example, replace the "save()" to "save(int, cacheMode)".

This change to your code in itself should be sufficient to ensure that a modified user property is expressed correctly in the headers after an authentication event. This would allow you to return to using the AuthZ setting in your webagent.conf file.

2. In addition to the API changes, a new EServer configuration file parameter was introduced that allows the EServer to force the AServer caches to flush synchronously. This parameter affects all AdminAPI calls, so it should only be used if you continue to encounter problems. That being said, if all of your API calls are time sensitive but your volume is low, this may be the appropriate solution. With your EServer configured in this mode, your API calls will only return after a successful cache flush.

The following new parameter was introduced in this hot fix:

"cleartrust.eserver.runtime.synchronous_mode"
 
# Specifies whether cache flush events are sent to Authorization Servers
# synchronously as part of the Administrative API call. These events are
# normally processed asynchronously by a dedicated thread for performance
# reasons. However, in certain environments it is more important that running
# Authorization Servers be notified of the flush event before the API call
# returns, so that the client can next make a Runtime API request and be
# confident that it will not receive stale data.
#
# All cache flush events are affected by this setting, including both those
# created when the .granular_updates parameter is set, as well as those
# "forced" events generated even when granular updates are off (see your
# Administrative API documentation).
#
# WARNING:
#   Enabling synchronous mode will negatively affect performance; how much
#   degradation is seen depends on the environment. Particularly important are
#   the number of objects in the system and how frequently they are modified,
#   load on the Entitlements Server, the data store, and all Authorization
#   Servers, and network latency.
#
#   If your RSA ClearTrust Agents also need to reflect cache updates quickly,
#   remember to reduce the time to live in the appropriate Agent cache. Bear in
#   mind that this will likely reduce Agent performance, increasing load on
#   Authorization Servers and the data store.
#
# Allowed Values:
#   true or false
#
# Default Value:
#   false
#
#cleartrust.eserver.runtime.synchronous_mode=true
 
Legacy Article IDa24811

Attachments

    Outcomes