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.
In general, up to 3.3 most of the focus in 3.x was in optimizing and
simplifying the core and giving flexibility and power to modules. Most
individual modules are not optimized yet.
The good news is that new modules can be added to 3.3 quite easily - and
without worry about the ( extremely long so far ) release
cycle.
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). 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
