I'd gamble that 90% of the IT folk (at least in the US Education sector) are going to be out of the office the day after Turkey Day ;) myself included.
I'm VERY interested in this topic (as well as my boss,) as we mangled the old "cas-server-support-ldap-pwd-expiration-3.4.2" code to allow for password warnings & other LDAP password policies implemented internally. It was a hack that requires extraneous CAS work (where LDAP password policies already do that work) to say the least... and we're not looking forward to porting it in the future (%50 of the reason why we're still on 3.4.2.) If you do have a talk on Friday that I'm not able to attend... Here's My ยข2: Please (please please please) stick with the Spring Security LDAP ppolicy functionality and allow for the end user to assign specific flow for individual response codes (I'm on the fence about additionally allowing regex flow choices, which would only buy super flexibility for odd scenarios IMHO.) It'll give used users WAY more flexibility in the long run. For instance, password expiration warning is not an "exception" upon authentication (at least in SunOneLDAP) so using Spring Security's ppolicy would be needed to catch this expiration warning correctly. But say if your particular LDAP server also popped out a message about how much time is left before expiration, it might come in handy to fire off a regex to handle that data appropriately (say if you wanted to auth someone and tell someone how much time they had if it was more than X minutes from now, rather than not authenticating them and sending them to a password reset page if it was less than X minutes from now (bending the LDAP policy rules for the sake of internal business rules.)) Now that I think about it, regex may come in handy regardless if it's an authentication exception OR ppolicy caught. To address the "java coding" scenario... Never mind how simple/elegant one tries to implement policy handling in CAS, there will always be an infinite variety of how policy is actually implemented on the LDAP side (let alone the number of available LDAP backends,) and CAS will have to be configured to match. There could always be a set of default handlers, but in most instances there will be some java (and/or web flow) coding/configuration on the CAS side. Frankly, I'd be a bit concerned if my CAS admin did not know their way around java... ;) The provision of clear examples on how to handle particular LDAP response codes and/or exceptions, a template if you will, would make things simple for the majority of people in need of this. I'll be monitoring the thread to answer any questions, etc. Raymond Walker Software Systems Engineer Sr. ITS Northern Arizona University -----Original Message----- From: Scott Battaglia <[email protected]> Reply-To: <[email protected]> Date: Tue, 22 Nov 2011 07:49:19 -0500 To: <[email protected]> Subject: Re: [cas-dev] Discussion: Error handling explicit vs generic >Realized I should have replied to this thread. I've got availability on >Friday for a serious discussion if anyone's is interested/willing. > >On Wed, Nov 16, 2011 at 12:58 PM, Tillinghast, Andrew P. ><[email protected]> wrote: > > >I had actually thought about using the regex to fire explicit exceptions, >I just hadn't thought of it till I had finished coding it the way i did. >The only downside I see if we/i'd need to have the exceptions for the >"all" the LDAP errors and if a deployer had an exception we didn't think >of it would still require Java coding. > >I'm on the jasig-cas chat now and I probably will be the rest of the day. > >-Andrew > > > >On Nov 16, 2011, at 10:59 AM, Scott Battaglia wrote: > > > > >I'm not super familiar with the ppolicy. We should see how that would >work. Currently we just parse the exception messages and throw new >mapped exceptions (similar to what Spring does with Oracle error codes -> >data access exceptions). > >Something to work through via chat? (and then come back to the list) > > >On Wed, Nov 16, 2011 at 10:52 AM, Marvin Addison ><[email protected]> wrote: > >> 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 > > >This strategy is simply inadequate for directories that communicate >account state not through error messages but via ppolicy, >http://opends.java.net/public/standards/draft-behera-ldap-password-policy. >txt. > I think that exceptions are generally the right solution to >communicate detailed error conditions to higher levels of the API, but >I don't think that necessarily precludes the use of mechanisms like >you've described. I see that mechanism as one particular strategy for >selecting the proper exception to throw instead of selecting a >message. That way we can keep the authentication handler "pure" by >dealing strictly with success and failure conditions and letting some >higher-level component (e.g. webflow) maps exceptions onto messages >and performs routing as needed for good UX. With that view the >ppolicy stuff down the road just needs a different exception mapping >handler and the higher-level stuff continues to work with an invariant >set of exceptions. > >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-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 > > > > > > >-- >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
