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]> 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
