Bug 1150608

Summary: cache-failures flag doesn't work for LDAP cache in security realms
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Josef Cacek <jcacek>
Component: SecurityAssignee: Darran Lofthouse <darran.lofthouse>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Slavicek <pslavice>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.4.0CC: anmiller, bdawidow, kkhan
Target Milestone: DR6   
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-19 12:43:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Josef Cacek 2014-10-08 14:03:33 UTC
Caching non-IO failures using the "cache-failures" flag doesn't work. Possible root of the issue is catch block in org.jboss.as.domain.management.security.LdapCacheService.BaseSearchCache.CacheEntry.getSearchResult(LdapConnectionHandler, K):

} catch (NamingException e) {
  if (cacheFailures) {
    failure = e;
  }
  throw e;
}

The problem is the IOException is thrown instead of NamingException in org.jboss.as.domain.management.security.LdapUserSearcherFactory.LdapUserSearcherImpl.search(LdapConnectionHandler, String):
throw MESSAGES.userNotFoundInDirectory(suppliedName);

and the message defined in org.jboss.as.domain.management.DomainManagementMessages:
@Message(id = 15231, value = "User '%s' not found in directory.")
IOException userNotFoundInDirectory(String username);

The stack trace looks like:

java.io.IOException: JBAS015231: User 'test' not found in directory.
	at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:123)
	at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:67)
	at org.jboss.as.domain.management.security.LdapCacheService.internalSearch(LdapCacheService.java:199)
	at org.jboss.as.domain.management.security.LdapCacheService.access$800(LdapCacheService.java:54)
	at org.jboss.as.domain.management.security.LdapCacheService$BaseSearchCache$CacheEntry.getSearchResult(LdapCacheService.java:375)
	at org.jboss.as.domain.management.security.LdapCacheService$ByAccessCache.search(LdapCacheService.java:526)
	at org.jboss.as.domain.management.security.UserLdapCallbackHandler$LdapCallbackHandler.handle(UserLdapCallbackHandler.java:201)
	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:173)
	at org.jboss.as.domain.http.server.security.BasicAuthenticator.checkCredentials(BasicAuthenticator.java:144)
	at org.jboss.com.sun.net.httpserver.BasicAuthenticator.authenticate(BasicAuthenticator.java:77)
	at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:103)
	at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:80)
	at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:64)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
	at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47)
	at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
	at org.jboss.threads.JBossThread.run(JBossThread.java:122)

Comment 1 Darran Lofthouse 2014-10-08 14:12:09 UTC
Does look like the wrong exception type is in use - we don't want to be caching IOExceptions as these would cover a server being temporarily unavailable so we should avoid using IOException where we are talking about an invalid user ID.

Comment 2 JBoss JIRA Server 2014-10-13 17:12:16 UTC
Darran Lofthouse <darran.lofthouse> updated the status of jira WFCORE-166 to Resolved

Comment 3 Darran Lofthouse 2014-10-13 17:12:56 UTC
On checking upstream this is a minor change that was already made upstream and not backported along with the rest of the cache backport.

Comment 4 Darran Lofthouse 2014-10-13 17:20:00 UTC
Nacking requires_doc_text as this was an omission during the backport for LDAP caching which is not included in any existing releases.

Comment 7 JBoss JIRA Server 2015-04-28 15:05:20 UTC
John Doyle <jdoyle> updated the status of jira EAP6-191 to Closed