On Sun, Sep 16, 2012 at 3:48 PM, Christian Mueller <[email protected]>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.
>
> 2) 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
