Tim,
I'm not sure this ever got answered (I had lots of email problems this month),
so just in case it didn't ...
[EMAIL PROTECTED] wrote:
> I'm putting together a LDAPRealm implementation for catalina and have the
> basic setup working. I would welcome some advice on implementation issues.
>
> I would prefer to avoid a round trip to the LDAP server (presumably the same
> could apply for a JDBCRealm or whatever) for each page requested. Hence I
> could store the principal created in a hashmap as is done for the
> MemoryRealm (my usaage is for a small Intranet based usage, so keeping the
> whole user base in memory is not a problem) and verify the password against
> this stored principal rather than doing another (possibly expensive) round
> trip to the LDAP server.
>
Catalina's standard policy for Authenticators is to cache the returned Principal
object in the user's session, if there is one. Thus, there will normally be
only one call to Realm.authenticate() per session, because the Authenticator
checks for a cached Principal first. As soon as the session expires, this
instance is thrown away.
>
> However when doing this the principal stays alive for the entire lifetime of
> tomcat. What I would like is that it only stays alive for that session, so
> that when the browser is quit and restarted a new round trip to the LDAP
> server is needed. My concern here is that if the LDAP administrator removed
> or invalidated a user, this should be picked up by tomcat pretty quickly.
Currently, no changes to the information in the LDAP server (including the fact
that a user was removed) will get recognized until the user tries to log on
again (i.e. by creating a new session). Then, the changes will be immediately
picked up because another call to Realm.authenticate() will have happened.
>
> Clearly if LDAP is being hit for every page it would be picked up
> immediately. If however the pricipal was being stored permananently the
> invalid user would still be able to be authenticated until tomcat is
> restarted. A sensible compromise would seem to be to give the principal
> session scope so that once the browser is quit (assuming we're using cookies
> here for session maintenance) and a new session started, the LDAP server has
> to be consulted again.
>
> The implementation issues would seem to be, can the Realm get access to the
> seesion, and is the realm the right place for this in the first place?
>
I think that the Authenticators all do exactly what you are asking for already
-- in effect the Principal object returned by the Realm is cached with session
scope, and then thrown away.
>
> Comments or suggestions welcome.
>
> many thanks
>
> tim
>
>
Craig
