tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: I have some new FormAuthenticator code for Tomcat.
Date Mon, 27 Jun 2005 18:28:24 GMT
I am -1 for this for the following reasons (in order of importance):

1. Your reference to sending an encrypted user certificate file to the 
server demonstrates a lack of understanding of PKI that undermines my 
confidence that you know what you are doing when it comes to security.
2. JAAS provides plug-in authentication.
3. Password hashing is already supported.
4. The implementation is Tomcat specific and hence is non-portable.


D M wrote:
> Hi,
> I've been working on some code for Form authentication in Tomcat that I think you all
might be interested in. In addition to implementing the current J2EE/Servlet spec for authentication
(i.e. j_security_check with two keys: j_username, j_password authenticated with the Realm),
it also offers some major increases in authentication capabilities with the simple inclusion
of an XML file in a web-context's WEB-INF folder.
> I created this flexible Form authentication with a main concern being that it be as non-intrusive
on Catalina code and the Servlet spec as possible. To use this new code, only one line in
a properties file needs to be changed:
>  ( )
>  FORM=com.spiralgeneration.formauthentication.FormAuthenticator
> Obviously, if you are interested in the code, the above class' package would be changed
to a Catalina package.
> While this API implementation does have a number of new classes, there are ZERO changes
for any existing Catalina code (save for replacing FormAuthenticator with this new FormAuthenticator).
The classes could even be kept in the current jar I've got them in.
> There is also no impact on the Servlet spec for Form authentication. There are ZERO changes
to web.xml or any other deployment or code files of a web context. If a web application wants
to use the usual username + password authentication, the Form authentication will act exactly
as it does currently in Tomcat. If the web application wants to use the new form authentication,
all that's needed is to include "WEB-INF/form-authentication.xml." That's it. ALL web.xml
configurations remain the same (e.g. securing pages is still done via security-constraint).
However, with that XML file included the application gets the following capabilities:
> 1. Plug in any pre-authentication key manipulators (called KeyPreparer).
> For example, if a database stores all passwords in a one-way hash, you can register (in
the XML) the password key to be "prepared" by your password-hashing KeyPreparer just prior
to sending to an authenticator. (I have created an example of this) This offers a lot of flexibility
in terms of storing login keys. If it were necessary to stop hashing passwords, the deployer
could simply remove one line in an XML file and the KeyPreparer is "unplugged."
> 2. Plug in any number of custom authenticators (called PluginAuthenticator).
> Currently, the only authentication possible in the Catalina implementation is a username
and password to a Realm. With this implementation a web context could require a username,
password and a file. Because this form authentication accepts multipart/form-data POSTs (it
converts an uploaded file to, the web context could require that users
carry a USB key ring (that has an encrypted file for example) so when they login from a remote
computer (in a web browser) they can point an input of type=file to that file. The developers
could then have two authenticators:
>  1. The default authentication (All PluginAuthenticators have controlled access to the
>      which checks the username and password.
>  2. Their custom authenticator that checks an encrypted file matches the data
>      stored for the username (they register for the username and file in XML).
> (I have created an example of this)
> 3. Create as many authentication keys (called SecurityRoleKeys) as needed.
> In the current authentication model, only a username and password are allowed. Here,
a web context could (in XML) require a username, a password, a file, a random number and any
other keys they wish. All keys can be given a class type to which they will be converted by
the form authentication. For example, the username and password would likely be java.lang.String,
the random number java.lang.Long and the file (I have JavaDocs and an
example XML file that show all the allowed types) So a KeyPreparer or PluginAuthenticator
can expect a key to be a certain type.
> 4. Accept multipart/form-data POSTs.
> As mentioned above, this form authentication can handle login forms of enctype="multipart/form-data".
As a result, it enables the ability to require file data for logins. For example, an encrypted
certificate file installed on an external USB drive or locally on a hard drive.
> 5. Set a default secure page for logins with no saved request.
> Currently, if a user goes directly to the login page and logs in, Tomcat will throw an
error, "No web resource available at /j_security_check" (or something like that). With this
new form authentication, in the XML the deployer can set a default secure redirect page. For
example, if the deployer sets the default page as "/secure-default.jsp" and a user goes directly
to the login page and successfully authenticates, they'll be sent to "/secure-default.jsp"
instead of getting an error.
> With all of the above capabilities, there are also quite a few configuration options.
For example, authenticators can be set as Required or Supported (among other things). The
options are too many to be of value in this email, but I have detailed explanations of them
in my JavaDocs, example application, DTD and help files.
> If the Tomcat team is interested in this code just let me know and I can send the jar
file, example app., install instructions (it's pretty simple), JavaDocs, etc. I think this
would be a good addition to the current authentication API not just because of the added capabilities
but also because of its relative lack of impact on the current code and API.
> (I have used this new form authentication in Tomcat 4.x, 5.x and JBoss w/Tomcat 5.x both
with and without SingleSignOn)
> - David Musicant
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message