1 2 Previous Next 16 Replies Latest reply on Mar 6, 2006 2:20 AM by Anil Saldanha

    Generic JBossWeb Authentication Framework

    Anil Saldanha Master

      I would like to dedicate this thread for discussion on the potential flexibility of the Tomcat Authentication Framework.

      Reference to a JIRA issue:
      http://jira.jboss.com/jira/browse/JBAS-2481

      Generic Overview:
      Tomcat has authenticators for BASIC, FORM-AUTH,CLIENT-CERT and DIGEST configured at the context level via a properties file loaded into org.catalina.startup.ContextConfig object. This ContextConfig object gets added as a lifecycle listener into org.apache.catalina.core.StandardContext init() method as shown below:

      public void init() throws Exception {
      
       .....
       StandardHost host=new StandardHost();
       host.setName(hostName);
       host.setAutoDeploy(false);
       .....
      
       ContextConfig config = new ContextConfig();
       this.addLifecycleListener(config);
      
       ......
       }
      


      ContextConfig code is located at:
      http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ContextConfig.java

      And the properties file that allows us to plug in custom authenticators is
      http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/Authenticators.properties

      We need to externalize this way of plugging in custom authenticators.

      One Possible Solution to plug in customized authenticators is:
      a) Make the ContextConfig an attribute of StandardContext. (Simple Tomcat codebase change)
      b) Create ContextConfig object .
      c) Call ContextConfig.setCustomAuthenticators with a map of authenticators. (Issue: Need to understand the semantics of the keys that can be customizable. Currently they are keyed for the http auth methods which is restrictive).
      c) Set the context config object in before the StandardConfig init() method is called - actually via a JMX invocation in TomcatDeployer.


        • 1. Re: Generic JBossWeb Authentication Framework
          Scott Stark Master

          The externalization suggestion looks correct. It seems like the context config authenticator map keys are simply whatever is passed in via the web.xml login-config/auth-method is. Where are you seeing the auth methods being restricted? The web-app.xml auth-type is not restricted by the xsd model.

          • 2. Re: Generic JBossWeb Authentication Framework
            Anil Saldanha Master

            Your assessment of the auth map key not being restrictive is correct.

            I would like your feedback on this, Scott....

            <server>
            
             <mbean code="org.jboss.web.tomcat.tc5.Tomcat5"
             name="jboss.web:service=WebServer" xmbean-dd="META-INF/webserver-xmbean.xml">
            
             <!-- Pass in any configuration -->
             <attribute name="Config">
             <tomcat-config>
             <authenticators>
             <authenticator key="BASIC">org.apache.catalina.authenticator.BasicAuthenticator</authenticator>
             <authenticator key="CLIENT-CERT">org.apache.catalina.authenticator.SSLAuthenticator</authenticator>
             <authenticator key="DIGEST">org.apache.catalina.authenticator.DigestAuthenticator</authenticator>
             <authenticator key="FORM">org.apache.catalina.authenticator.FormAuthenticator</authenticator>
             <authenticator key="NONE">org.apache.catalina.authenticator.NonLoginAuthenticator</authenticator>
             </authenticators>
             </tomcat-config>
             </attribute>
             <!-- The JAAS security domain to use in the absense of an explicit
             security-domain specification in the war WEB-INF/jboss-web.xml
             -->
             <attribute name="DefaultSecurityDomain">java:/jaas/other</attribute>
            


            Topic 1:
            I would like to use the setConfig(Element config) contract of the AbstractWebContainer. I could have just placed the properties format in an attribute, but wanted something cleaner. Are you ok with above format? The tomcat-config element is added to allow other configuration apart from authenticators in the Config element.

            Topic 2:
            An issue that I have not checked completely is that the mx layer is passing an Element created using DOM1, to the method setConfig. So basically DOM2 usage via org.jboss.util.xml.DOMUtils is failing on Node.getLocalName. Hence I will need to use DOM1 parsing of the Element, which means two custom methods based on DOM1 added to Tomcat5 class.

            I have finished externalizing the tomcat authenticators in a pluggable fashion at the tomcat sar level. I just get an harmless exception from AuthenticatorBase in tomcat saying that the authenticator has already been started. I am unsure how much the setCustomAuthenticators contract on the ContextConfig has been tested by the tomcat community. I will need a simple debug session to see how we can avoid this exception.

            Topic 3 (Low Priority):
            Since we have externalized ContextConfig from StandardContext, I am wondering maybe we should ask Tomcat to externalize HostConfig from StandardHost and likewise with other xxxConfig entities. This will extend pluggability of Tomcat wrt System Integrators.


            • 3. Re: Generic JBossWeb Authentication Framework
              Anil Saldanha Master

              That error in the AuthenticatorBase was because I first attempted instantiation of the authenticators in the Tomcat5 class - all the contexts were sharing the same set of authenticator instances. The solution was to instantiate in the TomcatDeployer so that each context gets its own set of authenticator instances.

              AuthenticatorBase class before starting an authenticator checks whether it has already been started. If yes, throws an error. So if all the contexts share the same set of authenticator instances, this is bound to happen.

              • 4. Re: Generic JBossWeb Authentication Framework
                Scott Stark Master

                 

                "anil.saldhana@jboss.com" wrote:

                Topic 1:
                I would like to use the setConfig(Element config) contract of the AbstractWebContainer. I could have just placed the properties format in an attribute, but wanted something cleaner. Are you ok with above format? The tomcat-config element is added to allow other configuration apart from authenticators in the Config element.

                Topic 2:
                An issue that I have not checked completely is that the mx layer is passing an Element created using DOM1, to the method setConfig. So basically DOM2 usage via org.jboss.util.xml.DOMUtils is failing on Node.getLocalName. Hence I will need to use DOM1 parsing of the Element, which means two custom methods based on DOM1 added to Tomcat5 class.

                I don't want to start resuing the setConfig(Element) attribute for passing arbitrary configuration. We need to be moving away from parsing xml in the services layer. We have support for javabean and jbossxb style of attributes that can be used instead. See http://wiki.jboss.org/wiki/Wiki.jsp?page=SERVICEdotXML for serialDataType="javaBean" and serialDataType="jbxb" style of attributes.

                "anil.saldhana@jboss.com" wrote:

                I have finished externalizing the tomcat authenticators in a pluggable fashion at the tomcat sar level. I just get an harmless exception from AuthenticatorBase in tomcat saying that the authenticator has already been started. I am unsure how much the setCustomAuthenticators contract on the ContextConfig has been tested by the tomcat community. I will need a simple debug session to see how we can avoid this exception.

                We need to submit a patch to tomcat to enable our usecase going forward. Synch up with Remy so that there is not a lot of back and forth through the bug database.

                "anil.saldhana@jboss.com" wrote:

                Topic 3 (Low Priority):
                Since we have externalized ContextConfig from StandardContext, I am wondering maybe we should ask Tomcat to externalize HostConfig from StandardHost and likewise with other xxxConfig entities. This will extend pluggability of Tomcat wrt System Integrators.

                The bigger issue is cleaning up the configuration to be compatible with our pojo based configuration view. We should be able to configure the embedded tomcat without jmx and still be able to expose a jmx management view.

                • 5. Re: Generic JBossWeb Authentication Framework
                  Anil Saldanha Master

                  jbxb style attributes is exactly what I need. Thanks for the link, Scott. I am glad I crossverified with you.

                  Also, I think we should think about removing the setContext contract from AbstractWebContainer.

                  • 6. Re: Generic JBossWeb Authentication Framework
                    Scott Stark Master

                    Yes, its obsolete and should be removed.

                    • 7. Re: Generic JBossWeb Authentication Framework
                      Anil Saldanha Master

                      The jbxb style enabled attribute in the Tomcat5 service is as follows:

                      <!-- You can configure a set of authenticators keyed by http-auth method used -->
                       <attribute name="Authenticators" serialDataType="jbxb">
                       <java:properties xmlns:java="urn:jboss:java-properties"
                       xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
                       xs:schemaLocation="urn:jboss:java-properties resource:java-properties_1_0.xsd">
                       <java:property>
                       <java:key>BASIC</java:key>
                       <java:value>org.apache.catalina.authenticator.BasicAuthenticator</java:value>
                       </java:property>
                       <java:property>
                       <java:key>CLIENT-CERT</java:key>
                       <java:value>org.apache.catalina.authenticator.SSLAuthenticator</java:value>
                       </java:property>
                       <java:property>
                       <java:key>DIGEST</java:key>
                       <java:value>org.apache.catalina.authenticator.DigestAuthenticator</java:value>
                       </java:property>
                       <java:property>
                       <java:key>FORM</java:key>
                       <java:value>org.apache.catalina.authenticator.FormAuthenticator</java:value>
                       </java:property>
                       <java:property>
                       <java:key>NONE</java:key>
                       <java:value>org.apache.catalina.authenticator.NonLoginAuthenticator</java:value>
                       </java:property>
                       </java:properties>
                       </java:properties>
                       </attribute>
                      


                      From the debug log:
                      2005-11-28 15:52:26,515 DEBUG [org.jboss.system.ServiceCreator]Created bean: jboss.web:service=WebServer
                      2005-11-28 15:52:26,671 DEBUG [org.jboss.system.ServiceConfigurator] Authenticators set to {FORM=org.apache.catalina.authenticator.FormAuthenticator,BASIC=org.apache.catalina.authenticator.BasicAuthenticator, DIGEST=org.apache.catalina.authenticator.DigestAuthenticator,NONE=org.apache.catalina.authenticator.NonLoginAuthenticator, CLIENT-CERT=org.apache.catalina.authenticator.SSLAuthenticator} in
                       jboss.web:service=WebServer
                      2005-11-28 15:52:26,671 DEBUG [org.jboss.web.tomcat.tc5.Tomcat5] Passed set of authenticators={FORM=org.apache.catalina.authenticator.FormAuthenticator, BASIC=org.apache.catalina.authenticator.BasicAuthenticator, DIGEST=org.apache.catalina.authenticator.DigestAuthenticator, NONE=org.apache.catalina.authenticator.NonLoginAuthenticator, CLIENT-CERT=org.apache.catalina.authenticator.SSLAuthenticator}
                      



                      • 9. Re: Generic JBossWeb Authentication Framework
                        Anil Saldanha Master

                        Got feedback from Remy that he would not accept the patch because the contextConfig class name is a configurable parameter at the Host level.

                        A very valid pointer from Remy. But it does not satisfy our needs.

                        I have replied Remy with:

                        I am interested in ContextConfig.setCustomAuthenticators as I want the authenticators to be configurable. Sending the classname of the ContextConfig to the Host element does not help, because
                        
                        1) I cannot set the authenticators and
                        2) I will have to plug in my own version of ContextConfig class, in the current setup.
                         - I cannot do it using inheritance as ContextConfig is final and I do not think it is wise to
                        have my own ContextConfig class.
                        
                        All I am asking is to make it possible to pass an instance of ContextConfig to either
                        StandardContext or Host...
                        
                        I welcome your ideas/pointers?
                        


                        • 10. Re: Generic JBossWeb Authentication Framework
                          Anil Saldanha Master

                          Objectives
                          ===========
                          Externalize tomcat authenticators at
                          a) the tomcat service level (implies we do it at the engine level ie across all hosts).
                          b) the tomcat host level (across all the contexts or webapps at the host level)
                          c) the tomcat context level (at each webapp level)


                          Remy thinks that the contextClassName attribute that is configurable in the host element
                          in server.xml is a cleaner approach. (ofcourse, he agrees that the ContextConfig class
                          does not have to be final). An issue with this is:
                          - Tomcat codebase does Class.forName(contextClassName) which will instantiate a
                          ContextConfig class. But if an user wishes to have different combinations of the
                          authenticators at the host level for different hosts, then he will have to write
                          different classes of type "ContextConfig". (An Assumption is that an user will want to have multiple
                          hosts at the engine level). A different Class of type ContextConfig is required because
                          we are unable to plug in the set of authenticators via any configuration. All we have
                          is a FQN of the contextClassName attribute passed to the Host element.




                          Item 1:
                          Now if I have to configure the set of authenticators at the service/engine level such that
                          they are applicable across hosts, then I can use the configuration I proposed
                          (that uses the jbxb style) in jbossweb55-service.sar/META-INF/jboss-service.xml and we can apply it
                          whenever an instanceof StandardContext is
                          constructed in Tomcat5. This is where my original patch is required. I really need to
                          pass in a preconstructed instance of ContextConfig with custom authenticators to the
                          StandardContext.init method.....

                          Item 2:
                          For the configuration of authenticators at the web app level, we can introduce the
                          configuration at the jboss-web.xml level and the tomcat deployer can again reuse
                          my original patch concept to set the custom authenticators into a ContextConfig
                          and plug it into StandardContext. (I may be wrong because I have not given a lot of
                          thought/done research on Item 2 usecase yet).


                          Pointers/feedback/corrections welcome.

                          • 11. Re: Generic JBossWeb Authentication Framework
                            Anil Saldanha Master

                            Tomcat 5.5.13 was released yesterday. The change of ContextConfig class becoming non-final has been added. This gives the flexibility to users to extend the ContextConfig class and configure at the Host level.

                            The other requested change of making the init() method of StandardContext aware of an externally configured ContextConfig instance, will be released in the next version of Tomcat (5.5.14). This change will give the flexibility to make the Tomcat Authenticators completely externalizable at the Tomcat service/engine level or individual web-app level.

                            Thanks to Remy.

                            • 12. Re: Generic JBossWeb Authentication Framework
                              Anil Saldanha Master

                              Externalization of the tomcat authenticators has been done to allow the authenticators to be configured at the tomcat sar level implies applied to all web applications running in the tomcat instance. Also any web application can override the set of applicable authenticators by configuring its jboss-web.xml

                              The main testsuite in HEAD has a target called "tomcat-federation-tests" that tests this functionality.

                              $>./build.sh
                              $>ant tomcat-federation-tests
                              


                              The configuration of the ContextConfig at the host level somehow seemed to have no effect on configuring the authenticators for all the web applications underneath. This may require some additional debug in the TC codebase but is not a priority for now.


                              • 13. Re: Generic JBossWeb Authentication Framework
                                Leif Johansson Newbie

                                This way of plugging in new authentication mechanisms for Tomcat suffices for a clean implementation of a GSSAPI/Negotiate implementation. However there is still the question of how to hand forwarded credentials upstream to JBoss. In the BASIC, DIGEST, X509 cases the JBossSecurityMgrRealm has apropriate authenticate calls. None of these are sufficient for general handshake-based authentication protocols like GSSAPI.

                                • 14. Re: Generic JBossWeb Authentication Framework
                                  Anil Saldanha Master

                                  We will need to look at the AuthenticatorBase construct in Tomcat to achieve integration with external security providers. Externalization of the tomcat authenticators was the first step in the direction.

                                  Please review the other threads on this design forum, many of them aim at generalizing the authentication and authorization layers.

                                  Integration with GSS API is interesting because I think they will find their way into the J2SE in the future (or they already there??). Also the GSS/Negotitate protocol semantics may need to be generalized in JBoss, for possible inclusion of the Windows Infocard initiative which is based on handshake (SecureConversation), Metadata exchange, Trust, security policy etc.

                                  1 2 Previous Next