> LPPEAuthenticationHandler estimates the account status itself, by looking at > some attributes to calculate the expiration date, etc. BUT in ppolicy there > are no such attributes in the user's record. From this point of view, > LPPEAuthenticationHandler is not generic enough to handle this kind of > mechanism and therefore creating a class that extends from it won't work.
That was the first thing I noticed in my review. The good news is that ldaptive handles most of the directory-specific details, so we can simply create a pluggable API for specifying which directory we're talking about, then let ldaptive do the heavy lifting. > org.ldaptive.auth.ext.PasswordPolicyAuthenticationResponseHandler can manage > this response and set the account status accordingly Yup, but we do need some CAS-specific adapter components that are aware of the underlying directory. These hypothetical components will be responsible for transforming an ldaptive AccountState into a set of Message objects (expiration warnings in this case) or an exception (password expired/locked) that will be bubble up the stack from the authentication subsystem to the Web tier where we can leverage Webflow to dispatch to the proper view. 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
