tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From D M <>
Subject Re: I have some new FormAuthenticator code for Tomcat.
Date Wed, 29 Jun 2005 19:58:29 GMT


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 

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.


- David

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message