Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-10417

Security API - Soteria - Jaspic - Error getting ServerAuthContext

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Critical
    • 15.0.0.Final
    • 13.0.0.Beta1, 14.0.0.Final
    • Security
    • None
    • Hide

      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 after the restart.

      Show
      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 after the restart.

    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 !

      Attachments

        Issue Links

          duplicates

          Bug - A problem that impairs or prevents the functions of the product. WFLY-8431 Race conditions in JASPIC registration code

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is incorporated by

          Component Upgrade - A task tracking an update to a bundled component or revision of component upstream of the project. WFCORE-3898 Upgrade PicketBox to 5.1.0.Final

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved
          relates to

          Feature Request - Feature requests from customers and/or users WFLY-10172 Add support for JSR-375 EE Security as required for Java EE 8

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              rhn-support-ivassile Ilia Vassilev
              alessandro.moscatelli@live.com Alessandro Moscatelli (Inactive)
              Votes:
              3 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: