> I've modified CasLoginView.lsp to display a warning if a X509 certificate is > showed but authentication has failed, so how can I determine the reason why > the certificate has been rejected ? Main causes I've identified are : > - Certificate is not paired (I'd show a link to our pairing application) > - Certificate is revoked > - LDAP Lookup was not fast enough
By "pairing" I suppose you mean there is no corresponding LDAP account corresponding to the cert. If that's correct you could potentially provide meaningful errors for cases 1 and 3. Case 2, revoked certificate, can't be handled by CAS because something external to the JVM (OpenSSL in your case) is performing the SSL negotiation. The container is bouncing the connection long before the request could get to the cas servlet for examination of the cause. Supporting case #2 brings up some interesting points for discussion. It's worth discussion because currently you have to do substantial work to provide a good user experience for a failed cert authentication. I wonder whether it would it be possible and feasible to develop some components that hook into the container (e.g. Tomcat) that would accept _any_ client certificate and delegate to the X509AuthenticationHandler for full validation, including the following: - Validity (NotBefore+NotAfter) - Allowed issuer - Path length checking - Revocation The second point above is fairly involved since we'd no longer be relying on the container to do the cert path verification, which is the assumption underlying the simple regex patterns we currently use for that feature. So the question is, if it's possible, is it worth the admittedly large effort to support a better user experience for X.509 auth. I'm taking for granted that the browser dialogs for failed SSL negotiation provide a terrible user experience. M -- 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
