Bug 1150608 - cache-failures flag doesn't work for LDAP cache in security realms
Summary: cache-failures flag doesn't work for LDAP cache in security realms
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Security
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: DR6
: EAP 6.4.0
Assignee: Darran Lofthouse
QA Contact: Pavel Slavicek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-08 14:03 UTC by Josef Cacek
Modified: 2019-08-19 12:43 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-08-19 12:43:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker EAP6-191 0 Major Closed Management security realms should cache LDAP data 2015-04-28 15:04:38 UTC
Red Hat Issue Tracker WFCORE-166 0 Major Resolved LDAP caching for security realm not caching where a user does not exist on the server. 2015-04-14 10:00:08 UTC

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


Note You need to log in before you can comment on or make changes to this bug.