You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by D M <da...@yahoo.com> on 2005/06/27 18:20:41 UTC
I have some new FormAuthenticator code for Tomcat.
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:
( Authenticators.properties )
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 java.io.InputStream), 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 Realm)
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 java.io.InputStream. (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
http://mail.yahoo.com
Re: I have some new FormAuthenticator code for Tomcat.
Posted by Remy Maucherat <re...@apache.org>.
Mark Thomas wrote:
> Remy Maucherat wrote:
> <snip>
>> I'll be the first to admit, however, that FORM (and the other auth
>> methods from the spec) are insufficient and not flexible enough, and I
>> am not completely against adding additional custom auth-methods.
>
> Can you give some use cases where the spec falls short?
Well, it can be annoying to integrate with the rest of a webapp, the
constraints are a limited, and it only does l/p.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: I have some new FormAuthenticator code for Tomcat.
Posted by Mark Thomas <ma...@apache.org>.
Remy Maucherat wrote:
<snip>
> I'll be the first to admit, however, that
> FORM (and the other auth methods from the spec) are insufficient and not
> flexible enough, and I am not completely against adding additional
> custom auth-methods.
Can you give some use cases where the spec falls short?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: I have some new FormAuthenticator code for Tomcat.
Posted by Remy Maucherat <re...@apache.org>.
Mark Thomas wrote:
> 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.
I agree with the arguments. I'll be the first to admit, however, that
FORM (and the other auth methods from the spec) are insufficient and not
flexible enough, and I am not completely against adding additional
custom auth-methods.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: I have some new FormAuthenticator code for Tomcat.
Posted by D M <da...@yahoo.com>.
Mark,
Thanks for the reply. Sorry it took me a bit to get back to you on this. Comments inline.
>>OK. I see this as just being a password that is so long that it has
>>to be written down (eg on the USB key) and physically carried around
>>by the user. There is an interesting debate here as to whether this
>>is more or less secure than a 'good' pass-phrase...
That is a valid debate, however, while I was just giving one example
of what might be a possible authentication choice, RSA does recommend
using such a key in combination with a username and password as a
more secure authentication scheme. And with the current configuration
of FormAuthentication, that's not a possible option. (see below for
my reasons for implementing it as I have)
>>Tomcat (and most other web containers) support BASIC, FORM, DIGEST
>>and CLIENT-CERT. Can you give examples (in addition to the 1. above)
>>of authentication types you'd like to see supported?
Well, the one RSA recommends is one I would like to see supported. It
is done through a form, but is not supported by FORM type. However,
I think perhaps another way to look at it is not, what types can I
think of, but, how can we make it more easily extensible (which I
believe the API I created does) for future types that might be
needed (but we haven't thought of just yet).
But in addition to different ways to login, there could also be a case
where there's a need for a user to simultaneously log in to multiple
systems. Perhaps there is data or objects on a secure page that is
pulled from another system that requires slightly different login
information. Rather than forcing the user to login multiple times,
we could make it possible to do it all in one form.
And rather than requiring extra code that must be tied to
every secure resource that checks if the user logged in to that
separate system, we'd like to make it part of the regular
authentication/security mechanism.
>>Hashing is the most popular and archives the desired aims of
>>protecting passwords. Can you give examples of other manipulations?
Sure, Salting is another type of manipulation. Salting basically
means combining a password with a random value as a counter measure
to dictionary password attacks. The combined value can also then be
hashed/encrypted. (There are other examples as well, such as
allowing users to use a domain-neutral username but then to log
them in to multiple domains, appending it to the username)
But again, the main thing here is that we might not be able to think
up all the ways right now, but why not make it extensible so they
can be plugged in at a future time?
>>4. Portability...make your authentication components more web
>>container neutral.
I understand the benefits behind this, but there's a reason I've built
it the way I have (and the developer API is still vendor neutral, more
on that later...). To begin with, in Tomcat and other web servers, the
concept of SingleSignOn allows developers to authenticate users across
web contexts. This code is complex and has already been written for
Tomcat, Jetty, etc. However, if the authentication implementation were
to have no internal code connecting it to the web server's internal
auth scheme (using j_security_check for example), there's no way to use
SingleSignOn without rewriting it yourself.
Doing so has a few repercussions. First, the Servlet/J2EE spec that
handles authentication/authorization becomes unavailable to the web
applications. That means, you cannot use the built-in mechanisms that
use security-constraint and auth-constraint or security-role.
Rewriting code to handle all that not only is unecessary (as it already
exists) and complex, and means you cannot tie in to the specifications.
As well, in JBoss (or any other application server) your login will not
be automatically extended to the EJB realm (or other web contexts). You
would have to write code to handle that as well.
And that becomes a bit of a mess in part because you'd likely have to handle
it using JNDI (which each app server/web server handles differently,
especially in clustered situations). Making it vendor neutral in that
manner is, in my mind, not such a clean solution.
With regard to whether my code is vendor neutral, it is vendor neutral
in the same way Java itself is. I have an implementation of an API
for authentication that has an implementation for Tomcat (just as
Java has a Windows, Linux, etc impl). In this API, developers
have no direct knowledge of any Tomcat classes; it's all been
abstracted.
However, to make this possible in a default installation of Tomcat,
I am suggesting that Tomcat make the FORM implementation pluggable
(instead of being already set inside the jar), perhaps via a command-line
property. That's really the only part of Tomcat that needs to change
to make it more flexible/extensible.
Thanks!
- David
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: I have some new FormAuthenticator code for Tomcat.
Posted by Mark Thomas <ma...@apache.org>.
David,
D M wrote:
>>1. Local files as authentication tokens
OK. I see this as just being a password that is so long that it has to
be written down (eg on the USB key) and physically carried around by the
user. There is an interesting debate here as to whether this is more or
less secure than a 'good' pass-phrase that the user can just carry
around in their head. My instinct is that it is about the same but the
additional complexity required to implement it makes me lean towards
less secure since greater complexity = greater chance to mess things up.
Note: since the 'password' will travel over the wire, this is
fundamentally different (and less secure) than a PKI style private key
on a token which will never be transmitted to the server.
>>2. Plug-in authentication.
Tomcat (and most other web containers) support BASIC, FORM, DIGEST and
CLIENT-CERT. Can you give examples (in addition to the 1. above) of
authentication types you'd like to see supported?
>>3. Authentication token manipulation
Hashing is the most popular and archives the desired aims of protecting
passwords. Can you give examples of other manipulations and the security
benefits of performing them?
>>4. Portability
Have a look at http://jcifs.samba.org/. This provides NTLM
authentication as a servlet filter. It might give you some ideas about
how to make your authentication components more web container neutral.
Also there is a Jakarta project starting up (name TBD) that will provide
web components such as filters, listeners, etc. If your authentication
code can be made container neutral I think this would be a more natural
home for it. Have a look at
http://marc.theaimsgroup.com/?l=jakarta-general&m=111972374202676&w=2,
http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons,
http://marc.theaimsgroup.com/?t=111947286700005&r=1&w=2 and the related
threads.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: I have some new FormAuthenticator code for Tomcat.
Posted by D M <da...@yahoo.com>.
Hi Mark,
Thanks for your comments. My responses inline.
>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.
I think I wasn't being clear here. I didn't mean a certificate file as used in PKI. I was simply giving an example of some other type of data (besides a simple string) that could be used as an authentication key. The example was simply a file of any sort.
>2. JAAS provides plug-in authentication.
Sure it does, but NOT for FORM logins. Tomcat (and all other java web servers I've come across) allow only authenticating with a username and password. This gives flexibility with FORM logins working with Tomcat.
>3. Password hashing is already supported.
While password hashing may be supported, that is only ONE example of a manipulation that might be required on a key for authentication. Everytime a new mechanism arises, making a new implementation in Tomcat can create a bit of a mess, but with this form auth API, you can just plug it in.
>4. The implementation is Tomcat specific and hence is non-portable.
That's true in the short but as I said there was no change of Tomcat's code and the internal implementation of Tomcat is actually hidden from the Plugin classes. So it's actually quite easy to make an implementation of this for a number of web servers (and I'm actually making one for Jetty right now). So you could keep these classes as their own API that plugs in to Tomcat (which is how I made it. The only class Tomcat needs to know about is FormAuthenticator).
David
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: I have some new FormAuthenticator code for Tomcat.
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
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:
>
> ( Authenticators.properties )
> 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 java.io.InputStream), 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 Realm)
> 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 java.io.InputStream. (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
> http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org