tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Bowesman <>
Subject Re: Realm implementations
Date Mon, 07 May 2001 12:59:35 GMT

Thanks for your comments.

"Craig R. McClanahan" wrote:
> On Fri, 4 May 2001, Antony Bowesman wrote:
> > Hi,
> >
> > In TC 3.x authenticate() method of a realm is called for every request.
> > (I gather this is changed in 4.x).
> >
> You are correct.  Tomcat 4 caches the user Principal object returned
> by the authenticate() method in the user's session.  If the
> application calls request.isUserInRole() -- or the container is
> enforcing security constraints -- you may or may not have to go
> back to the underlying security realm to look up the role
> information, depending on how you've implemented things.  All
> the current Realm implementations cache the assigned roles along
> with the user Principal as well.

Will you be adding a cachable JAAS Subject or LoginContext into TC4 at
any stage, this would move it a little closer to JAAS? 

> > I am assuming the RequestImpl is a per HTTP session object.  Is
> > this correct?  So, each different HTTP session will get a
> > different RequestImpl?
> >
> Actually, RequestImpl is per *request*, not per *session*.  In
> Tomcat 4, the caching actually happens in the session implementation
> object (it's in the internal Tomcat part of the API).
> > If so, when HTTP session times out the authentication for that
> > user is lost.  Is it possible to keep the HTTP session alive
> > beyond the configured timeout through some keep alive mechanism?
> > I have a logical session that is container independent and there
> > may have been activity on that session that is not related to
> > the HTTP session and so I want to prevent Tomcat from losing the
> > authenticated context.
> >
> Keeping the session alive (beyond the normal timeout mechanism)
> would require tweaking the way that Tomcat does session expiration.
> If you want to keep something alive beyond the lifetime of a
> session, it sounds like you might need to store the actual objects
> elsewhere (perhaps in a collection stored as a session context 
> attribute), and maintain references to them as session attributes.
> You could use HttpSessionBindingListener events to know when session
> references to the underlying "EJB session" objects are added or 
> subtracted.  This would also let you share an EJB session across
> multiple HTTP sessions, if that was appropriate for your
> requirements.

Actually, our session is an 'overlying' session.  It is not specific to
any container and is available in ORB, EJB, WEB or standalone Java app
so I guess we will set session timeout to -1 and allow our session to
invalidate the HttpSession when it times out.


Antony Bowesman
Teamware Group
tel: +358 9 5128 2562
fax: +358 9 5128 2705

View raw message