[JBoss JIRA] (ELY-940) key-store-ssl-certificate -> key-store-clear-password is wrapping parsing inside the Supplier
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-940?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-940:
---------------------------------
Priority: Critical (was: Major)
> key-store-ssl-certificate -> key-store-clear-password is wrapping parsing inside the Supplier
> ---------------------------------------------------------------------------------------------
>
> Key: ELY-940
> URL: https://issues.jboss.org/browse/ELY-940
> Project: WildFly Elytron
> Issue Type: Task
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta24
>
>
> This means we get errors like this where the parser is accessed after parsing should have finished: -
> {{[disconnected /] connect
> java.lang.IllegalStateException: Current event not START_ELEMENT
> at com.ctc.wstx.sr.BasicStreamReader.getAttributeCount(BasicStreamReader.java:584)
> at org.wildfly.client.config.BasicXMLStreamReader.getAttributeCount(BasicXMLStreamReader.java:191)
> at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getAttributeCount(AbstractDelegatingXMLStreamReader.java:148)
> at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getAttributeCount(AbstractDelegatingXMLStreamReader.java:148)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseClearPassword(ElytronXmlParser.java:1864)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$43(ElytronXmlParser.java:1270)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1286)
> at org.wildfly.security.auth.client.ElytronXmlParser$PrivateKeyKeyStoreEntryCredentialFactory.get(ElytronXmlParser.java:2232)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$5(ElytronXmlParser.java:434)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextRuleType$6(ElytronXmlParser.java:457)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:493)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:292)
> }}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8069) NPE in org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke
by Jim Ma (JIRA)
Jim Ma created WFLY-8069:
----------------------------
Summary: NPE in org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke
Key: WFLY-8069
URL: https://issues.jboss.org/browse/WFLY-8069
Project: WildFly
Issue Type: Bug
Components: Web Services
Reporter: Jim Ma
Assignee: Jim Ma
The NPE is regularly encountered in a build of the {{invocation_integration}} branch. Ask me for more details if this problem cannot be reproduced locally.
The log message in {{testsuite/integration/ws/target/jbossas/standalone/log/server.log}} is:
{noformat}
2017-01-30 17:23:57,588 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default-workqueue-1) Application {http://www.jboss.org/jbossws/ws-extensions/wsrm}ReliableService#{http://www.jboss.org/jbossws/ws-e
xtensions/wsrm}writeLogMessage has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault
at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162)
at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128)
at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232)
at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:145)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:278)
at org.apache.cxf.ws.addressing.impl.InternalContextUtils$1.run(InternalContextUtils.java:321)
at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:109)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
... 17 more
{noformat}
This error is preceded by the following stack trace which might or might not be related:
{noformat}
2017-01-30 17:23:57,460 SEVERE [org.apache.cxf.ws.rm.RMCaptureOutInterceptor] (default task-19) Error persisting message: javax.xml.stream.XMLStreamException: Trying to write END_DOCUMENT when document has no r
oot (ie. trying to output empty document).
at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1584)
at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1613)
at com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1439)
at com.ctc.wstx.sw.BaseStreamWriter.close(BaseStreamWriter.java:247)
at org.apache.cxf.staxutils.DelegatingXMLStreamWriter.close(DelegatingXMLStreamWriter.java:35)
at org.apache.cxf.ws.rm.CapturingXMLWriter.getOutputStream(CapturingXMLWriter.java:397)
at org.apache.cxf.ws.rm.RMCaptureOutInterceptor$CaptureEnd.handleMessage(RMCaptureOutInterceptor.java:271)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:83)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252)
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:109)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:210)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-937) SSLContext in authentication client has no trust configuration
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-937:
------------------------------------
Summary: SSLContext in authentication client has no trust configuration
Key: ELY-937
URL: https://issues.jboss.org/browse/ELY-937
Project: WildFly Elytron
Issue Type: Task
Components: Authentication Client
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Blocker
Fix For: 1.1.0.Beta24
Currently it requires on the system default so it is not possible to configure trusted certificate authorities.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by Douglas Gardim (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
Douglas Gardim edited comment on WFLY-3858 at 2/9/17 8:18 PM:
--------------------------------------------------------------
Using 8.2.0.Final and got a curious behavior. I created another cache configuration with the same name as the security-domain, so now I have 2 cache configurations in my "security" infinispan cache container: "auth-cache" and "[security domain name]". After many redeployments I noticed that most of the times it ends up using the "[security domain name]" configuration. Still not working 100% of the times though.
was (Author: dgardim):
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.
> 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)
9 years, 2 months
[JBoss JIRA] (WFLY-7965) Coverity static analysis: Dereference null return value in ServerAuthenticationContext (Elytron)
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7965?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7965:
-----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Coverity static analysis: Dereference null return value in ServerAuthenticationContext (Elytron)
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-7965
> URL: https://issues.jboss.org/browse/WFLY-7965
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> Coverity static-analysis scan found possible dereference null return value in following code
> {code:java|title=ServerAuthenticationContext.java}
> if (log.isTraceEnabled()) {
> log.tracef("Authorizing principal %s.", authenticationPrincipal.getName());
> log.tracef("Authorizing against the following attributes: %s => %s",
> authorizationIdentity.getAttributes().keySet(), authorizationIdentity.getAttributes().values());
> }
> {code}
> Coverity suppose null value could get here via {{AggregateSecurityRealm.Identity.getAuthorizationIdentity}} calling {{TokenSecurityRealm.TokenRealmIdentity.getAuthorizationIdentity}}
> {code:java|title=TokenRealmIdentity.java}
> @Override
> public AuthorizationIdentity getAuthorizationIdentity() throws RealmUnavailableException {
> if (exists()) {
> return new AuthorizationIdentity() {
> @Override
> public Attributes getAttributes() {
> return claims;
> }
> };
> }
> return null;
> }
> {code}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=85537...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by Douglas Gardim (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
Douglas Gardim edited comment on WFLY-3858 at 2/9/17 7:24 PM:
--------------------------------------------------------------
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.
was (Author: dgardim):
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)
9 years, 2 months