tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Realm design
Date Fri, 23 Mar 2001 17:54:46 GMT


On Fri, 23 Mar 2001, David Cittadini wrote:

> I have a few questions about the Realm design:
> 
> a)                   How does a Realm find details of the Login Config for
> the Context currently being authenticated?  When developing a Realm it may
> be very useful to determine the authentication method used.  However, at the
> moment the Realm is just told to authenticate.  The Realm may also be
> attached to the "global" level and therefore have no idea which Context the
> authentication request came from.   Seems to me that it would be useful for
> the Realm to be able to determine the Login Config so that it can adjust any
> authentication processes as required.

It would be feasible to pass the login configuration being used as a
request attribute or something, but I'm struggling to see a use case for
this.  Could you describe how a Realm might want to behave differently?

> b)                   Why aren't CLIENT-CERT authentications passed onto the
> registered Realm?  At the moment, Realms only see to be passed to process
> BASIC authentication requests.  At the moment certificate requests are
> processed by the automatically injected CertificateValve.  Why can't Realms
> process CLIENT-CERT requests?
> 

CertificateValve only exposes the client certificate chain that exists (if
there is one).  It does no authentication.  In order for any Realm to get
called, you have to submit a request to a URL that is protected by an
appropriate security constraint -- and this works for all four kinds of
login configurations.

Currently, For authentication, SSLAuthenticator just checks for a valid
certificate chain.  The Realm will be consulted, though, to check out role
assignments (either for comparing to a security constraint, or because
your app calls HttpServletRequest.isUserInRole()).

> Thanks, David.
> 

Craig McClanahan



Mime
View raw message