On Mon, 26 Mar 2001, Roytman, Alex wrote:
> Hello,
>
> I wrote JNDI(LDAP) realm for tomcat 3.x based similar to JDBCRealm provided
> with tomcat
Would you be interested in contributing this code to the Tomcat 3 (and/or
4) code bases?
> My client is going to adopt RSA ACE security infrastructure which to my
> understanding will require users to append a hardware generated number to
> their passwords when they authenticate. So we will have system where
> password changes every 15 seconds and it can not be cached in tomcat and
> used for subsequent accesses to LDAP (unless your software is RSA ACE aware
> and can deal with it somehow)
> (- I am not really familiar with RSA ACE security so I might be missing
> something here -)
>
> If I understand correctly, tomcat 3.x has following security architecture:
> 1. Extract user/password from user Session for Form based authentication
> (from headers for Basic authentication)
> 2. For *every request* perform authentication and authorization
>
> This might be a problem if password on backend changes constantly. Cached
> password will expire in lets say 15 second and that will break tomcat's
> security
>
> One solution to the problem would be to cache all
> authentication/authorization info in user session (you already caching
> username and password for form based authentication there) and use it as a
> poof of successful authentication for all subsequent request.
>
> Do you see any problems with this approach?
>
> Does tomcat4 security architecture handles this better?
>
In Tomcat 4.0, if you are running under a session (which is automatic if
you use form-based login), the user principal object retrieved from the
Realm is cached in the Session the first time that it is authenticated, so
the Realm is consulted only once. This sounds to me like it operates in
exactly the way you are proposing.
In 3.x, it should be conceptually feasible to do the same thing -- I don't
know that code base well enough (at the moment) to know whether this would
require modification to the session implementation object or not.
Craig
