0 Replies Latest reply on May 11, 2011 9:04 AM by justincranford

    LoginModule chain bug? - SSL renegotiation is disabled, closing connection

    justincranford

      I am mixing DataSourceLoginModule with BaseCertLoginModule in my security domain. I got this to work, but only by enabling SSL renegotiation in server.xml (see HTTPS connector attribute below). The problem is JBoss turns off SSL renegotiation by default which seems to break the Login Module functionality. Turning on SSL renegotiation is not a viable option because it exposes by server to the SSL vulnerability announced in 2009.

       

           allowUnsafeLegacyRenegotiation="true"

       

      Is there a workaround to make these JBoss Login Modules work without SSL renegotiation? Is this a bug in JBoss itself?

       

      Here is my login-config.xml. It attempts to authenticate using DataSourceLoginModule first (ex: web.xml uses BASIC over HTTPS). If the user is authenticated, it authorizes there too and skips the other modules. If authentication fails though, the Security Domain attempts to authenticate using BaseCertLoginModule next (ex: web.xml uses CLIENT-CERT over HTTPS). If that works, a third module is used to authorized the user (different WHERE clauses).

       

         <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="sufficient">
          <module-option name="dsJndiName">java:/JustinCranfordDataSource</module-option>
          <module-option name="principalsQuery">SELECT password FROM actor WHERE name=?</module-option>
          <module-option name="rolesQuery">SELECT r.name,'Roles' FROM actor a,role r WHERE r.id=a.roleid AND a.name=?</module-option>
          <module-option name="hashAlgorithm">MD5</module-option>
          <module-option name="hashEncoding">base64</module-option>
          <module-option name="unauthenticatedIdentity">unauthenticated</module-option>
         </login-module>

         <login-module code="org.jboss.security.auth.spi.BaseCertLoginModule" flag="required">
          <module-option name="password-stacking">useFirstPass</module-option>
          <module-option name="securityDomain">java:/jaas/JustinCranfordSecurityDomain</module-option>
          <module-option name="unauthenticatedIdentity">unauthenticated</module-option>
         </login-module>

         <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
          <module-option name="password-stacking">useFirstPass</module-option>
          <module-option name="dsJndiName">java:/JustinCranfordDataSource</module-option>
          <module-option name="principalsQuery">SELECT password FROM actor WHERE dname=?</module-option>
          <module-option name="rolesQuery">SELECT r.name,'Roles' FROM actor a,role r WHERE r.id=a.roleid AND a.dname=?</module-option>
          <module-option name="hashAlgorithm">MD5</module-option>
          <module-option name="hashEncoding">base64</module-option>
          <module-option name="unauthenticatedIdentity">unauthenticated</module-option>
         </login-module>

       

      So, I have two web apps linked to the same Security Domain (CLIENT-CERT versus BASIC). The BASIC web app can authenticate and authorize even if SSL renegotiation is off, but my CLIENT-CERT web app blows up in Resteasy with this exception. This seems like a bug in JBoss to me, but I am hoping there is a workaround.

       

      JBoss security TRACE logs are attached showing how it BaseCertLoginModule works with SSL renegotiation turned on, and breaks when it is off.

       

      [org.jboss.web.tomcat.security.JBossWebRealm] Error during authenticate: java.lang.IllegalStateException: Security Context has not been set

      at org.jboss.web.tomcat.security.SecurityAssociationActions$SetPrincipalInfoAction.run(SecurityAssociationActions.java:70) [:6.0.0.Final]

      at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_24]

      at org.jboss.web.tomcat.security.SecurityAssociationActions.setPrincipalInfo(SecurityAssociationActions.java:270) [:6.0.0.Final]

      at org.jboss.web.tomcat.security.JBossWebRealm.authenticate(JBossWebRealm.java:226) [:6.0.0.Final]

      at org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:142) [:6.0.0.Final]

      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:559) [:6.0.0.Final]

      at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]

      at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]

      at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]

      at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]

      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]

      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]

      at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]

      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]

      at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]

      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]

      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final]

      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final]

      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]

       

       

       

      at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]