All, I've been using securityfilter for a number of years. With the introduction of Servlet 3.0, the major reason for sf's existence has finally been made available to devs within a servlet container: drive-by logins.
As I'm finally running on Tomcat 7 ;) I've been considering switching from using sf to using Tomcat's Realms (specifically DataSourceRealm, but that's not terribly important for this discussion). There are a few things that are stopping me from doing this: 1. Realms have only simple "authenticate" methods that contain as little information as possible. For instance, FORM logins have only username and password -- no other context is provided such as the user's IP address. I need to record the IP addresses of attempted logins in my database, and I can't get information about a failed login -- only a successful one (because I can detect a successful login based upon a session with a Principal that doesn't have a certain token, but I can't tell when a session doesn't have a Principal and should have one). 2. Tomcat Realms only support simple MessageDigest-based hashing. I need something more elaborate that can't just be set via the "digest" attribute of the Realm, because you can't just call MessageDigest.getInstance(digestName). The second issue is somewhat easier to solve: we can add some protected methods to RealmBase and have them default to things like using MessageDigest. I was thinking specifically of adding this method: protected boolean passwordMatches(String userSupplied, String stored); This would allow any Realm to be subclassed and have the above method overridden: the user can do whatever they'd like in order to support some wild password hashing scheme. For instance, I support a few flavors of hashing in my webapp: I can use a vanilla SHA hash for users with very old passwords, or I can use an iterated hash for newer passwords. I suspect I will be moving to either PBKDF2, bcrypt, etc. and will still need to accept older passwords, so my "passwordMatches" method can become quite complicated. Are there any objections to adding such a method? Another option would be to create an interface around that method and allow any realm to have a "credential checker" do the checking for it. That would allow anyone to plug-in another class and use it directly with any Tomcat Realm instead of having to choose a realm (e.g. DataSourceRealm) and subclass it to override a method in RealmBase. While the interface/plug-in idea is more flexible and possibly easier for most users, it does represent a bigger change to Tomcat. What do folks think about either of the above proposals? On the other hand, the first issue above is somewhat harder to solve because there is a lot of information that might be considered "useful" during a login. What we have in securityfilter is a "FlexibleRealmInterface" that the realm can implement and an alternative method gets called: authenticate(HttpServletRequest). This allows the realm to get whatever information it wants from the request. IIRC, some 3rd-party authenticators do this kind of thing (Spring?)... are they plugged-in using Tomcat's Realms or are they completely separate beasts like securityfilter? Thanks, -chris
signature.asc
Description: OpenPGP digital signature
