[JBoss JIRA] (WFLY-10417) Security API - Soteria - Jaspic - Error getting ServerAuthContext
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-10417?page=com.atlassian.jira.plugin... ]
Alessandro Moscatelli updated WFLY-10417:
-----------------------------------------
Description:
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 !
was:
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)
Steps to Reproduce:
Create an EAR Application with two WAR Web Application inside.
Create a jboss-app.xml for the EAR or/and two jboss-web.xml for the WARs declaring the security domain.
Create an implementation of HttpAuthenticationMechanism interface where you want (inside an Ejb module or in both the WARs Application).
Any combination of the above will trigger the problem anyway.
Now build and deploy on Wildfly 13 Beta 1, restart Wildfly.
Only one of the two Web Application will be able to obtain the ServerAuthContext.
Attachment: soteria.zip
image-2018-05-24-13-41-05-322.png
> 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: Darran Lofthouse
> 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)
8 years, 1 month
[JBoss JIRA] (WFCORE-3881) CLI + Kerberos authentication fails in CD13
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3881?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3881:
------------------------------------------
>From the log this appears to be the underlying error: -
{noformat}
Caused by: javax.security.auth.login.LoginException: unable to find LoginModule class: com.sun.security.auth.module.Krb5LoginModule from [Module "org.jboss.as.cli" version 5.0.0.Final-redhat-20180517 from local module loader @13a57a3b (finder: local module finder @7ca48474 (roots: /home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-ldap-kerberos/tests/target/dist/jboss-eap/modules/system/layers/base))]
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:338)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:334)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:333)
{noformat}
The following commit altered the dependencies of the CLI: -
https://github.com/wildfly/wildfly-core/commit/b48ea664f8129920ccde8b404d...
> CLI + Kerberos authentication fails in CD13
> -------------------------------------------
>
> Key: WFCORE-3881
> URL: https://issues.jboss.org/browse/WFCORE-3881
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 5.0.0.Beta4
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 5.0.0.Beta5
>
> Attachments: jboss-cli-CD12.log, jboss-cli-CD13.log, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD12.txt, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD13.txt
>
>
> Use case: Administrator wants to connect to CLI using kerberos ticket. It is not possible in CD13 with error
> {code}
> Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
> {code}
> Attaching logs of server and client for CD12 (OK) and CD13 (NOK)
> In server log there is missing message {{Server received authentication request}} so it makes me think problem is on client side.
> Comparing client logs there is difference
> * CD13
> {code}
> 11:32:58,924 TRACE [org.jboss.remoting.remote.client] Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
> {code}
> * CD12
> compared to CD12
> {code}
> 11:31:16,946 TRACE [org.wildfly.security.sasl.gssapi] GSSContext established, transitioning to negotiate security layer.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3881) CLI + Kerberos authentication fails in CD13
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3881?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved ELY-1590 to WFCORE-3881:
-----------------------------------------------
Project: WildFly Core (was: WildFly Elytron)
Key: WFCORE-3881 (was: ELY-1590)
Component/s: Security
(was: SASL)
Affects Version/s: 5.0.0.Beta4
(was: 1.3.2.Final)
Fix Version/s: 5.0.0.Beta5
(was: 1.3.3.CR1)
> CLI + Kerberos authentication fails in CD13
> -------------------------------------------
>
> Key: WFCORE-3881
> URL: https://issues.jboss.org/browse/WFCORE-3881
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 5.0.0.Beta4
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 5.0.0.Beta5
>
> Attachments: jboss-cli-CD12.log, jboss-cli-CD13.log, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD12.txt, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD13.txt
>
>
> Use case: Administrator wants to connect to CLI using kerberos ticket. It is not possible in CD13 with error
> {code}
> Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
> {code}
> Attaching logs of server and client for CD12 (OK) and CD13 (NOK)
> In server log there is missing message {{Server received authentication request}} so it makes me think problem is on client side.
> Comparing client logs there is difference
> * CD13
> {code}
> 11:32:58,924 TRACE [org.jboss.remoting.remote.client] Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
> {code}
> * CD12
> compared to CD12
> {code}
> 11:31:16,946 TRACE [org.wildfly.security.sasl.gssapi] GSSContext established, transitioning to negotiate security layer.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10443) Deprecate and schedule for removal redundant mod_cluster add/remove-[custom-]metric operations
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10443?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10443:
----------------------------------
Summary: Deprecate and schedule for removal redundant mod_cluster add/remove-[custom-]metric operations (was: Deprecate redundant mod_cluster add/remove-[custom-]metric operations)
> Deprecate and schedule for removal redundant mod_cluster add/remove-[custom-]metric operations
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-10443
> URL: https://issues.jboss.org/browse/WFLY-10443
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 13.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> There is a bunch of nonsensical operations registered at the mod_cluster configuration resource, see https://wildscribe.github.io/WildFly/12.0/subsystem/modcluster/mod-cluste...
> These are:
> * add-custom-metric Add new custom metric to the load balancer provider.
> * add-metric Add new metric to the load balancer provider.
> * remove-custom-metric Remove a custom metric from the load balancer provider.
> * remove-metric Remove a metric from the load balancer provider.
> These should have been deprecated long time ago, since they are just redundant. Regular model :add/:remove operations should be used for manipulating load metrics.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10443) Deprecate redundant mod_cluster add/remove-[custom-]metric operations
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10443?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10443:
----------------------------------
Description:
There is a bunch of nonsensical operations registered at the mod_cluster configuration resource, see https://wildscribe.github.io/WildFly/12.0/subsystem/modcluster/mod-cluste...
These are:
* add-custom-metric Add new custom metric to the load balancer provider.
* add-metric Add new metric to the load balancer provider.
* remove-custom-metric Remove a custom metric from the load balancer provider.
* remove-metric Remove a metric from the load balancer provider.
These should have been deprecated long time ago, since they are just redundant. Regular model :add/:remove operations should be used for manipulating load metrics.
was:
There is a bunch of nonsensical operations registered at the mod_cluster configuration resource, see https://wildscribe.github.io/WildFly/12.0/subsystem/modcluster/mod-cluste...
These are:
* add-custom-metric Add new custom metric to the load balancer provider.
* add-metric Add new metric to the load balancer provider.
* remove-custom-metric Remove a custom metric from the load balancer provider.
* remove-metric Remove a metric from the load balancer provider.
These should have been deprecated long time ago, since they are just redundant. Regular model :add operations should be used for manipulating load metrics.
> Deprecate redundant mod_cluster add/remove-[custom-]metric operations
> ---------------------------------------------------------------------
>
> Key: WFLY-10443
> URL: https://issues.jboss.org/browse/WFLY-10443
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 13.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> There is a bunch of nonsensical operations registered at the mod_cluster configuration resource, see https://wildscribe.github.io/WildFly/12.0/subsystem/modcluster/mod-cluste...
> These are:
> * add-custom-metric Add new custom metric to the load balancer provider.
> * add-metric Add new metric to the load balancer provider.
> * remove-custom-metric Remove a custom metric from the load balancer provider.
> * remove-metric Remove a metric from the load balancer provider.
> These should have been deprecated long time ago, since they are just redundant. Regular model :add/:remove operations should be used for manipulating load metrics.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1590) CLI + Kerberos authentication fails in CD13
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1590?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1590:
----------------------------------
Fix Version/s: 1.3.3.CR1
> CLI + Kerberos authentication fails in CD13
> -------------------------------------------
>
> Key: ELY-1590
> URL: https://issues.jboss.org/browse/ELY-1590
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.3.2.Final
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.3.3.CR1
>
> Attachments: jboss-cli-CD12.log, jboss-cli-CD13.log, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD12.txt, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD13.txt
>
>
> Use case: Administrator wants to connect to CLI using kerberos ticket. It is not possible in CD13 with error
> {code}
> Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
> {code}
> Attaching logs of server and client for CD12 (OK) and CD13 (NOK)
> In server log there is missing message {{Server received authentication request}} so it makes me think problem is on client side.
> Comparing client logs there is difference
> * CD13
> {code}
> 11:32:58,924 TRACE [org.jboss.remoting.remote.client] Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
> {code}
> * CD12
> compared to CD12
> {code}
> 11:31:16,946 TRACE [org.wildfly.security.sasl.gssapi] GSSContext established, transitioning to negotiate security layer.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1590) CLI + Kerberos authentication fails in CD13
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1590?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned ELY-1590:
-------------------------------------
Assignee: Darran Lofthouse
> CLI + Kerberos authentication fails in CD13
> -------------------------------------------
>
> Key: ELY-1590
> URL: https://issues.jboss.org/browse/ELY-1590
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.3.2.Final
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: jboss-cli-CD12.log, jboss-cli-CD13.log, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD12.txt, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD13.txt
>
>
> Use case: Administrator wants to connect to CLI using kerberos ticket. It is not possible in CD13 with error
> {code}
> Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
> {code}
> Attaching logs of server and client for CD12 (OK) and CD13 (NOK)
> In server log there is missing message {{Server received authentication request}} so it makes me think problem is on client side.
> Comparing client logs there is difference
> * CD13
> {code}
> 11:32:58,924 TRACE [org.jboss.remoting.remote.client] Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
> {code}
> * CD12
> compared to CD12
> {code}
> 11:31:16,946 TRACE [org.wildfly.security.sasl.gssapi] GSSContext established, transitioning to negotiate security layer.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10443) Deprecate redundant mod_cluster add/remove-[custom-]metric operations
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-10443:
-------------------------------------
Summary: Deprecate redundant mod_cluster add/remove-[custom-]metric operations
Key: WFLY-10443
URL: https://issues.jboss.org/browse/WFLY-10443
Project: WildFly
Issue Type: Bug
Components: mod_cluster
Reporter: Radoslav Husar
Assignee: Radoslav Husar
There is a bunch of nonsensical operations registered at the mod_cluster configuration resource, see https://wildscribe.github.io/WildFly/12.0/subsystem/modcluster/mod-cluste...
These are:
* add-custom-metric Add new custom metric to the load balancer provider.
* add-metric Add new metric to the load balancer provider.
* remove-custom-metric Remove a custom metric from the load balancer provider.
* remove-metric Remove a metric from the load balancer provider.
These should have been deprecated long time ago, since they are just redundant. Regular model :add operations should be used for manipulating load metrics.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month