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 13:06:14 GMT
Hi Costin,

Thanks for your comments. wrote:
> Hi Antony,
> > In TC 3.x authenticate() method of a realm is called for every
> > request.
> Well, yes and no.
> The BaseInterceptor.authenticate() callback is called on every request
> ( as it is on Apache and other servers ).
> The authenticate method of the realm ( that goes to a database or
> does expensive operations ) should be called once - and the result
> cached by the module ( either in session, or in a local cache ).
> We don't do this for the simple realm - but we should.

When you talk about caching it in the session I would understand that I
need to call req.getSession(true) to ensure a session is available. 
With form authentication the session is present as the j_* fields are in
it but for BASIC there is no session so I will have to create one.  I'd
rather not cache in the realm as I then have to start worrying about
cleaning out old authentications when the HttpSessio expires.

> A particular case is the authentication module - I expect tomcat
> to be "integrated" in different systems, and I doubly the "simple
> realm" will be used for anything but development. So there is no
> point in optimizing it,


> I would rather spend time on specialized modules that can be
> used in production environment ( and JAAS is probably the most
> important one, since it could be integrated with PAM and give
> access to most auth schemes).

Yes, it seems Tomcat has to move towards directly supporting JAAS as
that is the way J2EE 1.3 and JDK1.4 are moving.

> Another big priority is a module
> that delegates the auth to apache - but we have to wait for
> ajp14 for that.
> > I am implementing a JAAS Realm which authenticates against a back end
> > EJB user realm.  I want to avoid this authentication for every request
> > so I have done the following in authenticate()
> I would cache it inside the session ( if any ) - that's the most
> common case ( most people use sessions and authentication ).
> If you want to deal with the 10% special cases you could maintain
> a local cache to avoid calling the JAAS for each request.
> > In 3.2.2b4 it is changed (same as 3.3) and now returns null if there is
> > no principal.  So, it is sufficient to do this in authenticate()?
> I think that's the correct behavior.
> > I am assuming the RequestImpl is a per HTTP session object.  Is this
> > correct?  So, each different HTTP session will get a different
> > RequestImpl?
> No, that's almost impossible. The session is detected long after the
> request is received ( and you could have cases where you have
> multiple requests on the same time in the same session - think about a
> page with images ). You need to use req.getSession(false).
> (and keep in mind that authentication doesn't require session, even if
> most of the time they are used togheter !)
> > 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.
> I don't know if it would be a good idea. If you really want to keep the
> security context longer you should use your own cache, and let the session
> work as it is supposed to.
> ( and it shouldn't be very difficult ).
> Please let us know how this project evolves - I'm very interested in JAAS
> authentication for tomcat, as an add-on module.
> Costin

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

View raw message