tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34643] New: - document how to use certificate-based "clientAuth" on a per user or per session basis
Date Wed, 27 Apr 2005 11:12:35 GMT
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

           Summary: document how to use certificate-based "clientAuth" on a
                    per user or per session basis
           Product: Tomcat 5
           Version: Nightly Build
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Connector:Coyote
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: hauser@acm.org
                CC: mario@ops.co.at,william.barker@wilshire.com


http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration%20File
nicely documents how to enable "clientAuth" on a global basis.
A web application may well have a mixed user community, some authenticate by
means of a password or other authenticators, others have a certificate for
authentication.

The goal of this RFE is to amend the documentation with how the clientAuth
mechanism can be triggered and enforced on a per user basis.

Interim results of my own little research:
- if I request org.apache.catalina.Globals.SSL_CERTIFICATE_ATTR,
org.apache.coyote.tomcat4.CoyoteRequest.getAttribute triggers the
org.apache.coyote.ActionCode.ACTION_REQ_SSL_CERTIFICATE re-handshake
- to enforce this for a given user, I guess I could store that certificate in
the session and for every subsequent request test whether the cert is stored or
otherwise trigger the re-handshake by asking for SSL_CERTIFICATE_ATTR.

Open issues I haven't mastered so far:
1) If the application allows for self-signed certificates the user uploads into
the DB i.e. her profile, is there a way to use a non-global trustStore to
validate? Otherwise, with an increasing user-basis, I foresee scalability
problems if I had to import all such certificates into a global trust store?
2) javax.net.ssl.SSLServerSocket.setNeedClientAuth in
org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.configureClientAuth might be
the basis for an alternative approach, but I wouldn't know how to set that (or
probably rather
org.apache.tomcat.util.net.ServerSocketFactory.setAttribute("clientAuth", true)
before the org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket has
already occurred?

related mailing list threads probably are:
http://marc.theaimsgroup.com/?l=tomcat-user&m=105300671215744&w=2 and
http://marc.theaimsgroup.com/?l=tomcat-user&m=104581231518394&w=2

-- 
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


Mime
View raw message