I agree that some refactoring may be in order to take advantage of new ppolicy. I'd still vote that we keep the following for non-ppolicy use cases, in addition to the settings below:
- ldapDateConverter - datetimeF ormatter (This we may be able to remove; Not sure if ldaptive provides native formatting of date attributes?) - passwordExpirationDateAttributeName - accountLockedAttributeName - accountPasswordMustChangeAttributeName If you feel like they could moved to a lower level (or perhaps into ldaptive itself), that'd be perfectly fine. Given the variety of how lppe is implemented I suspect that we have to maintain a few custom attributes to accommodate "manual" checking of the policy. Needless to say, I'd be happy to lend a hand in testing the proposed changeset against AD and report back. The PPAction component was removed in favor of the handler, in the sense that checking policy would be all self-contained inside the handler. This would of course include scenarios where handler would block authentication all together as a result of say, an account being locked, or one that would be warned for expiration date nearing. So long as the handler is throwing back the right type of exception, the exception-handler would be able to alternate the flow. This would lessen configuration, and of course documentation and troubleshooting. Misagh ----- Original Message ----- From: "Marvin Addison" <[email protected]> To: [email protected] Sent: Friday, January 17, 2014 7:39:36 AM Subject: Re: [cas-dev] Accommodating ppolicy in LPPE I wanted to provide an update on this work. We will need to refactor the configuration provided in PasswordPolicyConfiguration since many of the controls are irrelevant to directories other than AD. My inclination is to simply remove them, at least temporarily. That leaves the following controls: - alwaysDisplayPasswordExpirationWarning - passwordWarningNumberOfDays (removed "default" from name since it's not a default in most cases) - passwordPolicyUrl Everything appears specific to AD. My personal feeling is that there were way too many configuration knobs, and this refactoring simplifies. I'm open to an argument that the controls are needed; in that case we'll need a strategy to accommodate directory-specific configuration. Another benefit of this refactoring is that there's nothing directory-specific about that configuration component, so it can be move to core. That is a good segue into broader design issues. There's now no reason that password policy can't be baked into the default webflow. The PasswordPolicyAction can fire in all cases after form submission and only do something meaningful if a PasswordPolicyConfiguration bean is configured. I believe that will dramatically improve ease of configuration. It also creates a path to implementing password policies for other authentication backends. Somewhat concerning is that the PasswordPolicyAction has apparently been deleted or renamed such that I can't find it. I could pore over the commit log to find it, but simply asking what happened is probably easier. 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
