New CAS single sign-on plugin

[Fabien Crespel]

Hello,

I would like to contribute a new CAS SecurityRealm plugin to Jenkins. Jasig 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 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.

[J. David Beutel]

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 (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 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.

[Fabien Crespel]

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 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 (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 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.

[Fabien Crespel]

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 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 (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 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.

[Fabien Crespel]

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 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 (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 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.

[nicolas de loof-2]

Done,

Repo : https://github.com/jenkinsci/cas-plugin

CI job : https://jenkins.ci.cloudbees.com/job/plugins/job/cas/

2012/9/3 Fabien Crespel <[hidden email]>

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 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 (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 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.

[Fabien Crespel]

Thanks Nicolas. It seems that I don't have commit rights over the forked repo though, could you please double check this and fix it? My GitHub username is fcrespel.

- Fabien.


Le mardi 4 septembre 2012 08:00:53 UTC+2, nicolas de loof a écrit :

Done,

Repo : https://github.com/jenkinsci/cas-plugin

CI job : https://jenkins.ci.cloudbees.com/job/plugins/job/cas/

2012/9/3 Fabien Crespel <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="jJvYlPnEFVYJ">fab...@...>

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 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 (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 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.

[nicolas de loof-2]

You're in the dev team for this plugin : https://github.com/organizations/jenkinsci/teams/239745

2012/9/4 Fabien Crespel <[hidden email]>

Thanks Nicolas. It seems that I don't have commit rights over the forked repo though, could you please double check this and fix it? My GitHub username is fcrespel.

- Fabien.


Le mardi 4 septembre 2012 08:00:53 UTC+2, nicolas de loof a écrit :

Done,

Repo : https://github.com/jenkinsci/cas-plugin

CI job : https://jenkins.ci.cloudbees.com/job/plugins/job/cas/

2012/9/3 Fabien Crespel <[hidden email]>

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 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 (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 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.

[Fabien Crespel]

Perfect, it works now. Thanks :-)

- Fabien.

Le mercredi 5 septembre 2012 10:24:22 UTC+2, nicolas de loof a écrit :

You're in the dev team for this plugin : https://github.com/organizations/jenkinsci/teams/239745

2012/9/4 Fabien Crespel <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="2nF5txVfzNsJ">fab...@...>

Thanks Nicolas. It seems that I don't have commit rights over the forked repo though, could you please double check this and fix it? My GitHub username is fcrespel.

- Fabien.


Le mardi 4 septembre 2012 08:00:53 UTC+2, nicolas de loof a écrit :

Done,

Repo : https://github.com/jenkinsci/cas-plugin

CI job : https://jenkins.ci.cloudbees.com/job/plugins/job/cas/

2012/9/3 Fabien Crespel <[hidden email]>

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 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 (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 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.