tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
Date Fri, 20 Sep 2002 20:40:37 GMT

----- Original Message -----
From: "Qingqing Ouyang" <>
To: "Tomcat Developers List" <>
Sent: Friday, September 20, 2002 11:53 AM
Subject: Re: cvs commit:

> Hi, Bill:
> Thanx for the comments.  Please see the following.
> >>Can someone start the Tomcat server with clientAuth=false, but access
> >>a URI that is protected by CLIENT-CERT?  If yes, then I think a
> >>re-handshake is a must.
> >
> >
> > But using CertificatesValve to accomplish this is the wrong way to do
> > Catalina has no good reason to know or care what transport the request
> > received on.  It's the connector's job to take care of that.
> >
> > It looks like we may need another Action to handle this case (probably
> > invoked by the Realm).  Comments?
> Okay, that is where my ignorance kicks in. ;-)
> I agree that Catalina does not have to know/care about what
> transport the request is received on.  The logical place for
> this to happen is somewhere:
> 1. Tomcat has enough information to determine the incoming
>     request is intended for a Context that requires the
>     client-cert authentication

True.  However it is unnecessary to do it for the entire Context.  It is
only necessary for the pages that require authentication.

> 2. Tomcat also has to have the handle on the specific
>     transport mechanism to force this second handshake with
>     the client.

"Tomcat" does, but Catalina doesn't.  All Catalina cares about is getting a
client-cert, it shouldn't care how it gets it.  What it should do is ask
Coyote to get the cert for it, since it's the only one that knows if it is
talking to a JSSE socket, a PureTLS socket, or even talking directly to
Apache via JNI.  The notification hook mechanism is already in Coyote.  It
would just be adding one more hook.

> 3. The certificate information also has to be populated with
>     the Request object for further authorization calls...
> Does that sound right?
> Thanx,
> Q^2
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message