[jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain

[Douglas Gardim (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361404#comment-13361404 ] 

Douglas Gardim commented on WFLY-3858:
--------------------------------------

Using 8.2.0.Final here. 
Actually I found another workaround: inside the "security" cache container, create another cache configuration (local-cache in my case) with the same name as the security-domain. So I have 2 cache configurations in my "security" infinispan cache container: "auth-cache" and "[security domain name]". After observing many redeployments I noticed that, when it fails to get the configuration from the "auth-cache", it gets it from the "[security domain name]" configuration instead.

I don't know exactly how to explain this, but I noticed that the security domain actually uses a cache that is named after the security domain's own name. Maybe because it uses exactly the configuration that is defined in the infinispan subsystem it somehow gets updated when it is finally loaded.



> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3858
>                 URL: https://issues.jboss.org/browse/WFLY-3858
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.1.0.Final
>            Reporter: Robert Tuck
>            Assignee: Darran Lofthouse
>         Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
>         <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
>             <cache-container name="security" default-cache="auth-cache" start="EAGER">
>                 <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
>                 <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration lifespan="60000"/>
>                 </replicated-cache>
>             </cache-container>
> </subsystem>
> ...
>         <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
>                 <security-domain name="OAuth-Consumer" cache-type="infinispan">
>                     <authentication>
>                         <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
>                                       module="deployment.ewb-server-ear.ear">
>                             <module-option name="allowedConsumerAuthFailures" value="-1"/>
>                             <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
>                         </login-module>
>                     </authentication>
>                 </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
>    public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
>         log.debugf("Creating SDC for domain=" + securityDomain);
>         AuthenticationManager am = createAuthenticationManager(securityDomain);
>         // create authentication cache
>         if (cacheFactory instanceof EmbeddedCacheManager) {
>             EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
>             @SuppressWarnings("rawtypes")
>             Cache cache = null;
>             if (cacheManager != null) {
>                 // TODO override global settings with security domain specific
>                 ConfigurationBuilder builder = new ConfigurationBuilder();
>                 Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null.
>                 if (baseCfg != null) {
>                     builder.read(baseCfg);
>                 }
>                 cacheManager.defineConfiguration(securityDomain, builder.build());
>                 cache = cacheManager.getCache(securityDomain);
>             }
>             if (cache != null && am instanceof CacheableManager) {
>                 @SuppressWarnings({ "unchecked", "rawtypes" })
>                 CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
>                 cm.setCache(cache);
>             }
>         } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <…>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
>    @Override
>    public Configuration getCacheConfiguration(String name) {
>       Configuration configuration = configurationOverrides.get(name);
>      if (configuration == null && cacheExists(name)) {
>          return defaultConfiguration;
>       }
>       return configuration;
>    }
> Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>  



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