[JBoss JIRA] (WFLY-7538) WebSocketTestCase fails with security manager - Reenable the test
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFLY-7538?page=com.atlassian.jira.plugin.... ]
Jan Tymel reopened WFLY-7538:
-----------------------------
Assignee: Josef Cacek (was: Darran Lofthouse)
{{WebSocketTestCase}} is correctly enabled. However, {{testClientInDeployment}} fails with security manager. The output is following:
{code}
SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-1-thread-1) Failed: org.jboss.as.test.integration.web.websocket.WebSocketTestCase.testClientInDeployment: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost:0" "listen,resolve")" in code source "(vfs:/content/indeployment.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.indeployment.war" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.SecurityManager.checkListen(SecurityManager.java:1131)
at org.wildfly.security.manager.WildFlySecurityManager.checkListen(WildFlySecurityManager.java:392)
at sun.nio.ch.SocketChannelImpl.bind(SocketChannelImpl.java:582)
at sun.nio.ch.SocketAdaptor.bind(SocketAdaptor.java:135)
at org.xnio.nio.WorkerThread.openTcpStreamConnection(WorkerThread.java:263)
at org.xnio.XnioIoThread.openStreamConnection(XnioIoThread.java:237)
at org.xnio.XnioWorker.openStreamConnection(XnioWorker.java:344)
at org.xnio.http.HttpUpgrade$HttpUpgradeState.doUpgrade(HttpUpgrade.java:247)
at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$100(HttpUpgrade.java:165)
at org.xnio.http.HttpUpgrade.performUpgrade(HttpUpgrade.java:129)
at io.undertow.websockets.client.WebSocketClient$ConnectionBuilder.connectImpl(WebSocketClient.java:323)
at io.undertow.websockets.client.WebSocketClient$ConnectionBuilder.connect(WebSocketClient.java:211)
at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:463)
at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:457)
at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServer(ServerWebSocketContainer.java:211)
at org.jboss.as.test.integration.web.websocket.WebSocketTestCase.assertWebSocket(WebSocketTestCase.java:81)
at org.jboss.as.test.integration.web.websocket.WebSocketTestCase.testClientInDeployment(WebSocketTestCase.java:75)
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:498)
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.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
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:498)
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.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
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:498)
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.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:498)
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:498)
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:498)
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.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
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.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
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:498)
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.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:498)
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:498)
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:498)
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.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176)
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:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
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:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512)
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731)
at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258)
at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
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)
{code}
This happens only if {{-Dnode0}} parameter is used (e.g. in QE's CI). Here are steps to reproduce:
# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dtest=WebSocketTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
>From my observation it appears that {{localhost}} value in a SocketPermission as discussed in [this comment|https://issues.jboss.org/browse/WFLY-7538?focusedCommentId=133276...] must be hardcoded instead of using {{TestSuiteEnvironment.getServerAddress()}}. If {{-Dnode0}} parameter is omitted both tests pass.
See JBEAP-7011 for more details
> WebSocketTestCase fails with security manager - Reenable the test
> -----------------------------------------------------------------
>
> Key: WFLY-7538
> URL: https://issues.jboss.org/browse/WFLY-7538
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Kabir Khan
> Assignee: Josef Cacek
> Priority: Blocker
> Labels: downstream_dependency
> Fix For: 11.0.0.Alpha1
>
>
> Reenable WebSocketsTestCase. See WFLY-7539 for more details
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-905) Authentication based on certificates does not work in Elytron with Undertow
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-905?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-905:
--------------------------------
Honza Kalina: the UndertowDeploymentInfoService converts authentication method names from "format in web.xml" (CLIENT-CERT) to "format used by HttpServletRequest" (CLIENT_CERT) - which of them should be passed/accepted by Elytron? can I modify elytron to accept both of them?
Darran Lofthouse: As in servlet spec we are required to report the name in the format defined in HttpServletRequest then it probably makes sense for our mech and factory to use that format. I would suggest that means we convert from web.xml format to API format. Withing our mech factory report we support CLINET_CERT but maybe also be tollerant if we are called to create a mech with CLIENT-CERT
David M. Lloyd: I never like the "accept both" strategy - I'd rather see one be declared "correct"
Darran Lofthouse: I think the primary one needs to be *the one from HttpServletRequest* and convert from the one in web.xml - if we don't want to be tolerant stick with just that
> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
> Key: ELY-905
> URL: https://issues.jboss.org/browse/ELY-905
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.1.0.Beta21
> Reporter: Jan Tymel
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> ... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [1] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [2] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [3] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-904) Logout support for HTTP-based authentication mechanisms
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor commented on ELY-904:
--------------------------------
Maybe we may consider an interface {{StatefulHttpServerAuthenticationMechanism}} which provides the ability to implement mechanisms that track user authentication session and support logout.
> Logout support for HTTP-based authentication mechanisms
> -------------------------------------------------------
>
> Key: ELY-904
> URL: https://issues.jboss.org/browse/ELY-904
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.1.0.Beta21
> Reporter: Pedro Igor
> Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-905) Authentication based on certificates does not work in Elytron with Undertow
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-905?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7687 to ELY-905:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-905 (was: WFLY-7687)
Component/s: HTTP
(was: Security)
Fix Version/s: (was: 11.0.0.Alpha1)
> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
> Key: ELY-905
> URL: https://issues.jboss.org/browse/ELY-905
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.1.0.Beta21
> Reporter: Jan Tymel
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> ... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [1] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [2] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [3] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-905) Authentication based on certificates does not work in Elytron with Undertow
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-905?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-905:
---------------------------
Affects Version/s: 1.1.0.Beta21
> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
> Key: ELY-905
> URL: https://issues.jboss.org/browse/ELY-905
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.1.0.Beta21
> Reporter: Jan Tymel
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> ... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [1] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [2] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [3] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-904) Logout support for HTTP-based authentication mechanisms
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor updated ELY-904:
---------------------------
Description:
I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.
was:
I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Logout support for HTTP-based authentication mechanisms
> -------------------------------------------------------
>
> Key: ELY-904
> URL: https://issues.jboss.org/browse/ELY-904
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.1.0.Beta21
> Reporter: Pedro Igor
> Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months