Folks, I stumbled upon this thread today and thought I'd send an update here to cas-users (also on cas-dev) just make sure folks are in the loop.
LDAP Password Policy Enformcement Update I've completed the merge of LPPE into the feature branch on https://source.jasig.org/cas3/branches/cas-server-3.4.10-lppe/ such that I can build and install CAS 3.4.10-LPPE-SNAPSHOT in my local mvn repo. This allows me to build a cas server with the feature via simple local maven overlay. To get it to work you need to pull in the configuration files in the resources directory of https://source.jasig.org/sandbox/cas-password-policy/branches/cas-server-support-ldap-pwd-expiration-3.4.x/ I have it working with Active Directory and can induce the PasswordWarning screen. I still need to spend some more time with the code and exercising the features. I'd like to arrive at a maintainable approach for this feature for CAS3 in the near term. Would love some collaboration, thoughts, comments on how best to improve on this and help identifying any blockers for inclusion in CAS 3.5. Please share your thoughts... This work is being driven by requirements at Lamar University. Best, Bill -- On Wed, Jan 26, 2011 at 10:24 AM, Andrew Petro <[email protected]> wrote: > ** > CAS developers, > > *The short version:* > > https://wiki.jasig.org/display/CASUM/LDAP+Password+Policy+Enforcement > > I'd like to make this CAS extension more productized akin to ClearPass for > near-term adoption with current GA CAS releases, and to implement this > functionality in CAS trunk so that the next new-functionality release of CAS > will ship with this functionality, and I'm seeking CAS developer feedback on > these ideas. > > * > The long version:* > > > An extension to CAS with apparently growing popularity: > > https://wiki.jasig.org/display/CASUM/LDAP+Password+Policy+Enforcement > > Scratches a real itch, in many ways very nicely done. > > However, it's struggling to keep up with CAS server releases, has some > modularity issues (modified version of CentralAuthenticationService.java?), > and in practice would-be adopters are having trouble following the > instructions to get it installed. > > I sympathize -- I found it complex too, and as Felix Shumacher recently > articulated on cas-user@ (copied below), there's a handful of problems, > bugs, issues that would-be adopters currently have to fix locally. > > I think one issue here is that the module isn't in Jasig source control and > tracked through Jasig JIRA so that it's easier to articulate issues, > patches, track change, collaborate upon it. Attachments to a wiki page are > an excellent start -- I believe ClearPass in part got its start this way -- > but module maturity leads to more sophisticated source control approaches. > > I also see opportunities in making this extension more general. Password > policy isn't an LDAP-specific concept, though there's interesting support > here for LDAP-specific, even AD-specific implementation. Refactoring to > articulate that this feature isn't LDAP specific -- that it's an API for > informing CAS about password policy and web flow configuration to reflect > that policy in the user experience, with handy LDAP implementations of the > plugin API -- would make it more useful even in places not relying upon LDAP > to articulate password policy. > > > So, with all that background, what to do next with this module? > > My current thinking: > > For the current CAS 3.4.5 release specifically and for CAS 3.4.x ongoingly: > productize this module in a way akin to ClearPass, such that it's in > cas-extensions source control, has a JIRA issue tracker, etc. > > In CAS server trunk, merge in this feature more directly, such that CAS > server trunk includes password policy feature support by default in the > shipping Spring web flow, but with no policy plugin turned on. If adopters > want password policy reflected in the CAS login flow experience, they simply > declare a Spring bean implementing their password policy, optionally relying > upon a handy LDAP-specific implementation. If they don't want the feature, > they do nothing and the password policy steps, while present in the web > flow, have no effect. > > It complexifies the default web flow a bit to include states for handling > password policy that won't be used by all adopters, but my current thinking > is that on balance this is a better tradeoff than those wanting what I'd > think would be an ever-more-popular feature having to muck with their web > flow to get it. > > > > > I'll be more than happy to navigate the politics and policy of whatever the > CAS committers think of these ideas -- securing blessing from cas-steer or > from Incubation in provisioning the source, issue tracking, etc. resources. > This email is intended to spur CAS committer discussion and ideally > consensus on good moves here, rather than to operationally step through how > to execute on those good moves... > > Appreciate any feedback. > > Andrew > > > > -------- Original Message -------- Subject: Re: [cas-user] > ldap-pwd-expiration module Date: Wed, 26 Jan 2011 09:54:45 -0500 From: > Andrew > Petro <[email protected]> <[email protected]> Reply-To: > [email protected] To: [email protected] > > > Is there any interest in implementing the functionality of this > module into the main sources? > > Yes. Very much so. For some reasonable meaning of "into the main > sources". > > I could see it as a an extension as productized and easy to implement as > ClearPass. I could also see it as a core CAS module alongside the other > core included CAS modules, perhaps even with these password policy > checks in the CAS login web flow by default but doing nothing in the > case where no implementation of the password policy API is available, > assuming buy-in of CAS committers on the value of the feature versus its > complexity cost. I'll start a thread on cas-dev on this topic. > > Your changes all sound welcome improvements. Can you share the source? > I'd love to merge your improvements in as the basis of a more > productized update to this module, whether the next answer here is > polishing an extension module ala ClearPass or inlining the > functionality into CAS. > > Thanks, > > Andrew > > > > On 01/25/2011 05:02 AM, Felix Schumacher wrote: > > Hi, > > > > we have use ldap-pwd-expiration module as a starting point to > > implement warnings and a short webflow to change passwords if the user > > has a password, which is short of expiring. > > > > There were a few things, which we did differently than shown in the wiki. > > > > 1. We started with placing the module inside the checked out svn > > sources and edited the pom.xml directly to include it. > > While that seemed to work - it created a jar file with the classes > > inside - the war file of our overlay build hat a few problems. > > a) The needed "principal" could not be found by the webflow, since > > b) ldap-pwd-expiration changed a few central classes while > > remaining the old classnames. > > Those two things were a result of ordering of the jar-files in > > WEB-INF/lib/. Tomcat will use the first class for a given name, that > > it finds in the classloader. (We could have solved it by renaming > > ldap-pwd-expiration jar to start with aa- or something like that. But > > that seems a bit flakey. > > > > 2. We changed the webflow of ldap-pwd-expiration as suggested by > > another thread on this list, to leave out the "viewScope" out of the > > new end-states. > > > > 3. We changed the code, which parses the ldap exception messages, so > > it can be configured by spring. We don't use ads and our ldap server > > has different error messages. > > > > 4. As a result we copied all files from the ldap-pwd-expiration module > > into our overlay directory and changed the names of the classes, to > > avoid classloader problems. > > > > 5. (There is a minor bug in the original source. It will overwrite the > > instance variable validDays with user specific values) > > > > > > Is there any interest in implementing the functionality of this module > > into the main sources? > > > > Any thoughts? > > Felix > > > > > > > > > -- > 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-user > > -- > 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
