During testing CAS authentication for OGC services I see a stack trace in the log because of creating an HTTP session not in the /geoserver/web/** path. So far so good.
There are 2 possibilities for CAS ticket authentication for stateless requests like http://localhost:8080/geoserver/wms?request=getCapabilities
-
The client requests a service/proxy ticket from the CAS server for the service
http://localhost:8080/geoserver/wms?request=getCapabilities
and Geoserver validates the ticket using the CAS server. After validation, Geoserver knows the user name. The ticket can be validated only once. (This is the standard CAS configuration). In this scenario, TWO additional HTTP requests to the CAS server are necessary for EACH stateless Geoserver request. This is quite a performance penalty.
-
As an alternative, the GeoServer CAS configuration has the option to for creating an HTTP Session. In this scenario, only the first request has the performance penalty, subsequent requests can use the session cookie.
Caching the CAS tickets is no option since it may happen that different users receive an identical ticket over the time.
At the end of the day, the GeoServer admin has to decide between these two options. Looking at SessionDebugFilter.java and web.xml, I see no easy way to avoid the stack trace in such situations.
Any ideas ?
Christian
I would say given that we now have more advanced authentication , and hence session management options I think SessionDebugFilter probably needs to get a little smarter, and be able to filter out situations like this.
It might make sense to not hardcode it in web.xml but instead wire it in via spring. Given that its really more of a developer tool anyways i don’t see this as too much burden. That would make it more accessible to other beans in the spring container for configuring it. For instance, perhaps we need to add a set of url patterns to it that form the allowable set of urls from a session can be created from.
Just some ideas.
On Sun, Sep 16, 2012 at 7:10 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
During testing CAS authentication for OGC services I see a stack trace in the log because of creating an HTTP session not in the /geoserver/web/** path. So far so good.
There are 2 possibilities for CAS ticket authentication for stateless requests like http://localhost:8080/geoserver/wms?request=getCapabilities
-
The client requests a service/proxy ticket from the CAS server for the service
http://localhost:8080/geoserver/wms?request=getCapabilities
and Geoserver validates the ticket using the CAS server. After validation, Geoserver knows the user name. The ticket can be validated only once. (This is the standard CAS configuration). In this scenario, TWO additional HTTP requests to the CAS server are necessary for EACH stateless Geoserver request. This is quite a performance penalty.
-
As an alternative, the GeoServer CAS configuration has the option to for creating an HTTP Session. In this scenario, only the first request has the performance penalty, subsequent requests can use the session cookie.
Caching the CAS tickets is no option since it may happen that different users receive an identical ticket over the time.
At the end of the day, the GeoServer admin has to decide between these two options. Looking at SessionDebugFilter.java and web.xml, I see no easy way to avoid the stack trace in such situations.
Any ideas ?
Christian
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.
On Mon, Sep 17, 2012 at 4:40 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
I would say given that we now have more advanced authentication , and hence session management options I think SessionDebugFilter probably needs to get a little smarter, and be able to filter out situations like this.
Agreed
Cheers
Andrea
–
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
I think it always depends on the concrete deployment and I fear many single sign on solutions will have this problem. Having the CAS server deployed in the internet may cause a performance penalty. The counter example is a zSeries Host running a lot of Linux virtual machines using hyper sockets (bypassing the TCP/IP stack and using shared memory).
Should I open a JIRA issue ?
2012/9/17 Andrea Aime <andrea.aime@anonymised.com>
On Mon, Sep 17, 2012 at 4:40 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
I would say given that we now have more advanced authentication , and hence session management options I think SessionDebugFilter probably needs to get a little smarter, and be able to filter out situations like this.
Agreed
Cheers
Andrea
–
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
On Wed, Sep 19, 2012 at 10:07 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
I think it always depends on the concrete deployment and I fear many single sign on solutions will have this problem. Having the CAS server deployed in the internet may cause a performance penalty. The counter example is a zSeries Host running a lot of Linux virtual machines using hyper sockets (bypassing the TCP/IP stack and using shared memory).
Should I open a JIRA issue ?
Yes please.
A short term fix could be to have the session debug filter be controlled via a system variable, and basically shut it down
if a certain flag is used
Cheers
Andrea
–
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