Generic JBossWeb Authentication Framework

[anil.saldhana]

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.

[starksm64]

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.

[anil.saldhana]

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.

[anil.saldhana]

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.

[starksm64]

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.

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.

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.

[anil.saldhana]

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.

[starksm64]

Yes, its obsolete and should be removed.

[anil.saldhana]

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}

[starksm64]

Great.

[anil.saldhana]

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?

[anil.saldhana]

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.

[anil.saldhana]

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.

[anil.saldhana]

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.

[leifj]

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.

[anil.saldhana]

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.