Container based authentication and session persistence with Tomca t 4.1.29

[Andreas Mohrig <an...@cadooz.de>]

Hello,

[ What I'm trying to do ]
I'm trying to use container based authentication while having session
persistence provided by a PersistentManager (with FileStore) with Tomcat
4.1.29 (running under Windows XP for development purposes). 

[ What works ]
Form-based authentication via a DataSourceRealm works fine. 
Persistence works fine as long as harmless objects such as strings are
concerned: they appear happily in session-scope after a restart of tomcat.

[ What does not work ]
The user that has been logged in however is forced to log in again, this
information seems to get lost during a restart.

[ What I already tried ]
Research in the web and in the archives did not give me a hint about what is
going wrong.
I looked up the documentation for org.apache.catalina.realm.GenericPrincipal
(which stores the user information) and noticed that it is not serializable,
i.e. it does not implement the java.io.Serializable interface. But being
serializable is a prerequisite for beeing written to a FileStore (or any
other store most probably).
An attempt to patch this class to make it implement this interface has not
been successfull because the GenericPrincipal objects hold references to the
Realm, which is not serializable either (and for some good reasons, it
seems). 

Am I just missing something or is this really a problem? Has anyone
accomplished to have persistent sessions with this (or any other) setup and
can give me a hint?

I'm reluctant to use application based authentication both because of the
work this would cause and because of the security issues involved. Any
feedback would be greatly appreciated.


Greetings,

Andreas Mohrig

Re: Container based authentication and session persistence with Tomca t 4.1.29

[Christopher Schultz <ch...@comcast.net>]

Andreas,
> I looked up the documentation for org.apache.catalina.realm.GenericPrincipal
> (which stores the user information) and noticed that it is not serializable,
> i.e. it does not implement the java.io.Serializable interface. But being
> serializable is a prerequisite for beeing written to a FileStore (or any
> other store most probably).

Also note that the GenericPrincipal nbever actually goes into the 
session. After login, snoop the session -- there's nothing in there. I 
believe that Tomcat keeps a table of session ids -> Principal objects, 
instead of putting that information into the session. (Can someone 
confirm... I don't want to spread falsehoods).

> An attempt to patch this class to make it implement this interface has not
> been successfull because the GenericPrincipal objects hold references to the
> Realm, which is not serializable either (and for some good reasons, it
> seems). 

I believe this is the wrong approach.

> Am I just missing something or is this really a problem? Has anyone
> accomplished to have persistent sessions with this (or any other) setup and
> can give me a hint?
> 
> I'm reluctant to use application based authentication both because of the
> work this would cause and because of the security issues involved. Any
> feedback would be greatly appreciated.

I have recently struggled with container-based AAA, and found the 
following approach works well for my requirements:

Create a Filter that checks to see if there is a Principal available in 
the request, yet no token in the session to indicate a valid login. In 
this state, I assume that the user has just successfully submitted the 
login page. In that case, I perform my "post login" required actions. 
That is, getting information from my database and putting it into the 
session.

(Note that a Filter instance gets instances of ServletRequest and 
ServletRespose, so you'll have to check for instanceof 
HttpServletRequest and cast the reference appropriately. I don't like 
this too much, but it seems like omy only choice in this situation).

In your case, you could couple this technique with two others:

1. Create an HttpSessionListener that will be notified when the user's 
session expires (or really when the session is destroyed; this may be 
due to an explicit logout). When a session is destroyed, you can 
serialize all the session objects to some database (flat file, RDBMS, 
etc.). Remember to make the data store aware of the user's identity.

2. Use my technique described above to "intercept" logins. When you are 
in the "just logged-on" state, take the opportunity to locate that 
user's session datastore and re-load the data back into the session.

One last thing: why do you want to save the user's session contents 
between logins? Why not make everything in the session transient? Or, do 
you have a lengthy process where users might be logged-out of your 
system with lots of valuable information in their sessions that is 
otherwise unrecoverable?

-chris


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org