Hello there, Jenkins admins, could you please review my plugin fork request above? it has gone unnoticed for more than a month now... :-) If there is anything preventing it, please let me know.
Thanks, Fabien. Le lundi 30 juillet 2012 10:08:49 UTC+2, Fabien Crespel a écrit : > > Hello, > > It has been a bit more than a couple weeks now and I'd like to move > forward with this. Considering this plugin is separate from the CAS1 > plugin, I don't see an issue with releasing it now even if the CAS1 plugin > isn't immediately marked as deprecated; for the moment a simple notice on > its wiki page could invite users to try the new plugin. > > Jenkins admins, are you fine with this and if so, could you please proceed > with forking the code repo at > https://github.com/fcrespel/jenkins-cas-plugin, giving me access to the > forked one as well as setting up the CI job? > > Thank you in advance, > Fabien. > > > Le jeudi 12 juillet 2012 22:49:48 UTC+2, Fabien Crespel a écrit : >> >> Thanks for your feedback :-) >> >> I merged your pull request and added 2 commits, to fix an extraneous "/" >> character in the logout URL and a problem with SAML 1.1 when running under >> the embedded Jetty from the HPI plugin. So you should be able to test the >> plugin simply by running "mvn hpi:run" from the command line, and >> configuring the CAS Security Realm at localhost:8080/configure. As a side >> note for anyone else interested in testing, you can get a CAS server >> working in no time by dropping the >> cas-server-webapp<http://repo1.maven.org/maven2/org/jasig/cas/cas-server-webapp/3.4.12/cas-server-webapp-3.4.12.war>into >> a servlet container (e.g. Tomcat); the default config allows you to >> login with matching pairs of username/password (e.g. test/test). >> >> Regarding the Jetty jsessionid hack, I haven't seen a need for it during >> testing... it may no longer be an issue, or the way the new plugin works >> simply doesn't trigger the problem..? >> As for the migration path from the CAS1 plugin, I would agree that simple >> deprecation and prominent notices on the wiki are enough; there aren't many >> options to configure so users could simply copy them. >> >> So if you think that this new plugin is ready for publication, could you >> please give your green light here so that Jenkins admins can fork the repo, >> create the CI job, etc. ? >> >> Thanks in advance, >> - Fabien. >> >> >> Le jeudi 12 juillet 2012 06:10:19 UTC+2, J. David Beutel a écrit : >>> >>> This looks like a big improvement! The code looks clean and nicely >>> factored. >>> >>> I haven't worked on the old one for a couple years, and it's the only >>> Jenkins plugin I've done, so I don't know just by looking at the new one >>> whether there are any problems. A code review by an experienced Jenkins >>> developer would still be good to get. But, I'll try out the new one, when >>> I finally get time to update the Jenkins instance I'm using now. >>> >>> I didn't see the jsessionid hack for Jetty; is it not needed anymore? >>> It might only be an issue with the CAS 1 client library, or some old >>> version of one of the other components. >>> >>> I don't know if there are any potential issues with using Spring >>> Security together with Acegi. I guess it's OK, if it works, and they're in >>> separate packages. >>> >>> If it's accepted as an official plugin, I guess we'd just deprecate the >>> existing CAS1 plugin, with a link on the wiki to the new one. I don't >>> think that an automatic migration of the configuration is necessary. To >>> upgrade, can users just install the new one, manually configure it like the >>> old one, and uninstall the old one? The users of the old one will dwindle >>> naturally. You're welcome to look into automating the migration, but I >>> don't think it's worth the effort. >>> >>> The one change I'd make is to an example in a help text, to make the >>> usernames anonymous. I'll send you a pull request with that. >>> >>> Cheers, >>> 11011011 >>> >>> On Wednesday, July 11, 2012 10:03:16 AM UTC-10, Fabien Crespel wrote: >>>> >>>> Hello, >>>> >>>> I would like to contribute a new *CAS SecurityRealm plugin* to >>>> Jenkins. Jasig CAS <http://www.jasig.org/cas> (Central Authentication >>>> Service) is a single sign-on (SSO) service implemented as a web >>>> application, and is commonly used in universities and enterprises to >>>> secure >>>> applications without having to login again and again. >>>> >>>> While looking for a way to login with CAS from Jenkins, I found the CAS1 >>>> plugin <https://wiki.jenkins-ci.org/display/JENKINS/CAS1+Plugin> by J. >>>> David Beutel, but as the plugin name implies it only supports the legacy >>>> CAS 1.0 protocol with custom extensions for role parsing. >>>> >>>> The plugin I have developped currently supports the following features: >>>> >>>> - *CAS protocol version 1.0*, preserving role parsing features from >>>> the existing CAS1 plugin. >>>> - *CAS protocol version 2.0*, with limited attribute support >>>> (custom protocol extensions need to be added to the CAS webapp). >>>> - *SAML protocol version 1.1*, with full attribute support >>>> (groups/authorities, mail and full name sync). >>>> - *Authentication renewal* (if enabled, user will have to input >>>> credentials even if a session already exists at CAS side). >>>> - *Single sign-out* (if enabled, user will be logged out of Jenkins >>>> if he logs out of CAS or from other CAS-enabled applications). >>>> - Fully *configurable*, with inline *help *and *i18n *support >>>> (French translation included, except for help texts). >>>> >>>> There are at least a couple more features that I'd like to try >>>> implementing, when/if I have time: >>>> >>>> - CAS 2.0 proxy support (needs configuration and testing) >>>> - CAS gateway mode (if a CAS session exists, login immediately on >>>> first visit) >>>> >>>> >>>> A few implementation notes: >>>> >>>> - This plugin was developed from scratch, it is not a fork of the >>>> CAS1 plugin and works differently, but it uses some bits of code from >>>> it >>>> for CAS 1.0 role parsing. >>>> - CAS protocols are exposed and configured as *extension points*, >>>> making it easy to add more as CAS evolves (e.g. SAML 2.0 one day?) >>>> - CAS authentication filters are defined in a * >>>> CasSecurityRealm.groovy* script defining Spring beans, and are >>>> executed before the original filters configured by Jenkins. This means >>>> that >>>> *anonymous *access and *API Token auth* still work as expected. >>>> - CAS needs Jenkins' URL to be able to redirect back to it; this >>>> plugin simply uses Jenkins.getInstance().getRootUrl(), unlike the CAS1 >>>> plugin which included a specific configuration option. >>>> - Due to missing features in the Acegi Security CAS support, *Spring >>>> Security* 3.0.7 is used instead and up to successful authentication >>>> - at which point the Spring Security Authentication object is mapped to >>>> an >>>> Acegi one and stored in the Acegi SecurityContext. Unlike Acegi, the >>>> Spring >>>> Security CAS support relies more on the official CAS Client library, >>>> supports more protocols and can use attributes to fill authorities. >>>> >>>> >>>> Now, there are a few things I'd like to get feedback on and discuss: >>>> >>>> - Is the Spring Security dependency a potential issue? AFAIK >>>> Jenkins isn't going to move away from Acegi any time soon, and during >>>> testing I didn't find any negative side effect due to using this >>>> library. >>>> The resulting HPI file is only 3 MB big including dependencies. It's >>>> surely >>>> possible to backport Spring Security CAS code to Acegi if need be, but >>>> it >>>> doesn't feel right to me :-) >>>> - If this new plugin is accepted as an official plugin, what would >>>> happen with the existing CAS1 plugin? would they coexist or the new >>>> plugin >>>> be considered as a replacement, and the old one marked as deprecated? >>>> should automatic configuration migration between the two be considered >>>> and >>>> if so, how? (I guess J. David Beutel should weight in here, if >>>> possible, as >>>> the author and maintainer of the CAS1 plugin). >>>> - Considering this is my first Jenkins plugin, a code review would >>>> be most welcome. :-) >>>> >>>> And talking of *code *- here it is at GitHub (username is fcrespel): >>>> https://github.com/fcrespel/jenkins-cas-plugin >>>> Could you please consider it for forking into the official jenkisci >>>> repos? Note that I prefixed my repo with 'jenkins-' but that's really only >>>> for me, after forking I guess the repo should simply be named 'cas-plugin'. >>>> If accepted, I would of course work on a proper wiki page to describe >>>> how to configure the plugin. >>>> >>>> Please let me know what you think, comments and feedback will be >>>> appreciated :-) >>>> >>>> Best regards, >>>> - Fabien. >>>> >>>
