https://issues.apache.org/bugzilla/show_bug.cgi?id=52500
--- Comment #3 from Michael <michael_fur...@hotmail.com> 2012-01-23 13:22:16
UTC ---
Hi!
I want to improve current implementation of the client certificate
authentication (SSLAuthenticator)
Current implementation of SSLAuthenticator takes the user identifier from the
whole SubjectDN.
During my work with our enterprise customers I have found the following:
1) It is common case when the user identifier is stored in the Subject
Alternative Name of the client certificate.
2) When the user identifier is stored in the SubjectDN of the client
certificate it can be stored in e-mail, CN or in the hold SubjectDN
See the attached x509Examples.docx
I recommend to improve the Tomcat client certificate authentication and allow
to take user identifier from the Subject Alternative Name or from SubjectDN.
The attached code allows to do it using the following configuration:
<Context>
<Valve className="org.apache.catalina.authenticator.SSLAuthenticator"
userIdentifierRetrieveField="SubjectAlternativeName"
userIdentifierRetrieveFieldPart="otherName" />
</Context>
<Context>
<Valve className="org.apache.catalina.authenticator.SSLAuthenticator"
userIdentifierRetrieveField="SubjectDN" userIdentifierRetrieveFieldPart="e" />
</Context>
The attached code already works more than year at production in more than one
customer.
Open issues:
1) The implementation of SubjectAlternativeNameRetriever depend on bouncy
castel jar. If it is a problem possible to get all required source files into
Tomcat source files. Alternatively, it is possible not to support Subject
Alternative Name – but it is very common use case
2) I am not sure if the configuration above is the best option – possible to
discuss it
I will happy for your comments.
Best regards,
Michael
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
