Thank you for your thoughts. I have done a lot of reading on the topic
of CLIENT-CERT/SSL and Tomcat from Google searches as well as the source
code of SSLAuthenticator. However I see nothing to indicate how a
server would know you from me if I gave you my keystore and keystore
password. The server would authenticate you as me. Many tests on my
part indicate that is so. Funny that the client does this against the
server's cert by default.
I modified a version of SSLAuthenticator to do hostname verification
with success, but it seemed to me like something that is either a real
omission in Tomcat (perhaps on the basis of adherence to a standards
spec.?) or some conceptual misunderstanding on my part. In deference to
the thought that I was missing something, I was hoping to hear what I
might look at specifically to revert to stock code for SSLAuthenticator.
-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]
Sent: Monday, November 08, 2004 12:05 PM
To: Tomcat Developers List
Subject: Re: org.apache.catalina.authenticator.SSLAutheticator
- Original Message -
From: Ken Sims [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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
CN+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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
