Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Security / December 2003

Tip: Looking for answers? Try searching our database.

implementing a tomcat security server?

Thread view: 
Roger - 22 Dec 2003 09:05 GMT
I have a tomcat webapp that is comprised of a lot of one-shot,
context-free servlets. The only context they need is the security (ie
jsessionid) which is static for the session, of course. I use the
DatasourceRealm at the moment.

Because of the lack of real context I would like the security system
to validate against an external server. This would allow me to restart
tomcat between requests and the clients would recover okay. But I
think all of the realms only check the username and password at login.
The jsessionid is held in tomcat memory and is lost on a tomcat
restart. I think this includes any custom realm I might write.

Am I right about this? Is there a realm (or something else) that
allows me to do something more interesting with the jsessionid? I
don't mind writing it myself. I am envisaging replacing the jsessionid
lookup with an RMI call to my external security server process. Login
validation would go there as well.

Are the hooks available to implement something like this?

I keep finding things about session replication, which must be doing
something like this to work, but I do not need session replication as
such, I have no session to replicate.

All suggestions gratefully received.
Roger
nobody - 22 Dec 2003 11:38 GMT
> I have a tomcat webapp that is comprised of a lot of one-shot,
> context-free servlets. The only context they need is the security (ie
[quoted text clipped - 22 lines]
> All suggestions gratefully received.
> Roger

There's not necessarily a correlation between a user's authentication
and their session; i.e. you can have a session without authentication,
and authentication without sessions.

Typically in form-based authentication, the username is stored in the
session.  Some containers serialize the session during shutdown/restart,
which would make the session available to clients after a server cycle.
 Likewise, in HTTP basic authentication, the client sends credentials
with every request (so a server cycle would be transparent to the client
with respect to authentication, since each request carries the
authentication credentials).

As far as Tomcat is concerned see:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/manager.html

This gives instructions on enabling persistent sessions.
Roger - 22 Dec 2003 19:28 GMT
Thanks, that helps a lot. I have been ignoring the 'manager' docs
thinking they were not relevant. I notice that the .ser files are used
to handle restarts. This might actually do enough of what I need for
now, if I just flag my manager to be distributable I ought to get most
of what I want.

Longer term I think I have to implement my own manager and make it
'semi' persistent. The persistent manager doesn't work quite how I
want. It is, of course, designed to store session data and it must
write to the persistence store every time a request is completed. In
my case I just want to remember that this user logged on and got some
privs assigned. All of this is static for the duration of the session,
so I don't need to write it all the time.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.