[Geoserver-devel] CAS reworking and GEOS-5294,GEOS-5293

GeoServer GeoServer Developer
1

Hi all, during the weekend I did a reworking of the CAS module. We have an early adopter on the user mailing list and I try to meet his requirements. There are two CAS authentication filters

  1. A filter usable for the GeoServer GUI
  2. A filter receiving tickets generated by the client

Both filters did not work correctly. I decided to remove the GUI elements for 1), this can be done simply in applicationContext.xml. Integrating CAS login into the Geoserver GUI requires GUI modifications concerning the login work flow.

  1. is working now, I had to do some modifications and changed a lot of test code.

The issues are here
http://jira.codehaus.org/browse/GEOS-5293
http://jira.codehaus.org/browse/GEOS-5294

The git commit is here
https://github.com/mcrmcr/geoserver-1/commit/384034aeb101b977d0d3d76fc9f2336e8a373c6b

All modifications are within the CAS module, no core code is touched. The build itself has a simple test and a complex online test which is not executed if no fixture is found. The build works.

I have no problem to commit on master, but what about the upcoming 2.2.0 ?. At the moment, the GUI allows to create both kinds of CAS filters, but they will not work properly. I am feeling a little bit uncomfortable.

Possible solutions:

a) apply the patch to 2.2.x before releasing 2.2.0

b) remove the configuration possibilities for both CAS filters (commenting out some elements in the applicationContext.xml of the cas module) and commit before releasing 2.2.0. The release 2.2.0 will offer no CAS features at all.
After releasing 2.2.0, backport the fixes to 2.2.x. Version 2.2.1 would offer support for the filter described in 2). The filter described in 1) will be introduced in 2.3.x only.

For our early adopter, I can easily make a sec-cas-2.2-SNAPSHOT.jar for testing.

Opinions ?

2

On Sun, Sep 16, 2012 at 3:48 PM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Hi all, during the weekend I did a reworking of the CAS module. We have an early adopter on the user mailing list and I try to meet his requirements. There are two CAS authentication filters

  1. A filter usable for the GeoServer GUI
  2. A filter receiving tickets generated by the client

Both filters did not work correctly. I decided to remove the GUI elements for 1), this can be done simply in applicationContext.xml. Integrating CAS login into the Geoserver GUI requires GUI modifications concerning the login work flow.

  1. is working now, I had to do some modifications and changed a lot of test code.

The issues are here
http://jira.codehaus.org/browse/GEOS-5293
http://jira.codehaus.org/browse/GEOS-5294

The git commit is here
https://github.com/mcrmcr/geoserver-1/commit/384034aeb101b977d0d3d76fc9f2336e8a373c6b

All modifications are within the CAS module, no core code is touched. The build itself has a simple test and a complex online test which is not executed if no fixture is found. The build works.

I have no problem to commit on master, but what about the upcoming 2.2.0 ?. At the moment, the GUI allows to create both kinds of CAS filters, but they will not work properly. I am feeling a little bit uncomfortable.

Possible solutions:

a) apply the patch to 2.2.x before releasing 2.2.0

b) remove the configuration possibilities for both CAS filters (commenting out some elements in the applicationContext.xml of the cas module) and commit before releasing 2.2.0. The release 2.2.0 will offer no CAS features at all.
After releasing 2.2.0, backport the fixes to 2.2.x. Version 2.2.1 would offer support for the filter described in 2). The filter described in 1) will be introduced in 2.3.x only.

For our early adopter, I can easily make a sec-cas-2.2-SNAPSHOT.jar for testing.

Opinions ?

Plan B could be better, but I’m wondering if an option C could be taken into consideration.
So we have CAS functionality that did not stabilize, but could be interesting anyways and there is a patch.
How about making CAS an extension, apply the patch there, and have people interested in CAS
get the extension, leaving other people with a GeoServer that has no build-in CAS whatsoever?

Core functionality should be limited to stuff that most people will want, I have the impression
CAS is more suited to an extension anyways, since only a limited subset of users will want to use
it anyways. HTTP basic/digest + HTTPs should be the common options, the one that sit in core.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

3

Since there are other authentication mechanisms (OAuth,OpenId, SAML,…) which may find their way into geoserver, I would vote for option C.

The procedure would be

  1. apply the patch on 2.2.x and master
  2. make CAS an extension on 2.2.x and master

If we can do this before 2.2.0, I do not need to make another commit to hide the CAS configuration GUI for 2.2.0.

On master, we have time how to integrate single sign on techniques into the admin GUI.

I would be fine with that.

Christian

2012/9/16 Andrea Aime <andrea.aime@anonymised.com>

On Sun, Sep 16, 2012 at 3:48 PM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Hi all, during the weekend I did a reworking of the CAS module. We have an early adopter on the user mailing list and I try to meet his requirements. There are two CAS authentication filters

  1. A filter usable for the GeoServer GUI
  2. A filter receiving tickets generated by the client

Both filters did not work correctly. I decided to remove the GUI elements for 1), this can be done simply in applicationContext.xml. Integrating CAS login into the Geoserver GUI requires GUI modifications concerning the login work flow.

  1. is working now, I had to do some modifications and changed a lot of test code.

The issues are here
http://jira.codehaus.org/browse/GEOS-5293
http://jira.codehaus.org/browse/GEOS-5294

The git commit is here
https://github.com/mcrmcr/geoserver-1/commit/384034aeb101b977d0d3d76fc9f2336e8a373c6b

All modifications are within the CAS module, no core code is touched. The build itself has a simple test and a complex online test which is not executed if no fixture is found. The build works.

I have no problem to commit on master, but what about the upcoming 2.2.0 ?. At the moment, the GUI allows to create both kinds of CAS filters, but they will not work properly. I am feeling a little bit uncomfortable.

Possible solutions:

a) apply the patch to 2.2.x before releasing 2.2.0

b) remove the configuration possibilities for both CAS filters (commenting out some elements in the applicationContext.xml of the cas module) and commit before releasing 2.2.0. The release 2.2.0 will offer no CAS features at all.
After releasing 2.2.0, backport the fixes to 2.2.x. Version 2.2.1 would offer support for the filter described in 2). The filter described in 1) will be introduced in 2.3.x only.

For our early adopter, I can easily make a sec-cas-2.2-SNAPSHOT.jar for testing.

Opinions ?

Plan B could be better, but I’m wondering if an option C could be taken into consideration.
So we have CAS functionality that did not stabilize, but could be interesting anyways and there is a patch.
How about making CAS an extension, apply the patch there, and have people interested in CAS
get the extension, leaving other people with a GeoServer that has no build-in CAS whatsoever?

Core functionality should be limited to stuff that most people will want, I have the impression
CAS is more suited to an extension anyways, since only a limited subset of users will want to use
it anyways. HTTP basic/digest + HTTPs should be the common options, the one that sit in core.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

4

I agree, making the cas security module an optional piece makes a lot of sense to me. Actually i wanted to do this with all the security extensions, including LDAP, although since it added no additional dependencies it seemed ok to leave it in by default.

Should cas go in extension or community?

On Sun, Sep 16, 2012 at 9:41 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Since there are other authentication mechanisms (OAuth,OpenId, SAML,…) which may find their way into geoserver, I would vote for option C.

The procedure would be

  1. apply the patch on 2.2.x and master
  2. make CAS an extension on 2.2.x and master

If we can do this before 2.2.0, I do not need to make another commit to hide the CAS configuration GUI for 2.2.0.

On master, we have time how to integrate single sign on techniques into the admin GUI.

I would be fine with that.

Christian

2012/9/16 Andrea Aime <andrea.aime@anonymised.com1268…>

On Sun, Sep 16, 2012 at 3:48 PM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Hi all, during the weekend I did a reworking of the CAS module. We have an early adopter on the user mailing list and I try to meet his requirements. There are two CAS authentication filters

  1. A filter usable for the GeoServer GUI
  2. A filter receiving tickets generated by the client

Both filters did not work correctly. I decided to remove the GUI elements for 1), this can be done simply in applicationContext.xml. Integrating CAS login into the Geoserver GUI requires GUI modifications concerning the login work flow.

  1. is working now, I had to do some modifications and changed a lot of test code.

The issues are here
http://jira.codehaus.org/browse/GEOS-5293
http://jira.codehaus.org/browse/GEOS-5294

The git commit is here
https://github.com/mcrmcr/geoserver-1/commit/384034aeb101b977d0d3d76fc9f2336e8a373c6b

All modifications are within the CAS module, no core code is touched. The build itself has a simple test and a complex online test which is not executed if no fixture is found. The build works.

I have no problem to commit on master, but what about the upcoming 2.2.0 ?. At the moment, the GUI allows to create both kinds of CAS filters, but they will not work properly. I am feeling a little bit uncomfortable.

Possible solutions:

a) apply the patch to 2.2.x before releasing 2.2.0

b) remove the configuration possibilities for both CAS filters (commenting out some elements in the applicationContext.xml of the cas module) and commit before releasing 2.2.0. The release 2.2.0 will offer no CAS features at all.
After releasing 2.2.0, backport the fixes to 2.2.x. Version 2.2.1 would offer support for the filter described in 2). The filter described in 1) will be introduced in 2.3.x only.

For our early adopter, I can easily make a sec-cas-2.2-SNAPSHOT.jar for testing.

Opinions ?

Plan B could be better, but I’m wondering if an option C could be taken into consideration.
So we have CAS functionality that did not stabilize, but could be interesting anyways and there is a patch.
How about making CAS an extension, apply the patch there, and have people interested in CAS
get the extension, leaving other people with a GeoServer that has no build-in CAS whatsoever?

Core functionality should be limited to stuff that most people will want, I have the impression
CAS is more suited to an extension anyways, since only a limited subset of users will want to use
it anyways. HTTP basic/digest + HTTPs should be the common options, the one that sit in core.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

On Sun, Sep 16, 2012 at 6:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I agree, making the cas security module an optional piece makes a lot of sense to me. Actually i wanted to do this with all the security extensions, including LDAP, although since it added no additional dependencies it seemed ok to leave it in by default.

Should cas go in extension or community?

If Christian agrees to maintain it I’d move it to extension, given that so far it has lived in core
and some people out there are trying to use it. New security modules should start from
community though

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

6

On Sun, Sep 16, 2012 at 11:43 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sun, Sep 16, 2012 at 6:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I agree, making the cas security module an optional piece makes a lot of sense to me. Actually i wanted to do this with all the security extensions, including LDAP, although since it added no additional dependencies it seemed ok to leave it in by default.

Should cas go in extension or community?

If Christian agrees to maintain it I’d move it to extension, given that so far it has lived in core
and some people out there are trying to use it. New security modules should start from
community though

Works for me. +1

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

7

Good work but I am also for having it as an extension. It can be moved
into core when fully stabilized and if very widely adopted. (though I
would be an early adopter).

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.

8

On 17/09/12 05:42, Phil Scadden wrote:

Good work but I am also for having it as an extension. It can be moved
into core when fully stabilized and if very widely adopted. (though I
would be an early adopter).

I am happy to put CAS in extension.

Phil, "extension" is more about architecture rather than stability. Extension modules often have the same level of support and stability as core; the main difference is that extension modules do not need to be included in a GeoServer deployment (plugins, for example). Modules without core developer support or that are experimental go in community:
http://docs.geoserver.org/latest/en/developer/policies/community-modules.html#promoting-a-community-module

Kind regards,
Ben.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

9

Of course I will maintain this module (as long as I have a mandate from OpenGeo to do so).

The question is if we migrate the CAS module to an extension before 2.2.0 or afterward. Before 2.2.0 is less complicated but if this is not possible, I will disable the CAS configuration GUI.

Please let know, I will coordinate the work with Justin.

Christian

2012/9/17 Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>

On 17/09/12 05:42, Phil Scadden wrote:

Good work but I am also for having it as an extension. It can be moved
into core when fully stabilized and if very widely adopted. (though I
would be an early adopter).

I am happy to put CAS in extension.

Phil, “extension” is more about architecture rather than stability.
Extension modules often have the same level of support and stability as
core; the main difference is that extension modules do not need to be
included in a GeoServer deployment (plugins, for example). Modules
without core developer support or that are experimental go in community:
http://docs.geoserver.org/latest/en/developer/policies/community-modules.html#promoting-a-community-module

Kind regards,
Ben.

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

10

On Mon, Sep 17, 2012 at 9:39 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Of course I will maintain this module (as long as I have a mandate from OpenGeo to do so).

We just need short term commitment, if you decide to drop CAS support later
we can either search for another maintainer or drop the module back in community land.
Stuff in core is more complicated, as it’s officially maintained by the PSC.

The question is if we migrate the CAS module to an extension before 2.2.0 or afterward. Before 2.2.0 is less complicated but if this is not possible, I will disable the CAS configuration GUI.

Before if at all possible, this week we should try to release 2.2.0 final

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

11

On Mon, Sep 17, 2012 at 2:11 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Sep 17, 2012 at 9:39 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Of course I will maintain this module (as long as I have a mandate from OpenGeo to do so).

We just need short term commitment, if you decide to drop CAS support later
we can either search for another maintainer or drop the module back in community land.
Stuff in core is more complicated, as it’s officially maintained by the PSC.

The question is if we migrate the CAS module to an extension before 2.2.0 or afterward. Before 2.2.0 is less complicated but if this is not possible, I will disable the CAS configuration GUI.

Before if at all possible, this week we should try to release 2.2.0 final

Christian, i can help with this. This should be pretty straight forward since as originally written the security plugins were already designed to be extensions, and outside the core module.

@Christian: Let me know if you want to do this? Otherwise i will start the reshuffling probably tomorrow. Hoping for a release later this week.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

12

Hi Justin, I can do this on Friday, a little bit late and I am not used to do these kind of migration. I am still unsure if the patch goes into 2.2.0. My idea would be to

  1. apply the patch to 2.2.x
  2. cherry-pick on master
  3. make CAS a geoserver extension on 2.2.x and master

Again, if 2.2.0 is not an option, I still have to remove the GUI configuration in applicationContext.xml.

Your support here would be nice. Let me know about the result :slight_smile:

Thanks

2012/9/17 Justin Deoliveira <jdeolive@anonymised.com>

On Mon, Sep 17, 2012 at 2:11 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Sep 17, 2012 at 9:39 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Of course I will maintain this module (as long as I have a mandate from OpenGeo to do so).

We just need short term commitment, if you decide to drop CAS support later
we can either search for another maintainer or drop the module back in community land.
Stuff in core is more complicated, as it’s officially maintained by the PSC.

The question is if we migrate the CAS module to an extension before 2.2.0 or afterward. Before 2.2.0 is less complicated but if this is not possible, I will disable the CAS configuration GUI.

Before if at all possible, this week we should try to release 2.2.0 final

Christian, i can help with this. This should be pretty straight forward since as originally written the security plugins were already designed to be extensions, and outside the core module.

@Christian: Let me know if you want to do this? Otherwise i will start the reshuffling probably tomorrow. Hoping for a release later this week.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

13

Hey Christian,

I was actually hoping to get the release started before Friday. And i won’t really have much time this weekend to do it and then early next week I will be traveling. So if you don’t mind i may do the reshuffling for now.

This means that if you have locally committed changes you are going to have to probably manually reapply them to the newly moved module. Will this be a problem?

On Mon, Sep 17, 2012 at 10:04 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Hi Justin, I can do this on Friday, a little bit late and I am not used to do these kind of migration. I am still unsure if the patch goes into 2.2.0. My idea would be to

  1. apply the patch to 2.2.x

  2. cherry-pick on master

  3. make CAS a geoserver extension on 2.2.x and master

Again, if 2.2.0 is not an option, I still have to remove the GUI configuration in applicationContext.xml.

Your support here would be nice. Let me know about the result :slight_smile:

Thanks

2012/9/17 Justin Deoliveira <jdeolive@anonymised.com>

On Mon, Sep 17, 2012 at 2:11 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Sep 17, 2012 at 9:39 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Of course I will maintain this module (as long as I have a mandate from OpenGeo to do so).

We just need short term commitment, if you decide to drop CAS support later
we can either search for another maintainer or drop the module back in community land.
Stuff in core is more complicated, as it’s officially maintained by the PSC.

The question is if we migrate the CAS module to an extension before 2.2.0 or afterward. Before 2.2.0 is less complicated but if this is not possible, I will disable the CAS configuration GUI.

Before if at all possible, this week we should try to release 2.2.0 final

Christian, i can help with this. This should be pretty straight forward since as originally written the security plugins were already designed to be extensions, and outside the core module.

@Christian: Let me know if you want to do this? Otherwise i will start the reshuffling probably tomorrow. Hoping for a release later this week.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

14

No, do it as you prefer and I will apply the patch. It is a good idea to exclude CAS from the core build and this gives me some freedom to work on this topic.

2012/9/17 Justin Deoliveira <jdeolive@anonymised.com>

Hey Christian,

I was actually hoping to get the release started before Friday. And i won’t really have much time this weekend to do it and then early next week I will be traveling. So if you don’t mind i may do the reshuffling for now.

This means that if you have locally committed changes you are going to have to probably manually reapply them to the newly moved module. Will this be a problem?

On Mon, Sep 17, 2012 at 10:04 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Hi Justin, I can do this on Friday, a little bit late and I am not used to do these kind of migration. I am still unsure if the patch goes into 2.2.0. My idea would be to

  1. apply the patch to 2.2.x

  2. cherry-pick on master

  3. make CAS a geoserver extension on 2.2.x and master

Again, if 2.2.0 is not an option, I still have to remove the GUI configuration in applicationContext.xml.

Your support here would be nice. Let me know about the result :slight_smile:

Thanks

2012/9/17 Justin Deoliveira <jdeolive@anonymised.com>

On Mon, Sep 17, 2012 at 2:11 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Sep 17, 2012 at 9:39 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

Of course I will maintain this module (as long as I have a mandate from OpenGeo to do so).

We just need short term commitment, if you decide to drop CAS support later
we can either search for another maintainer or drop the module back in community land.
Stuff in core is more complicated, as it’s officially maintained by the PSC.

The question is if we migrate the CAS module to an extension before 2.2.0 or afterward. Before 2.2.0 is less complicated but if this is not possible, I will disable the CAS configuration GUI.

Before if at all possible, this week we should try to release 2.2.0 final

Christian, i can help with this. This should be pretty straight forward since as originally written the security plugins were already designed to be extensions, and outside the core module.

@Christian: Let me know if you want to do this? Otherwise i will start the reshuffling probably tomorrow. Hoping for a release later this week.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.