June 2018 - jboss-jira - Jboss List Archives

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-10417?page=com.atlassian.jira.plugin... ] Kabir Khan resolved WFLY-10417. ------------------------------- Resolution: Done [~ivassile] Resolving as it looks like the Picketbox upgrade incorporates this. If that is wrong, please reopen this issue > 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: 14.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)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ] Sanne Grinovero commented on WFLY-10520: ---------------------------------------- [~dmlloyd] suggested on chat to keep the transformer in a separate module "so we can deprecate & remove it later on" That's an excellent point, and we also need a plan to make sure we can actually get rid of it - eventually. For starters, could we make sure that each time the "transform" method is triggered an appropriate logging message is generated? What else should we do to ensure people will swiftly move on - or at least have no way to not notice? I'm understanding the plan is to have this transformer disabled by default, enabled by opt-in. Would it be sensible to have a default which would just check the bytecode for removed signatures and fail the deployment? > Add Hibernate ORM 5.3 compatibility transformer > ----------------------------------------------- > > Key: WFLY-10520 > URL: https://issues.jboss.org/browse/WFLY-10520 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Gail Badner > Assignee: Scott Marlow > Fix For: 14.0.0.CR1 > > > A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10538) JMSService installs services into the root service container

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-10538: ------------------------------------- Summary: JMSService installs services into the root service container Key: WFLY-10538 URL: https://issues.jboss.org/browse/WFLY-10538 Project: WildFly Issue Type: Bug Components: JMS Reporter: Stuart Douglas Assignee: Stuart Douglas This means it is outside the ContainerStateMonitor -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10537) PartitionManagerService is created in the root service container

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-10537: ------------------------------------- Summary: PartitionManagerService is created in the root service container Key: WFLY-10537 URL: https://issues.jboss.org/browse/WFLY-10537 Project: WildFly Issue Type: Bug Components: Security Reporter: Stuart Douglas Assignee: Stuart Douglas This means it is not managed by the ContainerStabilityMonitor -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10536) PooledConnectionFactory JNDI aliases are created in the root service container

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-10536: ------------------------------------- Summary: PooledConnectionFactory JNDI aliases are created in the root service container Key: WFLY-10536 URL: https://issues.jboss.org/browse/WFLY-10536 Project: WildFly Issue Type: Bug Components: JMS Reporter: Stuart Douglas Assignee: Stuart Douglas This means they are not covered by the container state monitor -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10535) PooledConnectionFactory JNDI aliases are created in the root service container

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-10535: ------------------------------------- Summary: PooledConnectionFactory JNDI aliases are created in the root service container Key: WFLY-10535 URL: https://issues.jboss.org/browse/WFLY-10535 Project: WildFly Issue Type: Bug Components: JMS Reporter: Stuart Douglas Assignee: Stuart Douglas This means they are not covered by the container state monitor -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10534) Datasource JNDI bindings are created in the root service container

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-10534: ------------------------------------- Summary: Datasource JNDI bindings are created in the root service container Key: WFLY-10534 URL: https://issues.jboss.org/browse/WFLY-10534 Project: WildFly Issue Type: Bug Components: JCA Reporter: Stuart Douglas Assignee: Stuart Douglas This means they are outside the stability controller, which means there is a small chance they can cause random deployment failure -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-284) Fix Update sites on jenkins2

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-284?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-284: -------------------------------- Team: Infrastructure (was: Infrastructure) Sprint: Kiali QE Sprint 6 > Fix Update sites on jenkins2 > ---------------------------- > > Key: SWSQE-284 > URL: https://issues.jboss.org/browse/SWSQE-284 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Filip Brychta > > Update sites on jenkins2 contain http://ci-ops-jenkins-update-site.rhev-ci-vms.eng.rdu2.redhat.com/update-... as a default update side which is not working. Default one was overwritten by this. We need to add back default one and fix this redhat update site. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3919) Missing algorithms in jdbc-realm scram-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3919?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-3919: ------------------------------- Description: As discovered in https://developer.jboss.org/message/983249, ALGORITHM_SCRAM_SHA_384 and ALGORITHM_SCRAM_SHA_512 are missing in scram-mapper of jdbc-realm in Elytron subsystem. (was: ALGORITHM_SCRAM_SHA_384 and ALGORITHM_SCRAM_SHA_512 are missing in scram-mapper of jdbc-realm in Elytron subsystem.) > Missing algorithms in jdbc-realm scram-mapper > --------------------------------------------- > > Key: WFCORE-3919 > URL: https://issues.jboss.org/browse/WFCORE-3919 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > > As discovered in https://developer.jboss.org/message/983249, ALGORITHM_SCRAM_SHA_384 and ALGORITHM_SCRAM_SHA_512 are missing in scram-mapper of jdbc-realm in Elytron subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3919) Missing algorithms in jdbc-realm scram-mapper

by Jan Kalina (JIRA)

Jan Kalina created WFCORE-3919: ---------------------------------- Summary: Missing algorithms in jdbc-realm scram-mapper Key: WFCORE-3919 URL: https://issues.jboss.org/browse/WFCORE-3919 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Jan Kalina Assignee: Jan Kalina ALGORITHM_SCRAM_SHA_384 and ALGORITHM_SCRAM_SHA_512 are missing in scram-mapper of jdbc-realm in Elytron subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

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 June 2018