Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-14837

DOCS-14837: Investigate changes in SERVER-59148: LDAP Authorization cache refresh

      Downstream Change Summary

      This change introduces 3 new `setParameters` that should be documented.
      1. `ldapShouldRefreshUserCacheEntries`: A boolean. If set to true, the server will periodically refresh cached role/privilege information for users authorized via LDAP. Refreshes are performed by reacquiring authorization data from the LDAP server for each cached user and updating the cached entry if it differs from the freshly fetched data. If set to false, the server will periodically invalidate cached role/privilege information for users authorized via LDAP. Default is true.
      2. `ldapUserCacheRefreshInterval`: An int. Represents the time (in seconds) that the server will wait before contacting the LDAP server to refresh role information for all cached LDAP-authorized users. The maximum value is 86400 seconds (24 hours). The default value is 30 seconds.
      3. `ldapUserCacheStalenessInterval`: An int. Represents the maximum amount of time (in seconds) that the server will retain cached role information for LDAP users after the last successful refresh. If more than `ldapUserCacheStalenessInterval` seconds passes without a successful refresh, then the server will invalidate all cached LDAP user information and will become unavailable for LDAP users until it is able to contact the LDAP server again. The maximum value is 86400 seconds (24 hours). The default value is 90 seconds.

      `ldapUserCacheInvalidationInterval` remains as-is, but will only be used if `ldapShouldRefreshUserCacheEntries` is set to false. Otherwise, the new `ldapUserCacheRefreshInterval` setParameter is used to control how often the external user cache is refreshed.

      Description of Linked Ticket

      Change LDAP user cache management to no longer invalidate all LDAP entries on a periodic basis. Instead of a periodic interval controlled by the set parameter ldapUserCacheRefreshInterval, a new background runner named "LDAPCachePoller" will periodically refresh the role information for cached LDAP users in a single-threaded loop instead. This background runner will be active if isLDAPAuthzEnabled is true.

      For each entry, the server will first check whether the cached entry contains credentials if enableAuthenticationCaching is true. It will then search the LDAP server for role information. If the result from the LDAP server for the search operation does not match the role information in the cache, it will call insertOrAssign on the cache. Calling insertOrAssign only on changed entries will ensure that the refresh has minimal effect on the LRU tracking of the cache. If the user is missing from LDAP, invalidate() will be called to remove the entry from the cache. Finally, if any LDAP entries are changed, the authorization cache generation number will be bumped which will cause mongos to refresh its cache.

       

      While MongoDB could issue LDAP queries in parallel, a single-threaded approach will induce a lighter load on the LDAP server. The tradeoff is that it may take longer than ldapUserCacheRefreshInterval to refresh all the cache entries if the LDAP server is running slowly.

       

      If the LDAP server is unavailable (host down, connection refused, etc) or inadequately performing (queries timeout), the cache entries will not be touched. A global timer will be set on each successful refresh pass. For each refresh pass with errors, a check will be made to see when the last successful pass was made. If the last successful pass was made more than ldapUserCacheStalenessIntervalSeconds seconds, then the cache will be invalidated. This will cause MongoDB to become unavailable for LDAP users until the LDAP server returns.

       

      Since the underlying cache is a LRU with a max size of authorizationManagerCacheSize (default 100), this will not cause the cache to grow forever. Cache entries may remain longer in the cache than in the original design. Iterating the ReadThroughCache, InvalidatingLRU, and LRUCache are all passive operations that do not affect the lifetime of an entry. Only inserting, assigning or getting an entry affects the LRU.

       

      The older LDAPUserCacheInvalidator will be left in the code and be disabled by default. The reason for this is we are unsure if the most security conscious customers will prefer this behavior. If the user has a non-default value, we will log a warning to tell users that this behavior has changed and warn them it has been deprecated.

            Assignee:
            jason.price@mongodb.com Jason Price
            Reporter:
            backlog-server-pm Backlog - Core Eng Program Management Team
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:
              2 years, 20 weeks, 1 day ago