Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-11350

(7.0.z) Legacy ldap realm, entry for non existing user are cached

    XMLWordPrintable

Details

    • Hide
      • configure security realm to use cache with eviction by size strategy 
                    <security-realm name="authn-by-search-time-3-1">
                <authentication>
                    <ldap connection="ldap-connection" base-dn="ou=People,dc=jboss,dc=org" recursive="true">
                        <cache eviction-time="30" max-cache-size="1" cache-failures="false"/>
                        <username-filter attribute="uid"/>
                    </ldap>
                </authentication>
            </security-realm>
      • configure http interface to be secured by this realm 
                    <http-interface security-realm="authn-by-search-time-3-1">
                <http-upgrade enabled="true"/>
                <socket-binding http="management-http"/>
            </http-interface>
      • access http://localhost:9990/console with existing user e.g. "jduke"
      • access http://localhost:9990/console with non existing user e.g. "test"
      • In log there is message "Entry with key 'jduke' evicted from cache due to cache being above maximum size." When you access http://localhost:9990/console again with "jduke", then Wireshark shows that LDAP call occured.
      Show
      configure security realm to use cache with eviction by size strategy <security-realm name= "authn-by-search-time-3-1" > <authentication> <ldap connection= "ldap-connection" base-dn= "ou=People,dc=jboss,dc=org" recursive= " true " > <cache eviction-time= "30" max-cache-size= "1" cache-failures= " false " /> <username-filter attribute= "uid" /> </ldap> </authentication> </security-realm> configure http interface to be secured by this realm <http- interface security-realm= "authn-by-search-time-3-1" > <http-upgrade enabled= " true " /> <socket-binding http= "management-http" /> </http- interface > access http://localhost:9990/console with existing user e.g. "jduke" access http://localhost:9990/console with non existing user e.g. "test" In log there is message "Entry with key 'jduke' evicted from cache due to cache being above maximum size." When you access http://localhost:9990/console again with "jduke", then Wireshark shows that LDAP call occured.

    Description

      In case when cache is used for legacy LDAP security realm and any access to secured resource occures, then entry is added into cache even if user has not been authenticated correctly.

      Note, in reproducer there is cache-failures=false
      "cache-failures - This is a boolean that enables/disables the caching of failed searches. This has the potential for preventing an LDAP server from being repeatedly access by the same failed search, but it also has the potential to fill up the cache with searches for users that do not exist. This setting is particularly important for the authentication cache. " [1]

      And even with cache-failures = false , non existing user "takes slot" in cache, thus this

      • effectively could make cache smaller, because valid entries could be evicted due to max-cache-size.
      • reduce benefit of LDAP cache and impacts performance in unpredictable manner.

      Same behavior can be seen in 7.0.0.GA.

      Attachments

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-9391 Legacy ldap realm, entry for non existing user are cached

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified
          relates to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-12370 [7.1] Legacy ldap realm, caching by access time doesn't "clear" timeout for already cached entry

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Verified

          Activity

            People

              jondruse@redhat.com Jiri Ondrusek
              jondruse@redhat.com Jiri Ondrusek
              Martin Choma Martin Choma
              Martin Choma Martin Choma
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: