You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2005/05/09 23:49:04 UTC
DO NOT REPLY [Bug 34643] -
document how to use certificate-based "clientAuth" on a per user or per session basis also with self-signed/expired client certs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34643>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34643
hauser@acm.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|document how to use |document how to use
|certificate-based |certificate-based
|"clientAuth" on a per user |"clientAuth" on a per user
|or per session basis |or per session basis also
| |with self-signed/expired
| |client certs
------- Additional Comments From hauser@acm.org 2005-05-09 23:49 -------
it appears that if the client certificate shall not be asked from all users and
not upon the first contact with the given connector, the "clientAuth" attribute
isn't it, irrespective of whether set to "true" or "want".
The approach appears to be rather to direct the user to a protected jsp/struts
action at the point in time you want the client cert auth to happen with
<security-constraint>
<web-resource-collection>
<web-resource-name>Client Certificate Auth</web-resource-name>
<url-pattern>/certBasedAuth.do</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
Being flexible with respect to the used certificate remains tricky:
1) if already knowing the certificate to be expected e.g. by virtue of it being
in a LDAP truststore, it appears to be impossible to allow for mismatches of the
certs[0].getSubjectDN().getName() without replacing the current
org.apache.catalina.authenticator.SSLAuthenticator
- one might for example rather use the SHA1 fingerprint to match?
2) similarly, if you want to be more tolerant on certificate
expiration/not-yet-valid, I haven't figured how to get the "validate=false" for
org.apache.catalina.realm.RealmBase.authenticate(X509Certificate[] certs) from a
config file without altering sources.
3) As for self-signed certificates, I see two approaches
a) be able to create a mini-trust-store on the fly before the ssl-handshake
occurs in org.apache.tomcat.util.net.jsse.JSSESupport.handShake() - I have no
clue how late in an SSLSocket's life its truststore can be altered? A nice
example how this can be done a per thread basis (albeit before creating the
socket and not when it's already in operation) is Oleg's
org.apache.commons.httpclient.contrib.ssl.AuthSSLProtocolSocketFactory (see Bug
34391) - I guess this implies that the web-app programmer in some way (by means
of an enhanced LoginConfig or an extra parameter of the method or a session
attribute?) might tell
org.apache.catalina.authenticator.SSLAuthenticator.authenticate() the
self-signed cert it should expect when that method starts
b) alternatively, a less rigid TrustManager might be used in
org.apache.tomcat.util.net.jsse.JSSE15SocketFactory.getTrustManagers(String
keystoreType, String algorithm) - some ideas are in
http://forum.java.sun.com/thread.jspa?forumID=2&threadID=411937
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org