May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10417) Security API - Soteria - Jaspic - Error getting ServerAuthContext

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-10417?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-10417: --------------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Security API - Soteria - Jaspic - Error getting ServerAuthContext > ----------------------------------------------------------------- > > Key: WFLY-10417 > URL: https://issues.jboss.org/browse/WFLY-10417 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 13.0.0.Beta1 > Environment: Wildfly 13.0.0.Beta1 and an EAR Application using JavaEE 8 Security API > Reporter: Alessandro Moscatelli > Assignee: Ilia Vassilev > Priority: Critical > Fix For: 13.0.0.CR1 > > Attachments: image-2018-05-24-13-41-05-322.png, soteria.zip > > > I am testing the new Wildfly release and the new Java EE8 Security API. > I noticed this serious (I truly believe) bug, and it also accours almost randomly. > > The deployed application is an EAR. > > If I deploy the EAR with a started Wildfly 13.0.0.Beta1 everything is fine. > Then if I stop and start / restart the application server, I can see the startup and the EAR is redeployed but sometimes (like 50% of time) the bug/error accours. > Usually after a couple of times (stop/start/restart) I can reproduce the issue. > Before the bug accours every call to pages and APIs works correctly. After the bug accours every call triggers the AuthException. > After the bug accours, if I redeploy the SAME EAR everything is fine again 100% of times. > This seems like Wildfly does something different when redeploying an application on startup and when being already startup up and then processing an application deploy. > > I can provide my EAR if you want, but I would prefer not to if this is not necessary. > The security domain as defined as suggested : > > <security-domain name="auth" cache-type="default"> > <authentication-jaspi> > <login-module-stack name="dummy"> > <login-module code="Dummy" flag="optional"/> > </login-module-stack> > <auth-module code="Dummy"/> > </authentication-jaspi> > </security-domain> > > META-INF/jboss-app.xml inside the EAR : > > <?xml version="1.0" encoding="UTF-8"?> > <jboss-app> > <security-domain>auth</security-domain> > </jboss-app> > > META-INF/jboss-web.xml inside the WAR inside the EAR : > > <?xml version="1.0" encoding="UTF-8"?> > <jboss-web> > <security-domain>auth</security-domain> > </jboss-web> > > Log : > > 17:04:18,556 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /optoplus-services-web and security domain auth: javax.security.auth.message.AuthException > at org.jboss.security.auth.message.config.JBossServerAuthConfig.getAuthContext(JBossServerAuthConfig.java:187) > at org.jboss.security.plugins.auth.JASPIServerAuthenticationManager.isValid(JASPIServerAuthenticationManager.java:99) > at org.wildfly.extension.undertow.security.jaspi.JASPICAuthenticationMechanism.authenticate(JASPICAuthenticationMechanism.java:123) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231) > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125) > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99) > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > 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.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:48) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > 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:1514) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514) > 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:360) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > UPDATE !! > Now I finally got WHY it was random !! > The problem is related to EAR containing multiple WAR registering different contexts : > 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 80) Initializing Soteria 1.0 for context '/soteria-web2' > 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 76) Initializing Soteria 1.0 for context '/soteria-web' > 13:29:37,738 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 80) WFLYUT0021: Registered web context: '/soteria-web2' for server 'default-server' > 13:29:37,745 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/soteria-web' for server 'default-server' > 13:29:37,781 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "soteria-ear-1.0.0.ear" (runtime-name : "soteria-ear-1.0.0.ear") > 13:29:37,908 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server > 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management > 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9990 > 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Beta1 (WildFly Core 5.0.0.Beta3) started in 10500ms - Started 707 of 931 services (430 services are lazy, passive or on-demand) > 13:30:09,195 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /soteria-web and security domain auth: javax.security.auth.message.AuthException > *+In case of a reboot (or stop and start) of Wildfly, only ONE of the TWO contexts manages to get the ServerAuthContext !+* > I attached an example project you can use to reproduce and detailed steps ! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2595) Average accumulate function should return null instead of zero when no facts are matched

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2595: ----------------------------------- Summary: Average accumulate function should return null instead of zero when no facts are matched Key: DROOLS-2595 URL: https://issues.jboss.org/browse/DROOLS-2595 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3724) stop-servers following by a reload operation could end up in a long period with an unmanageable domain

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3724?page=com.atlassian.jira.plugi... ] Yeray Borges updated WFCORE-3724: --------------------------------- Issue Type: Feature Request (was: Bug) > stop-servers following by a reload operation could end up in a long period with an unmanageable domain > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3724 > URL: https://issues.jboss.org/browse/WFCORE-3724 > Project: WildFly Core > Issue Type: Feature Request > Components: Management > Affects Versions: 5.0.0.Alpha2 > Reporter: Yeray Borges > Assignee: Yeray Borges > > When {{:stop-servers}} operation is used with a timeout different than 0, a graceful stop is performed on each server. > If the user executes {{/host=master:reload}} in a DC, the reload operation waits for the servers until they are completely stopped. This could be an issue for a DC since the user is unable to execute any operation meanwhile the reload op is waiting for the previous stop. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3724) stop-servers following by a reload operation could end up in a long period with an unmanageable domain

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3724?page=com.atlassian.jira.plugi... ] Yeray Borges updated WFCORE-3724: --------------------------------- Issue Type: Bug (was: Feature Request) > stop-servers following by a reload operation could end up in a long period with an unmanageable domain > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3724 > URL: https://issues.jboss.org/browse/WFCORE-3724 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 5.0.0.Alpha2 > Reporter: Yeray Borges > Assignee: Yeray Borges > > When {{:stop-servers}} operation is used with a timeout different than 0, a graceful stop is performed on each server. > If the user executes {{/host=master:reload}} in a DC, the reload operation waits for the servers until they are completely stopped. This could be an issue for a DC since the user is unable to execute any operation meanwhile the reload op is waiting for the previous stop. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10465) Upgrade WildFly Core 5.0.0.CR1

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-10465?page=com.atlassian.jira.plugin... ] Kabir Khan resolved WFLY-10465. ------------------------------- Resolution: Done > Upgrade WildFly Core 5.0.0.CR1 > ------------------------------ > > Key: WFLY-10465 > URL: https://issues.jboss.org/browse/WFLY-10465 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 13.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2426) ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails with lower amount of processors

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2426?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-2426: ------------------------------------- This issue can be investigated running this test https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/j... > ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails with lower amount of processors > --------------------------------------------------------------------------------------------- > > Key: DROOLS-2426 > URL: https://issues.jboss.org/browse/DROOLS-2426 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.7.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > > The test ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails randomly, when the machine on which it is run has smaller amount of processors (tested with 2). It fails because the engine doesn't produce expected amount of rule fires, so the test waits on a CountDownLatch. One idea what happens is that one agenda thread expires events from second agenda on some race condition. But that is a first guess after looking at the code. > Steps to reproduce: > 1. Change the number of parallel partitions to 2 here [1] > 2. Rebuild drools-core > 3. Run the test from PR [2] few times. > [1] https://github.com/kiegroup/drools/blob/63ea870c89591dfeae1276f582d825670... > [2] https://github.com/kiegroup/drools/pull/1843 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-269) Create new docker image for PR jobs

by Jeeva Kandasamy (JIRA)

[ https://issues.jboss.org/browse/SWSQE-269?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy updated SWSQE-269: ---------------------------------- Team: Infrastructure (was: Infrastructure) Add new Jenkins docker image for PR's in https://github.com/Kiali-QE/publish-jenkins-console > Create new docker image for PR jobs > ----------------------------------- > > Key: SWSQE-269 > URL: https://issues.jboss.org/browse/SWSQE-269 > Project: Kiali QE > Issue Type: QE Task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > > Currently, PR jobs are using kiali-qe-python Jenkins slave docker images. UI tests docker images needs to be isolated. > Create new Jenkins slave docker image for PR jobs -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-269) Create new docker image for PR jobs

by Jeeva Kandasamy (JIRA)

Jeeva Kandasamy created SWSQE-269: ------------------------------------- Summary: Create new docker image for PR jobs Key: SWSQE-269 URL: https://issues.jboss.org/browse/SWSQE-269 Project: Kiali QE Issue Type: QE Task Reporter: Jeeva Kandasamy Assignee: Jeeva Kandasamy Currently, PR jobs are using kiali-qe-python Jenkins slave docker images. UI tests docker images needs to be isolated. Create new Jenkins slave docker image for PR jobs -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10467) Drop support for mod_cluster subsystem model versions prior 1.5.0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10467?page=com.atlassian.jira.plugin... ] Radoslav Husar commented on WFLY-10467: --------------------------------------- The genuine cleanup is the incorporation of all the issues linked onto WFLY-10439, this only saves ~100 LOC. > Drop support for mod_cluster subsystem model versions prior 1.5.0 > ----------------------------------------------------------------- > > Key: WFLY-10467 > URL: https://issues.jboss.org/browse/WFLY-10467 > Project: WildFly > Issue Type: Task > Components: mod_cluster > Affects Versions: 13.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > * No need to keep unused model version 1.4.0 in enumeration. > * No need to keep transformer logic prior 1.5.0 which is the lowest supported (session draining strategy was supported in EAP 6.3/6.4 so no need to transform to older). > * No need for org.wildfly.extension.mod_cluster.controller.SessionDrainingStrategyChecker > * No need for 1.5.0 config in org.wildfly.extension.mod_cluster.ModClusterTransformersTestCase#createFailedOperationConfig -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10469) Dropped message did not match the computed checksum

by Romain Pelisse (JIRA)

Romain Pelisse created WFLY-10469: ------------------------------------- Summary: Dropped message did not match the computed checksum Key: WFLY-10469 URL: https://issues.jboss.org/browse/WFLY-10469 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Romain Pelisse Assignee: Paul Ferraro We saw this error during failover scenario *eap-7x-failover-http-session-shutdown-dist-async-auth-asymEncrypt* (scenario with "AUTH" and "ASYM_ENCRYPT" protocols enabled) (21 occurences). The error started to occur on *server* {code} 04:42:59,767 WARN [org.jgroups.protocols.ASYM_ENCRYPT] (thread-20,ee,perf21) perf21: exception occurred decrypting message [JBossINF] 04:42:59,768 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-10,ee,perf21) perf21: dropped message from perf20 as the message's checksum (3775292975120264796) did not match the computed checksum (2347657351) [JBossINF] 04:42:59,768 WARN [org.jgroups.protocols.ASYM_ENCRYPT] (thread-10,ee,perf21) perf21: unrecognized cipher; discarding message from perf20 {code} together with decrypting WARN messages 2 seconds after new cluster view was received: {code} 04:42:57,878 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,perf21) ISPN000094: Received new cluster view for channel ejb: [perf19|4] (3) [perf19, perf21, perf20] {code} Link to server log: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failov... Client did not log any error at that time. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2018