May 28th, 2008, 04:18 PM
CasProcessingFilter Never Calls onUnsuccessfulAuthentication
I used to be able to log authentication exceptions from the onUnsuccessfulAuthentication method of my custom AuthenticationProcessingFilter when using form based authentication. Now however after trying to switch to the JA-SIG CAS product, this method is never called. I am not sure if this a configuration issue or not. I have tried various configs, and would appreciate if someone could clarify for me if how I can achieve such functionality. Currently I am extending the CasProcessingFilter, but thought I might have to change something on the CAS server itself?
Java 5, Spring 2.0.+, Spring Security 2.5.+, CAS 3.2, CAS Client 3.1.1
Last edited by julian; May 28th, 2008 at 04:21 PM.
May 28th, 2008, 04:26 PM
When Spring Security is used with CAS, CAS actually handles the authentication and Spring Security merely validates the ticket sent by CAS.
Thus, if you were to call either successful or unsuccessful from Spring Security all you'd get is whether ticket validation failed or not (which pretty much can't unless the service urls don't match up or you attempt to re-use a ticket). Either way, on an unsuccessful ticket validation, you don't have any useful information other than the failed ticket.
May 28th, 2008, 06:13 PM
Thanks for the response. I figured that was my problem. I suppose the solution is then to extend certain CAS components?
May 28th, 2008, 09:23 PM
Since you're using CAS 3.2, you can take advantage of the fact that we're leveraging the Inspektr library (http://code.google.com/p/inspektr [disclaimer: I am a committer to that also]).
If you look in the unused-spring-configuration directory in the WEB-INF directory you'll see something about an audit-context.xml (or something similar to that). It gives an example of how to enable the Inspektr package. The default configuration prints everything out to the console so if you enable it you can see what kinds of messages it can gather.
We have a AuditTrailManager that writes to database tables (again see the Inspektr web site), but you can write a custom one if you already have existing tables.
May 29th, 2008, 11:16 AM
Well this certainly would work for auditing purposes, but what about adding password expiration, captcha, or account locked capabilities? Would it be best to change the login-webflow to add logic to check for password expiration, etc.? Perhaps by overriding org.jasig.cas.web.flow.AuthenticationViaFormAction to add more return values (e.g. result("credentialsExpired"))?