Schawn,We have a similar use case here, except we do not use a part of the DN shown by the certificate but another field (UPN embedded in SubjectAltName). We had to develop a small Java class (X509CertificateCredentialsToUserPrincipalNameResolver) to do the job.
Once the UPN is returned from the certificate, we use the LDAP resolver to find an eventual owner (in our case, the UPN is recorded in a specific AD field). Without this "pairing" between X509 certificate and LDAP entry, the will not be authenticated by X509. It would be the behavior you expect.
As you use Tomcat as web server, you may use 2 connectors types : BIO/NIO or APR, the SSL configuration to achive client authentication is not the same.
Rgds. Le 25/09/2012 13:15, Schawn E. Thropp a écrit :
Marvin,This has definitely been a learning experience for me and I really appreciate the support I have been getting on the forums. Unfortunatly if I understand what you are saying, I am not sure I can use the SSLCACertificateFile approach at this time. The environment I am working in is using Tomcat only. We are not fronted with Apache. So Tomcat is both the server and servlet container in our case. As for my situation, we are working to switch over to the use of DoD Issued CAC cards for authentication purposes. So all of the CAC card certificates have the same CA (to my understanding). But we don't want everyone who has a CAC card to have access to our site, portal and applications, only certain ones. We will provide the ability to login via typical username/password but give them an option to use CAC card to login in also. So I have been working on using the CAS and X509 example provided to get basic X509 certificate authentication working. I have the example set up and seems to be accepting my X509 certificate and allowing me to login, but that is just with the basic X509 authentication, I still need to validate that the user is allowed into the site, via a LDAP lookup. The EDIPI number is a unique number added to the end of the CN. CN=firstname.lastname.<edipi number>. The plan was to have these EDIPI numbers in our LDAP for every valid user of the site. Then during X509 authentication, strip the EDIPI number off of the certificate and do a lookup prior to allowing them into site. That is the basic workflow. Hopefully this helps explain my requirements. Any help or if you could point me in the right direction to get me further along and into the LDAP lookup of the EDIPI number would be fantastic. Or if you have some alternative suggestions for providing a solution, that would be awesome also.Thanks Schawn *From:* Marvin Addison <[email protected]> *To:* [email protected] *Sent:* Monday, September 24, 2012 2:19 PM *Subject:* Re: [cas-user] Using LDAP and X509 for authentication/authorization > We are in the process of supporting X509 certificates for authentication of > users. It is one thing to accept / authorize via the X509 certificate, but > of course we need to go a step further and validate whether or not the owner > of the certificate is allowed access via an LDAP look up. I'm familiar with a similar use case, but I think it's a workaround for shortcomings in standards (CRL, OCSP) and poor reference implementations. I do think both standards are workable, however, and the CRL checking implementation in CAS is production ready. I'm not sure how far you are into the PKI implementation underneath this project, but if you can issue all certs from a single trusted user CA, then you can do all the authorization checks on the server-side HTTP endpoint (e.g. SSLCACertificateFile and friends). > We are thinking > about using the EDIPI number on the end of a Common Name (e.g., CN = > firstname.lastname.<edipi number>. The smart cards that will be used > appends this unique number (EDIPI) on the end of the CN. I would expect this attribute to be in some field in the certificate, either a custom extension OID or as a distinct attribute in the subject DN. If yes, then I can recommend an implementation that avoids parsing the string representation of the subject DN, which can get tricky in edge cases. Best to avoid if possible. In either case it may be necessary to develop you own CredentialsToPrincipalResolver, but those components are fairly simple. M --You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user-- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
-- Philippe MARASSE Service Informatique - Centre Hospitalier Henri Laborit BP 587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19
smime.p7s
Description: Signature cryptographique S/MIME
