Two objectives mostly come to mind: The "it gets too messy" approach to avoid complicating the existing Ldap handler and ensure that those without LPPE needs can still configure the handler without having to worry about other details. I suspect that the two may comfortably merge and responsibilities of the LPPE handler can safely be dispatched to a pluggable component and set to void for those care not about LPPE.
Misagh ----- Original Message ----- From: "Marvin Addison" <[email protected]> To: [email protected] Sent: Wednesday, January 15, 2014 9:39:54 AM Subject: [cas-dev] Accommodating ppolicy in LPPE I'm starting to look at what is required to fully support OpenLDAP ppolicy in the LPPE framework. I believe most if not all the work can be performed in the AuthenticationHandler. It looks like it's simply a matter of extending the capabilities presently handled by LPPEAuthenticationHandler. I haven't completed my analysis, but subclassing or dispatching come to mind as approaches. My preliminary analysis begs a question: why do we need LPPEAuthenticationHandler? I had in mind that password expiration would be a first-order consideration for AuthenticationHandlers; in that view the functionality in the LPPE handler should be pulled down into LdapAuthenticationHandler. That looks to me like mostly moving code around, but possibly there are benefits to that organization that aren't clear. We might need directory-specific subcomponents to do the account state handling so the one handler doesn't get too messy, but I don't see the need for more than one LDAP authentication handler. Thoughts? 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
