[JBoss JIRA] (ISPN-4285) HotRod digest-md5 auth fails with NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4285?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4285:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1097316|https://bugzilla.redhat.com/show_bug.cgi?id=1097316] from ON_QA to VERIFIED
> HotRod digest-md5 auth fails with NPE
> -------------------------------------
>
> Key: ISPN-4285
> URL: https://issues.jboss.org/browse/ISPN-4285
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Beta1
>
>
> HotRod DIGEST-MD5 auth fails with NPE when password on the server is stored as a plain text. Example realm configuration snip:
> {noformat}
> <authentication>
> <local default-user="$local" allowed-users="*"/>
> <properties path="application-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
> </authentication>
> {noformat}
> Full stack trace:
> {noformat}
> org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:310)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:185)
> at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:27)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:535)
> at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:633)
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:614)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:525)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:521)
> at org.infinispan.server.test.client.hotrod.security.HotRodSaslAuthTestBase.initialize(HotRodSaslAuthTestBase.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:95)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:222)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:62)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:139)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.NullPointerException
> at org.infinispan.client.hotrod.impl.transport.AbstractTransport.writeArray(AbstractTransport.java:97)
> at org.infinispan.client.hotrod.impl.operations.AuthOperation.execute(AuthOperation.java:35)
> at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.auth(SaslTransportObjectFactory.java:99)
> at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.makeObject(SaslTransportObjectFactory.java:72)
> at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.makeObject(SaslTransportObjectFactory.java:25)
> at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:306)
> ... 98 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 4 months
[JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3838:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1043434|https://bugzilla.redhat.com/show_bug.cgi?id=1043434] from ON_QA to VERIFIED
> L1 entry added by ST when already invalidated
> ---------------------------------------------
>
> Key: ISPN-3838
> URL: https://issues.jboss.org/browse/ISPN-3838
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> Non-transactional cache with L1 enabled. Node A is losing ownership of an entry, the entry is not removed during ST but is going to L1.
> 1. ST builds the invalidation command, EntryWrapping interceptor starts committing all the entries
> 2. Write on primary owner (B) occurs
> 3. A gets the InvalidateL1Command, removes the ImmortalCacheEntry from data container (as it does not own the entry anymore)
> 4. The ST invalidation command commits the MortalCacheEntry with old value, storing it into the data container.
> Result: Outdated value is in L1 cache.
> As the entry is not locked during the ST, it can be committed as MortalCacheEntry only if it was not changed (removed and possibly then cached again with different value).
> (I understand that this wouldn't be easy to implement as the check is not to be executed in perform, but during the actual commit - and atomically in the container.)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 4 months
[JBoss JIRA] (ISPN-4316) The client is tried for "SSL Peer Authentication" even though encryption's require-ssl-client-auth is set to false
by Vijay Bhaskar Chintalapati (JIRA)
Vijay Bhaskar Chintalapati created ISPN-4316:
------------------------------------------------
Summary: The client is tried for "SSL Peer Authentication" even though encryption's require-ssl-client-auth is set to false
Key: ISPN-4316
URL: https://issues.jboss.org/browse/ISPN-4316
Project: Infinispan
Issue Type: Bug
Components: Security, Server
Affects Versions: 7.0.0.Alpha4
Reporter: Vijay Bhaskar Chintalapati
Assignee: Tristan Tarrant
Consider the scenario:
- The client enables the authentication thru ConfigurationBuilder (i.e cb.security().authentication())
- The Server's SSL configuration doesn't require client authentication (i.e require-ssl-client-auth="false") and in addition the security-realm's <authentication .../> doesn't include a <truststore .../>
In such a scenario the client is unable to authenticate as the following exception is thrown in the server side logs:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
One sided communication encryption (with client storing server's certificate in its trust store) should be supported particularly when the client wants to authenticate via credentials
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 4 months
[JBoss JIRA] (ISPN-4313) If Hotrod Server encryption's require-ssl-client-auth is set to true, <truststore .. /> existence must be checked
by Vijay Bhaskar Chintalapati (JIRA)
[ https://issues.jboss.org/browse/ISPN-4313?page=com.atlassian.jira.plugin.... ]
Vijay Bhaskar Chintalapati updated ISPN-4313:
---------------------------------------------
Component/s: Server
> If Hotrod Server encryption's require-ssl-client-auth is set to true, <truststore .. /> existence must be checked
> -----------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4313
> URL: https://issues.jboss.org/browse/ISPN-4313
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Security, Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: Vijay Bhaskar Chintalapati
> Assignee: Dan Berindei
> Priority: Critical
>
> Currently the Infinispan Server can be configured with SSL encryption such that it requires the client to authenticate itself to the server for the purposes of encryption. This can be done by setting the attribute require-ssl-client-auth="true" as shown below.
> <hotrod-connector socket-binding="hotrod" cache-container="security">
> ....
> <encryption security-realm="ApplicationRealm" require-ssl-client-auth="true"/>
> ....
> </hotrod>
> But when that attribute is set to "true" a check should be enforced to check the existence of the the <truststore .. /> element exists in secruity-realm's <authentication>.
> If the check on the configuration fails, the server should throw and error on bootup rather than fail when client connections start to come in.
> Currently when the require-ssl-client-auth="true" and there is no <truststore../> configured, client connections fail and the exception below is thrown in the server's logs:
> javax.net.ssl.SSLHandshakeException: null cert chain
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 4 months
[JBoss JIRA] (ISPN-4314) Authentication is not enforced at Server when a Hotrod client doesn't enable authentication AND when the cache/cache manager doesn't enforce authorization
by Vijay Bhaskar Chintalapati (JIRA)
Vijay Bhaskar Chintalapati created ISPN-4314:
------------------------------------------------
Summary: Authentication is not enforced at Server when a Hotrod client doesn't enable authentication AND when the cache/cache manager doesn't enforce authorization
Key: ISPN-4314
URL: https://issues.jboss.org/browse/ISPN-4314
Project: Infinispan
Issue Type: Bug
Components: Security, Server
Affects Versions: 7.0.0.Alpha4
Reporter: Vijay Bhaskar Chintalapati
Assignee: Tristan Tarrant
Consider a situation where :
- Hotrod server enforces authentication via security-realms by defining a <authentication .../> element in <hotrod-connector .. /> element
- "security-cm" (for example) cache container, tied to the hotrod-connector above, doesn't define authorization in the configuration file
- "security" (for example) cache of security-cm also doesn't (mainly because if cannot) enforce authorization
- a Hotrod client uses a regular ConfigurationBuilder without enabling security
In the above scenario any cache operations are permitted without any restrictions. This authentication should be enforced at all times as defined at the <hotrod-connector .../> and shouldn't be based on authorization at cache-containers
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 4 months
[JBoss JIRA] (ISPN-4313) If Hotrod Server encryption's require-ssl-client-auth is set to true, <truststore .. /> existence must be checked
by Vijay Bhaskar Chintalapati (JIRA)
[ https://issues.jboss.org/browse/ISPN-4313?page=com.atlassian.jira.plugin.... ]
Vijay Bhaskar Chintalapati updated ISPN-4313:
---------------------------------------------
Description:
Currently the Infinispan Server can be configured with SSL encryption such that it requires the client to authenticate itself to the server for the purposes of encryption. This can be done by setting the attribute require-ssl-client-auth="true" as shown below.
<hotrod-connector socket-binding="hotrod" cache-container="security">
....
<encryption security-realm="ApplicationRealm" require-ssl-client-auth="true"/>
....
</hotrod>
But when that attribute is set to "true" a check should be enforced to check the existence of the the <truststore .. /> element exists in secruity-realm's <authentication>.
If the check on the configuration fails, the server should throw and error on bootup rather than fail when client connections start to come in.
Currently when the require-ssl-client-auth="true" and there is no <truststore../> configured, client connections fail and the exception below is thrown in the server's logs:
javax.net.ssl.SSLHandshakeException: null cert chain
was:
Currently the Infinispan Server can be configured with SSL encryption such that it requires the client to authenticate itself to the server for the purposes of encryption. This can be done by setting the attribute require-ssl-client-auth="true" as shown below.
<hotrod-connector socket-binding="hotrod" cache-container="security">
....
<encryption security-realm="ApplicationRealm" require-ssl-client-auth="true"/>
....
</hotrod>
But when that attribute is set to "true" a check should be enforced to check the existence of the the <truststore .. /> element exists in secruity-realm's <authentication>.
If the check on the configuration fails, the server should throw and error on bootup rather than fail when client connections start to come in.
Currently when the require-ssl-client-auth="true" and there is no <truststore../> configured, client connections fail and the exception below is thrown at the server:
javax.net.ssl.SSLHandshakeException: null cert chain
> If Hotrod Server encryption's require-ssl-client-auth is set to true, <truststore .. /> existence must be checked
> -----------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4313
> URL: https://issues.jboss.org/browse/ISPN-4313
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Security
> Affects Versions: 7.0.0.Alpha4
> Reporter: Vijay Bhaskar Chintalapati
> Assignee: Dan Berindei
> Priority: Critical
>
> Currently the Infinispan Server can be configured with SSL encryption such that it requires the client to authenticate itself to the server for the purposes of encryption. This can be done by setting the attribute require-ssl-client-auth="true" as shown below.
> <hotrod-connector socket-binding="hotrod" cache-container="security">
> ....
> <encryption security-realm="ApplicationRealm" require-ssl-client-auth="true"/>
> ....
> </hotrod>
> But when that attribute is set to "true" a check should be enforced to check the existence of the the <truststore .. /> element exists in secruity-realm's <authentication>.
> If the check on the configuration fails, the server should throw and error on bootup rather than fail when client connections start to come in.
> Currently when the require-ssl-client-auth="true" and there is no <truststore../> configured, client connections fail and the exception below is thrown in the server's logs:
> javax.net.ssl.SSLHandshakeException: null cert chain
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 4 months