Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <00f601c4c5ce$3777cef0$cb37a8c0@bbarkerxp>
From: "Bill Barker" <wbarker@wilshire.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
References: <D38B506E54797D4CAD2E73EF8089AF88024A921A@mayhem.msj.com>
Subject: Re: org.apache.catalina.authenticator.SSLAutheticator
Date: Mon, 8 Nov 2004 12:04:55 -0800
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_1099944276-15326-202"

------------=_1099944276-15326-202
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


----- Original Message -----
From: "Ken Sims" <KSims@msjcorp.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Monday, November 08, 2004 8:25 AM
Subject: org.apache.catalina.authenticator.SSLAutheticator


>I am curious why SSLAuthenticator does not/cannot compare some attribute
>of the client cert with the remote address (requestor)?  Without such a
>check, it seems to me that certificates are as easily shared as the
>credentials used in basic authentication.
>
There are plenty of tutorials on CLIENT-CERT auth out there.  I suggest that
you read one :).

>Also, why do the realm implementations always return null for
>getPrincipal?  Couldn't they lookup the user on the  users database,
>ignoring password, to establish authorized roles?
>
Usually when you seriously want CLIENT-CERT, you find that you need a custom
Realm anyway.  There isn't really a one-size-fits-all solution.  Where it is
implemented in TC (MemoryRealm, and UDBRealm in 5.5.x), it authenticates
against the Subject.  In a lot of cases, you really only want the CN, or the
CN+EMAIL fields.  In other cases (e.g. JNDI, JAAS) you might want the entire
cert.  You can look through BZ for TC 4 to find several examples of proposed
implementations.

That said, patches are always welcome :).


>The combination of these two things seems to me to really limit the
>usefulness of client certificate authentication because authentication
>provides little guarantee of who the client is, and even if it did, the
>client is denied access to any protected resources.
>


This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.


------------=_1099944276-15326-202
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
------------=_1099944276-15326-202--