I think that you are very nearly there, but this is (to quote Sherlock Holmes) a three pipe problem.

As far as I can see, Tomcat does not directly permit you to use JAAS authentication. In fact, if it's running separately, it probably shouldn't.

You could set up Tomcat security using a JDBC Realm that accesses the same database, tables and columns as a JAAS databaseServerLoginModule in the EJB tier. This will at least save your administrators some time and effort.

But, if your EJB tier is to be secure, you will still have to supply credentials with EVERY EJB call.

The simplest way to do this is to store a Context object that contains credentials in addition to the other EJB lookup information. I use a "JSP Helper" bean that has session scope, stores the context, and supplies the context to other beans when required. The performance overhead should be very low - only a reference is passed.

The next problem is that, if you attempt to use security at Tomcat level, you can get the principal using session.getRemoteUser() but not the password. Quite right too. Think what the hackers might do.

So you can't use Tomcat security and then reuse the credentials for JAAS security on the EJB tier.

The only solution to this is to bypass Tomcat security, and to use a specialised login page which builds the EJB context and then tests EJB security by trying to make a method call on the EJB tier. If this is effectively a null operation (return true), the only reason for failure will be a security failure.

If you get a security failure, you should probably invalidate the session right away. But that's not terribly friendly - as you should let the user know what has happened. My next, unfinished step is to find the fragments of Javascript needed to display a login failure page for 5 seconds and then to invalidate the session.

I would agree that SRPLoginModule sounds like pain without reward.

Hope this helps,

James Strachan