The issue I'm attempting to address is that each flavor of LDAP returns a 
different error message for account conditions such as locked.

The original LPPE had explicit exception such as LDAPAccountLocked that used a 
regex pattern to determine if the error thrown by the LDAP mapped to the 
explicit exception, each exception also had a separate error handler that then 
mapped the error to a flow action.

The problem I saw with this method was that in order for a deployer to use an 
LDAP server other the Active Directory they need sufficient JAVA knowledge to 
write their own exceptions and to add them into the LDAP exception chain.


What I wrote into the proposed LPPE module is a class that accepts Regex / 
Error message pairs that are configured via spring, the deployer is able to 
specify a regex pattern and what error message to throw in response, the errors 
are thrown as a BadCredentialsAuthenticationException exception. There is also 
a error handler web flow class that reads the message context and again based 
on spring configuration maps an error message to a flow action.


-Andrew

On Nov 15, 2011, at 4:33 PM, Scott Battaglia wrote:

> The exceptions should be as explicit as they need to be to get the job done.  
> Java can't easily make decisions when it needs to extract details from the 
> message itself.   If an account is locked, there is no reason not to throw an 
> account locked exception.
> 
> CAS4 API uses the Java6 exception hierarchy as its starting point, e.g.
> 
> http://download.oracle.com/javase/6/docs/api/javax/security/auth/login/AccountLockedException.html
>  
> 
> The CAS4 API for password policy uses explicit exceptions also and there are 
> no plans to change that.  I also don't see what the point would be in the 
> LPPE if we didn't map to useful exceptions (how much better is it than 
> parsing LDAP error codes at that point?)
> 
> 
> On Tue, Nov 15, 2011 at 3:45 PM, Tillinghast, Andrew P. 
> <[email protected]> wrote:
> 
> 
> Last week during the unconference I had the opportunity to review my proposed 
> LPPE changes with Bill Thompson and Andrew Petro, during the topic of CAS 
> error handling came up and it seemed like it was a topic that needed broader 
> discussion then the three of us could cover.
> 
> In the previous iteration of the LDAP Password Policy Enforcement the LDAP 
> errors were mapped into explicit exception each with a separate custom error 
> handler and in the new version LPPE is throwing a generic 
> BadCredentialsAuthenticationException where a regex pattern and error message 
> is defined in the Spring Configuration. While there isn't a clear reason to 
> choose one method over the other I felt the generic exception and spring 
> configuration made customization of LPPE for different LDAP servers 
> accessible to more deployers. The explicit exceptions required the deployer 
> to know basic java rather then just XML.
> 
> It would seem the original direction of CAS was towards explicit exceptions, 
> there is even a BlockedCredentialsAuthenticationException in the CAS core but 
> in a casual search of the code I couldn't find any place where the exception 
> was thrown or handled.
> 
> Bill, Andrew and I came up with a compromise of sorts and I did like to see 
> if the CAS developer community at large was comfortable with it.
> 
> Generic Exceptions for "expected" exceptions, for example in the normal 
> workflow we expect some user's will get an account disabled message from 
> LDAP, it makes sense to throw this as a generic exception and allow some form 
> of error handling.
> 
> Explicit Exceptions for "exceptional" exceptions (Andrew Pero's term, not 
> mine), for example a view not found while processing login flow - These 
> exceptions should be explicit so they can be easier to track in logging and 
> in researching the cause.
> 
> 
> I don't know if i was very eloquent in explaining the discussion but it seems 
> that the community's take on this is key to determining if my proposed 
> changes to LPPE are acceptable or not.
> 
> Andrew Tillinghast
> Sr. Web Developer
> [email protected]
> 270 Mohegan Avenue
> New London, CT 06320-4196
> Ph:860 439-5265 Fax: 860 439-2871
> P Think before you print
> CONFIDENTIALITY: This email (including any attachments) may contain 
> confidential, proprietary and privileged information, and unauthorized 
> disclosure or use is prohibited. If you received this email in error, please 
> notify the sender and delete this email from your system.
> 
> 
> 
> -- 
> 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-dev
> 
> -- 
> 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-dev


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

Reply via email to