Tomcat 6.0.18 Java 1.6.0_14 RedHat 5.2 Server Oracle 10g I've got an old web app that was originally spec'd in 1999. Last year, I got it migrated from Tomcat 3.2.4 for 6.0.16 and more recently from Java 1.4.2 to 1.6. I'm gradually trying to modernize it. I just converted from using an old database connection pool library from that period to using a DataSource managed by Tomcat/DBCP (which was surprisingly easy). Now I want to tackle container based security.
The app currently manages its own security. It's all servlets which do a little session magic on their own. The login servlet hits the database where the user names and password are. I want to start using JSP and/or maybe JSF, which is part of the reason I want to go to container based security. I'm thinking that the login.jsp can be set up with a bean to massage the session so that old servlets will still be satisfied that the session is legit. Newer servlets can dispense with that security and older ones can have it taken out gradually over time (over 200 of them). While it's actually just one web app, conceptually, it's two. There's one side which is an administrative side, and another for the general public. Some servlets are used by one side, other servlets are used by the other. They all use the same database, and share a lot of the same objects and data, however the user names and passwords are in different database tables. Also, the public side can be used anonymously (no need to log in). Login mainly gives the public side the ability to store preferences so that it doesn't need to be re-entered and keep track of history. I've been going over the realm documentation, and it's a little confusing. I think that I'm actually going to need two realms, one for each side (remember that they use different tables). I'm not exactly sure how to set that up. I'd like to use a DataSourceRealm, using the DataSource I've already set up, however I've also got the problem that the programmers who set this up stored the passwords UNIX/Linux style with a Java implementation of crypt(3), which doesn't seem to be one of the options for MessageDigest. I hope I'm wrong about that. Given how common it is in the UNIX/Linux world, I'd think that would be a good one to have (and please don't tell me that it's not that secure -- that's not the point -- this is a compatibility issue). Does this mean I'm going to need to write my own custom realm? That looks fairly confusing too. Can someone please point me at a good overall strategy for how to tackle all of this, given these constraints? I've only spent a few hours trying to go through the docs but I'm feeling a bit overwhelmed and really need some perspective.