Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-59148

LDAP Authorization cache refresh

    XMLWordPrintable

    Details

    • Type: Task
    • Status: In Progress
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Security 2021-08-23, Security 2021-09-06, Security 2021-09-20, Security 2021-10-04, Security 2021-11-01

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              varun.ravichandran Varun Ravichandran
              Reporter:
              mark.benvenuto Mark Benvenuto
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated: