[JBoss JIRA] (WFCORE-3168) Add warning when setting new secret value for alias or remove alias
by Hynek Švábek (JIRA)
Hynek Švábek created WFCORE-3168:
------------------------------------
Summary: Add warning when setting new secret value for alias or remove alias
Key: WFCORE-3168
URL: https://issues.jboss.org/browse/WFCORE-3168
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Critical
Add warning when setting new secret value for alias or remove alias.
There would be nice to have warning message for update secret value for alias or remove alias. Because some dependant services might have cached the secret value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-1324) Authentication is not cached properly if the callback handler does not implement equals()/hashCode()
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/ELY-1324?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas moved JBREM-1338 to ELY-1324:
--------------------------------------------
Project: WildFly Elytron (was: JBoss Remoting)
Key: ELY-1324 (was: JBREM-1338)
Workflow: GIT Pull Request workflow (was: classic default workflow)
> Authentication is not cached properly if the callback handler does not implement equals()/hashCode()
> ----------------------------------------------------------------------------------------------------
>
> Key: ELY-1324
> URL: https://issues.jboss.org/browse/ELY-1324
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Stuart Douglas
>
> If the callback handler does not implement equals()/hashCode() then AuthenticationConfiguration objects will not be considered equal (in the case where a new one is being created each time), which will result in a memory leak in org.jboss.remoting3.ConnectionPeerIdentityContext#futureAuths, as well as authentication being attempted for every request. This can be observed by adding a loop to org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase#testRemoteLookup
> I think this is a fairly serious issue, as I think there will be a lot of handler out there that do not meet this requirement, and it causes both a serious performance regression due to repeated auth, as well as a memory leak that can crash the JVM.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9186) Some tests fail with SocketPermission with security manager enabled
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-9186?page=com.atlassian.jira.plugin.... ]
Ingo Weiss reassigned WFLY-9186:
--------------------------------
Assignee: Ingo Weiss
> Some tests fail with SocketPermission with security manager enabled
> -------------------------------------------------------------------
>
> Key: WFLY-9186
> URL: https://issues.jboss.org/browse/WFLY-9186
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ingo Weiss
>
> Some tests fail with SocketPermission with security manager enabled
> * AtomicTransactionSuspendTestCase
> * BusinessActivitySuspendTestCase
> {code:collapse=true}
> testCommitAfterSuspend(org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase) Time elapsed: 0.111 sec <<< ERROR!
> javax.xml.ws.soap.SOAPFaultException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "10.40.4.255:8180" "connect,resolve")" in code source "(vfs:/content/executorService.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.executorService.war" from Service Module Loader")
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:161)
> at com.sun.proxy.$Proxy48.init(Unknown Source)
> at org.jboss.as.test.xts.suspend.AbstractTestCase.before(AbstractTestCase.java:103)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:463)
> 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:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:108)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:241)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319)
> 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:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: org.apache.cxf.binding.soap.SoapFault: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "10.40.4.255:8180" "connect,resolve")" in code source "(vfs:/content/executorService.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.executorService.war" from Service Module Loader")
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:86)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:52)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:41)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:805)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1684)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1560)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1361)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:658)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:518)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:427)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:328)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:281)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
> ... 130 more
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JBREM-1338) Authentication is not cached properly if the callback handler does not implement equals()/hashCode()
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/JBREM-1338?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on JBREM-1338:
-----------------------------------------
[~swd847] this is the old Remoting 2 project not Remoting 3 - but as AuthenticationConfiguration is providing the overall equality check maybe this will be better over in the Elytron project.
> Authentication is not cached properly if the callback handler does not implement equals()/hashCode()
> ----------------------------------------------------------------------------------------------------
>
> Key: JBREM-1338
> URL: https://issues.jboss.org/browse/JBREM-1338
> Project: JBoss Remoting
> Issue Type: Bug
> Reporter: Stuart Douglas
>
> If the callback handler does not implement equals()/hashCode() then AuthenticationConfiguration objects will not be considered equal (in the case where a new one is being created each time), which will result in a memory leak in org.jboss.remoting3.ConnectionPeerIdentityContext#futureAuths, as well as authentication being attempted for every request. This can be observed by adding a loop to org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase#testRemoteLookup
> I think this is a fairly serious issue, as I think there will be a lot of handler out there that do not meet this requirement, and it causes both a serious performance regression due to repeated auth, as well as a memory leak that can crash the JVM.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2207) Use of AUTH does not result in a SecurityException if another client does not use AUTH
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2207?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2207.
----------------------------
Resolution: Done
> Use of AUTH does not result in a SecurityException if another client does not use AUTH
> --------------------------------------------------------------------------------------
>
> Key: JGRP-2207
> URL: https://issues.jboss.org/browse/JGRP-2207
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.4
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: JGroupsAuthExample.java, JGroupsAuthExample.java
>
>
> If there are two members in a cluster, one with AUTH configured and started first, so it can become the coordinator and a second without AUTH, the documentation implies that the second should receive a SecurityException. Instead, it creates it's own cluster. This works as expected if the second member uses AUTH, but has a different SecurityToken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2207) Use of AUTH does not result in a SecurityException if another client does not use AUTH
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2207?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2207:
--------------------------------
OK, check out master, the code should now do what you want it to do: throw an exception in JChannel.connect() on the second node.
> Use of AUTH does not result in a SecurityException if another client does not use AUTH
> --------------------------------------------------------------------------------------
>
> Key: JGRP-2207
> URL: https://issues.jboss.org/browse/JGRP-2207
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.4
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: JGroupsAuthExample.java, JGroupsAuthExample.java
>
>
> If there are two members in a cluster, one with AUTH configured and started first, so it can become the coordinator and a second without AUTH, the documentation implies that the second should receive a SecurityException. Instead, it creates it's own cluster. This works as expected if the second member uses AUTH, but has a different SecurityToken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months