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.
> 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()
>
> authenticate()
> {
> ...
> JAASRealmPrincipal principal = new
> JAASRealmPrincipal(principalName, lc.getSubject());
> // Set principal into Tomcat
> req.setUserPrincipal(principal);
> ...
> }
>
> so, now if I call getUserPrincipal() I get my JAAS realm that now sits
> inside tomcat's RequestImpl.
>
> In 3.2.2b1 the req.getUserPrincipal() method created a SimplePrincipal
> if the principal was null so it never returned null.
>
> 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()?
>
> --------------------
> if (req.setUserPrincipal(principal) == null)
> {
> // User not authenticated... do authentication
> ...
> JAASRealmPrincipal principal = new
> JAASRealmPrincipal(principalName, lc.getSubject());
> // Set principal into Tomcat
> req.setUserPrincipal(principal);
> ...
> }
> else
> // User already authenticated...
> return true;
> --------------------
>
> 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.
> How does this fit into TC4?
>
Pretty much the same, although the caching of user principals is already
done for you in the Authenticator implementations.
> Best regards
> Antony
>
Craig McClanahan
