Details
-
Bug
-
Resolution: Won't Do
-
Major
-
None
-
10.1.0.Final
-
None
Description
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.
Attachments
Issue Links
- causes
-
SECURITY-991 NPE When registering null AuthConfigProvider on JBossAuthConfigFactory
- Closed
- is blocked by
-
SECURITY-911 Remove obsolete EULA
- Open
- is duplicated by
-
WFLY-10417 Security API - Soteria - Jaspic - Error getting ServerAuthContext
- Closed
- is incorporated by
-
WFCORE-3898 Upgrade PicketBox to 5.1.0.Final
- Resolved