On 19/7/09 04:56, Bill Davidson wrote:
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).
A servlet Filter that checks for the presence of the bean, (loads it if
missing by checking the contents of the UserPrincipal), would be less
intrusive and you can just remove it when all Servlets are updated.
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.
Two Filters, if necessary, as they can be applied by selecting different
classes. Hopefully your sub-apps operate on different paths.
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.
There is/was a multi realm, but I think it's intended for use with an
SSL cert & Form auth combination.
Check the source of the latest release:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/realm/CombinedRealm.java
You may be able to exploit this to do what you need.
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.
(Hopefully you've got a dev environment.) Start with a repackaged
version of DataSourceRealm and make minimal changes to encrypt the
password before sending it to the DB for matching.
Modifying the realm a bit shouldn't be too tricky, find the method that
sends the password to the DB to do the auth.
If you've got code for the crypt implementation it may just worth
bunging it into a static utility & encrypting the password manually,
inside the realm - just to get it working initially, so you can prove
that it will work.
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.
Configure container based security.
Get one Realm working for 1 part of the app.
Add a Filter to handle the unmodified servlets.
Add the Combined realm.
p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
