000015117 - AxM - Auth servers Protected cache out of date - Cache reload

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 Number000015117
Applies ToClearTrust Authorization server 5.5.3
Access Manager Authorization server 6.x
IssueAxM Allow SAFE cache flushing of the protected URL cache
The protected URL cache entries in Authorization servers are not up to date when the Authorization servers go out of reach of the Entitlements Server or from the Dispatcher Server.  Eserver not being able to reach all aservers for cache updates. Also, if the eserver does not get a complete list from the dispatcher it will not update all the aservers caches.
Resolution

This Hotfix is to change the protected URL caching such that the protected URL cache can be flushed or reloaded manually or periodically to keep it updated. This is achieved by spawning a separate scheduler thread in the Authorization  server. A new parameter has been introduced in the Authorization server configuration file, aserver.conf, to control the behavior of the scheduler thread.

# This parameter instructs the Authorization server when to reload the
  # protected URL cache entries or how frequently the protected URL cache
  # entries must be reloaded. This parameter serves a different purpose than
  # that of the cleartrust.aserver.cache.time_to_live.
  # When cleartrust.aserver.cache.time_to_live is set, only the stale/expired
  # protected URL cache entries are reloaded when the URL is requested. When
  # this parameter is set, apart from reloading the stale/expired entries, the
  # Authorization server will also load newly protected URL entries from the
  # data store.
  #
  # This parameter can use two different formats as values for scheduling the
  # thread:
  # 1.Protected URL cache reload interval duration:
  #    With this option, cache will be reloaded on an interval basis. If the
  #    parameter value is '2 hours', then the cache will be reloaded for every
  #    two hours calculated from the last time the cache was automatically
  #    reloaded.
  # 2.Protected URL cache reload time:
  #    Protected URL cache reload starts at a previously  specified time. The
  #    time must be specified in 24 hour format.
  #  
  # If the parameter is commented out or if the parameter value is 0(zero),
  # the scheduler thread will not get triggered to reload the cache.
  #
  # Allowed Values:
  #   Any positive integer followed by a space and one of the following time
  #   specifiers: Hour(s) | Min(s)
  #   hh:mm          ( Cache reload time. Must be specified in 24 hour format.)
  #   0              ( The scheduler thread will not get triggered to reload
  #                    the cache )
  #
  # Default Value:
  #   0
  #
  # Recommended Value:
  #   02:00
  #
  # Note:
  # It is highly recommended that the value of this parameter be set to a
  # suitable value so that the cache reload thread runs at an off-peak time,
  # because the CPU utilization will peak at the time of cache loading.
  #
  # Example:
  #   1.Protected URL cache reload interval duration:
  #       cleartrust.aserver.cache.webserver.thread_time= 5 Hours
  #       cleartrust.aserver.cache.webserver.thread_time= 35 Mins
  #   2.Protected URL cache reload time:
  #       cleartrust.aserver.cache.webserver.thread_time= 01:45
  #       cleartrust.aserver.cache.webserver.thread_time= 23:25
  #   3. Disable protected URL cache reload:
  #       cleartrust.aserver.cache.webserver.thread_time= 0
  #
  # cleartrust.aserver.cache.webserver.thread_time=


This problem has been resolved in hotfix 5.5.3.128  for RSA ClearTrust 5.5.3.  Please contact RSA Customer Support and request this hotfix or later as these hotfixes are cumulative.
Legacy Article IDa48984

Attachments

    Outcomes