spring-security : Using user's certificate to authenticate against LDAP - ldap

Question

I managed to authentify the user against the Ldap using the username found in the certificate. What I would like to obtain is to authentify the user using directly the certificate on the Ldap.
I cannot found how to pass the certificate to the Ldap.
here is the current config (using the certificate's username) :
<security:x509 subject-principal-regex="CN=(.*?)," user-service-ref="userService"/>
<bean name="userService" class="org.springframework.security.ldap.userdetails.LdapUserDetailsService">
<constructor-arg ref="ldapUserSearch"/>
<constructor-arg ref="ldapAuthoritiesPopulator"/>
</bean>
<bean name="ldapUserSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
<constructor-arg value=""/>
<constructor-arg value="sAMAccountName={0}"/>
<constructor-arg ref="contextSource" />
</bean>
<bean name="ldapAuthoritiesPopulator" class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
<constructor-arg ref="contextSource" />
<constructor-arg value="" />
<property name="groupSearchFilter" value="member={0}" />
<property name="searchSubtree" value="true" />
</bean>

Answer 1

I was looking in to this issue myself. I have yet to find an authentication stack that does X509->account resolution "right". I got hung up on the fact that Spring Security's UserDetailsService interface insists on a string uid for lookup, but in many cases it is impossible to derive such a UID from the information contained in an X509 certificate's subject (e.g. there are many cn=John Smith in the world, or even within a single organization, nor is email required in a certificate DN). The uniqueness of a certificate lies in the Issuer + Serial Number combination, not the Subject.
After looking through the API there are a couple ways to go about this. Either way probably precludes using the namespace and setting up the filter chain and beans yourself:
1) Implement your own AuthenticationUserDetailsService and bind this to the PreAuthenticatedAuthenticationProvider. By default, I believe, the namespace sets up a UserDetailsByNameServiceWrapper using the passed-in user-service-ref. Going this route means you have to do everything to set up the UserDetails, including granted authorities resolution. Of course you can delegate all this, but its more work.
2) If your LDAP store is keyed by some UID, and this is the route I am leaning towards, implement your own X509PrincipalExtractor and bind it to the X509AuthenticationFilter and return the string uid that your LDAPUserDetailsService is configured to expect. Within the extractor implement the logic to search your LDAP store for the stored certificate. I do not know of any strategies that will work across LDAP servers, the easiest way would be if your LDAP supports RFC4523 certificateMatch or certificateExactMatch and you can configure a search filter that will return you a unique account from which you can then return the attribute you need (e.g. sAMAccountName). If not, if your certificates contain a value that you can filter on (e.g. certificate cn = LDAP cn) that you can use to retrieve a candidate set of LDAP results for, extract their certificates to X509Certificate and do .equals() against the passed in certificate to find the account that matches and return its uid.

Answer 2

Set up the LDAP server to use SSL with client authentication.

Answer 3

Finally, I've implemented the following sollution in my NON-web application :
<bean id="x509ContextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
<constructor-arg value="ldap://hostname:389/DC=base,DC=com" />
<property name="authenticationStrategy">
<bean class="org.springframework.ldap.core.support.ExternalTlsDirContextAuthenticationStrategy">
<property name="sslSocketFactory">
<bean class="yourOwnSocketFactory"/>
</property>
<property name="shutdownTlsGracefully" value="true" />
</bean>
</property>
</bean>
where yourOwnSocketFactory takes the user's certificate to establish the TLS connection.
A successfull TLS connection means the user is authenticated. That's the case with a well configured LDAP, which should check the user including certificate revokation list.
Once the connection established, you have to recover the user's informations with a custom BindAuthenticator which could extract (X509PrincipalExtractor) Certificate DN (or other usefull info) to match the LDAP user.