Description of problem: Customer is seeing performance issues with EAP 6 when attempting to use the management interface and authenticate against their ldap server. They have a flat but very large collection of groups. They would like to see performance similar to what they saw using parseRoleNameFromDN feature in EAP 5. Version-Release number of selected component (if applicable): EAP 6.4Beta How reproducible: Not very. Need access to customer's unique ldap provider and structure. Steps to Reproduce: 1. Configure <ldap> in management interface to use abovementioned provider 2. Attempt to access management interface Actual results: Authentication times out at 5s. (Increasing this value for customers production environment is not acceptable.) Expected results: Authentication does not timeout. Additional info: Severity set to Urgent at request of customer. There is a planned move to EAP 6 as part of a major upgrade to an ISV-provided application and this is a blocker for them.
Forgot to reference support case 00890012. Thank you.
Any news? Customer is pushing hard to get this into a CP for 6.4.
Created attachment 1086005 [details] config for testing change
Ondrej Lukas <olukas> updated the status of jira JBEAP-2320 to Reopened
Verification failed for IBM JDK 1.6. Remaining JDKs from platform certification work correctly. In case when group name from LDAP contains '/' characters then authentication failed. Exception in EAP server.log after failed authentication: TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 1) Failure supplementing Subject: java.lang.IllegalArgumentException: Cannot convert hex String to UTF8 at org.apache.harmony.jndi.internal.parser.LdapRdnParser.getUnEscapedValues(LdapRdnParser.java:173) [jndi.jar:] at org.apache.harmony.jndi.internal.parser.LdapRdnParser.unescapeValue(LdapRdnParser.java:131) [jndi.jar:] at javax.naming.ldap.Rdn.unescapeValue(Rdn.java:65) [jndi.jar:] at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.parseRole(LdapGroupSearcherFactory.java:345) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:277) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:215) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:223) [jboss-as-domain-management-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:115) [jboss-as-domain-http-interface-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:80) [jboss-as-domain-http-interface-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] 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.XFrameHeaderFilter.doFilter(XFrameHeaderFilter.java:45) [jboss-as-domain-http-interface-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81) at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:48) [jboss-as-domain-http-interface-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.5.6.Final-redhat-2.jar:7.5.6.Final-redhat-2] 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$Worker.runTask(ThreadPoolExecutor.java:908) [rt.jar:1.6.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:931) [rt.jar:1.6.0] at java.lang.Thread.run(Thread.java:738) [vm.jar:1.6.0] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
I think this is happening due to a bug in the Apache Harmony code that ships with the IBM 1.6 JDK: https://issues.apache.org/jira/browse/HARMONY-4229 As previously mentioned, this does not happen on IBM 1.7 JDK, Oracle 1.6 or 1.7. At this point, I think the best approach would be to modify the catch statement in the parseRole to be more broad in what it catches. That way it would be less likely that odd parsing issues would cause authentication issues.
Derek, thanks for the clarification.
Verified in EAP 6.4.6.CP.CR2.
Jiri Pallich <jpallich> updated the status of jira JBEAP-2320 to Closed
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.