[jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code

Race conditions in JASPIC registration code ------------------------------------------- Key: WFLY-8431 URL: https://issues.jboss.org/browse/WFLY-8431 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 10.1.0.Final Environment: Centos 7 x86_64, with the included Java 8 environment Reporter: István Tóth Assignee: Darran Lofthouse Priority: Major Attachments: GetFactoryTestCase.java javax.security.auth.message.config.AuthConfigFactory and org.jboss.security.auth.message.config.JBossAuthConfigFactory have race conditions. 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. Nearly all methods of this class manipulate these, without any synchronization. In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. The methods that modify the maps should also be made synchronized, or rewritten to use the atomic ConcurrentHashMaps operations. A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way.