This has been on my list for awhile (just not very high :). I am leaning in the direction of 1): change the clientAuth parameter to be a String of the form: 'true', 'false', or 'want'. It's the simplest, and cleanest.
Getting the PureTLS implementation caught up with the JSSE implementation is another item on my list :). ----- Original Message ----- From: "Becker, Michael" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 22, 2004 10:38 AM Subject: JSSE 1.4: 'Want' vs. 'Need' Client Certificate Authentication One of the additional features that has been introduced in JSSE 1.4 is the ability to 'want' client certificates instead of 'require'ing them (http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.ht ml#NewMethods). It also appears that this functionality is not available in the PureTLS implementation of the SSL protocol (at least that I could find). This feature could be useful in scenarios where some users have client side certificates and some do not. This would still allow both sets of users to connect to the same host, but using different modes of authentication. Another nice thing that this feature would give us is the ability to provide a friendly "You don't have a client certificate and contact this help desk to get your client certificate" instead of not allowing any requests to get into the container. Considering the fact that this is only applicable to a JDK 1.4.x VM, is this something that could be built into the current distribution? Here are some options that I came up with to get this functionality in Tomcat. 1. Provide an additional argument to the org.apache.coyote.tomcat4.CoyoteServerSocketFactory in server.xml to 'want' certificate authentication. If the underlying SSL implementation does not support that feature, log an error/warning and revert to 'need' certificate authentication. 2. For the org.apache.tomcat.util.net.jsse.JSSE14* classes, change the functionality to 'want' certificates instead of 'need' them. This gives the application and container the ability to give the user an error if they do not have a certificate instead of closing the socket and making the browser show the 'Page can not be displayed' error. This would change existing behavior and thus could be a really bad thing to do. 3. Make my own modifications and don't incorporate into the default distribution. Regards, Mike Becker --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
