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

[István Tóth (JIRA)]

István Tóth created WFLY-8431:
---------------------------------

             Summary: 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


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.





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)