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
