> Using the method you recommended we cannot subclass
> BindLdapWithX509AuthenticationHandler

Reading your use case again, I'm pretty sure you don't need anything
other than BindLdapAuthenticationHandler.  You didn't mention anything
in particular about the X.509 authentication process, but I will
assume it's standard issuer verification.  That can be handled
directly by the container in most cases (e.g. Tomcat, JBoss,
Apache+Tomcat), freeing the application from having to deal with
certificate authentication.  If you get a certificate in the request,
you can be sure it's a valid one in your PKI.

> I assume that we would then have to extract the email address from the
> certificate in the credentials object

Correct.  I recommended creating a subclass of
UsernamePasswordCredentials that can store the email address from the
cert since that will cause an LDAP authentication handler to fire to
handle the user/pass credentials.  I hope I made it clear the strategy
you'd use to get the certificate out of the request so that you will
have access to the email.  That's the only tricky part.

I would like to emphasize that you should not enable the x509Check
action in the login webflow if you follow my outline.  My strategy in
essence is a one-off of username/password authentication, and that
action will short circuit username/password handlers if enabled.

> This also requires replacing the current
> use of LdapUtils.getFilterWithValues with our own (similar but extended
> code). We can then do a single LDAP lookup using a filter "|((uid=<username
> from webform>)(mail=<mail from cert>))".

I suspect you would need to make the change you suggest because it
currently only handles one parameter replacement, where you'd need
two:  username and email.  That seems like a pretty straightforward
change.

Good luck,
Marvin

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

Reply via email to