Hi all,
I need some opinions about how to integrate the CAS authentication point. Let us assume GeoServer OGC services are protected by a CAS authentication filter. There are 2 types of clients
- A user sitting in front of a browser
- A remote software doing proxy authentication
If the unauthenticated client sends a ticket, everything works fine. Example
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
But how to react if there is no ticket (and no authenticated HTTP Session) ?. Example
http://mygeoserver/geoserver/wms?request=getCapabilities
The current implementation returns an HTTP 401 (Unauthorized). This is fine for clients like 2), but this is not nice for clients as described in 1)
The standard procedure for CAS works as follows:
- Geoserver redirects the request to the cas server ( HTTP 307 ) with the following URL
https://mycasserver/login?service=http://mygeoserver/geoserver/wms?request=getCapabilities
- A login form is presented and on successful login, the CAS server redirects the client to the original URL (including a ticket parameter)
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
- Geoserver validates the ticket and gets the user name from the CAS server
This standard procedure is nice for clients described in 1), but unlucky for clients described in 2).
Possible Solution:
The normal entry point should be the CAS standard procedure, a client like 2) may include an additional parameter
noredirect=true. If the parameter is present, Geoserver send back a 401. I think this is not a big challenge, since the developer of the proxy app has to add the ticket parameter anyways. Adding an additional parameter is not such an effort.
Opinions ?
Hey Christian,
I think i agree with your assessment and i like having the browser be the typical case and making a bit more work for the proxy application developer. However can you illuminate why the standard procedure is not desirable for the proxy application? Is it because the proxy application should handle the redirect itself? And no the geoserver auth filter?
On Fri, Oct 5, 2012 at 8:29 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
Hi all,
I need some opinions about how to integrate the CAS authentication point. Let us assume GeoServer OGC services are protected by a CAS authentication filter. There are 2 types of clients
- A user sitting in front of a browser
- A remote software doing proxy authentication
If the unauthenticated client sends a ticket, everything works fine. Example
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
But how to react if there is no ticket (and no authenticated HTTP Session) ?. Example
http://mygeoserver/geoserver/wms?request=getCapabilities
The current implementation returns an HTTP 401 (Unauthorized). This is fine for clients like 2), but this is not nice for clients as described in 1)
The standard procedure for CAS works as follows:
- Geoserver redirects the request to the cas server ( HTTP 307 ) with the following URL
https://mycasserver/login?service=http://mygeoserver/geoserver/wms?request=getCapabilities
- A login form is presented and on successful login, the CAS server redirects the client to the original URL (including a ticket parameter)
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
- Geoserver validates the ticket and gets the user name from the CAS server
This standard procedure is nice for clients described in 1), but unlucky for clients described in 2).
Possible Solution:
The normal entry point should be the CAS standard procedure, a client like 2) may include an additional parameter
noredirect=true. If the parameter is present, Geoserver send back a 401. I think this is not a big challenge, since the developer of the proxy app has to add the ticket parameter anyways. Adding an additional parameter is not such an effort.
Opinions ?
Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
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.
Hi Justin
Exactly, the proxy application causes a redirect sent back from Geoserver on authentication failure/unauthenticated request. Out of the box, a Java url follows the redirect request and and the proxy receives an HTTP 200 and a login form from the CAS server (depends on the authentication mechanism configured on the CAS server). This is quite nasty, I know this from the CAS online test.
Getting back an HTTP respone “Access Denied” is easier to handle. What is a better solution, adding an url parameter or a request header attribute causing the geoserver cas filter to send back an “Access Denied”.
Christian
2012/10/12 Justin Deoliveira <jdeolive@anonymised.com>
Hey Christian,
I think i agree with your assessment and i like having the browser be the typical case and making a bit more work for the proxy application developer. However can you illuminate why the standard procedure is not desirable for the proxy application? Is it because the proxy application should handle the redirect itself? And no the geoserver auth filter?
On Fri, Oct 5, 2012 at 8:29 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
Hi all,
I need some opinions about how to integrate the CAS authentication point. Let us assume GeoServer OGC services are protected by a CAS authentication filter. There are 2 types of clients
- A user sitting in front of a browser
- A remote software doing proxy authentication
If the unauthenticated client sends a ticket, everything works fine. Example
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
But how to react if there is no ticket (and no authenticated HTTP Session) ?. Example
http://mygeoserver/geoserver/wms?request=getCapabilities
The current implementation returns an HTTP 401 (Unauthorized). This is fine for clients like 2), but this is not nice for clients as described in 1)
The standard procedure for CAS works as follows:
- Geoserver redirects the request to the cas server ( HTTP 307 ) with the following URL
https://mycasserver/login?service=http://mygeoserver/geoserver/wms?request=getCapabilities
- A login form is presented and on successful login, the CAS server redirects the client to the original URL (including a ticket parameter)
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
- Geoserver validates the ticket and gets the user name from the CAS server
This standard procedure is nice for clients described in 1), but unlucky for clients described in 2).
Possible Solution:
The normal entry point should be the CAS standard procedure, a client like 2) may include an additional parameter
noredirect=true. If the parameter is present, Geoserver send back a 401. I think this is not a big challenge, since the developer of the proxy app has to add the ticket parameter anyways. Adding an additional parameter is not such an effort.
Opinions ?
Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
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.
On Mon, Oct 15, 2012 at 7:42 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
Hi Justin
Exactly, the proxy application causes a redirect sent back from Geoserver on authentication failure/unauthenticated request. Out of the box, a Java url follows the redirect request and and the proxy receives an HTTP 200 and a login form from the CAS server (depends on the authentication mechanism configured on the CAS server). This is quite nasty, I know this from the CAS online test.
Getting back an HTTP respone “Access Denied” is easier to handle. What is a better solution, adding an url parameter or a request header attribute causing the geoserver cas filter to send back an “Access Denied”.
Hmmm… no strong preference. I would think perhaps a header attribute would be more correct from a pure HTTP standpoint.
Christian
2012/10/12 Justin Deoliveira <jdeolive@anonymised.com1…>
Hey Christian,
I think i agree with your assessment and i like having the browser be the typical case and making a bit more work for the proxy application developer. However can you illuminate why the standard procedure is not desirable for the proxy application? Is it because the proxy application should handle the redirect itself? And no the geoserver auth filter?
On Fri, Oct 5, 2012 at 8:29 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
Hi all,
I need some opinions about how to integrate the CAS authentication point. Let us assume GeoServer OGC services are protected by a CAS authentication filter. There are 2 types of clients
- A user sitting in front of a browser
- A remote software doing proxy authentication
If the unauthenticated client sends a ticket, everything works fine. Example
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
But how to react if there is no ticket (and no authenticated HTTP Session) ?. Example
http://mygeoserver/geoserver/wms?request=getCapabilities
The current implementation returns an HTTP 401 (Unauthorized). This is fine for clients like 2), but this is not nice for clients as described in 1)
The standard procedure for CAS works as follows:
- Geoserver redirects the request to the cas server ( HTTP 307 ) with the following URL
https://mycasserver/login?service=http://mygeoserver/geoserver/wms?request=getCapabilities
- A login form is presented and on successful login, the CAS server redirects the client to the original URL (including a ticket parameter)
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
- Geoserver validates the ticket and gets the user name from the CAS server
This standard procedure is nice for clients described in 1), but unlucky for clients described in 2).
Possible Solution:
The normal entry point should be the CAS standard procedure, a client like 2) may include an additional parameter
noredirect=true. If the parameter is present, Geoserver send back a 401. I think this is not a big challenge, since the developer of the proxy app has to add the ticket parameter anyways. Adding an additional parameter is not such an effort.
Opinions ?
Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
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.
Perhaps I will offer both possibilities but I am preferring the header attribute too.
Christian
2012/10/16 Justin Deoliveira <jdeolive@anonymised.com>
On Mon, Oct 15, 2012 at 7:42 AM, Christian Mueller <mcrmcr21@anonymised.com403…> wrote:
Hi Justin
Exactly, the proxy application causes a redirect sent back from Geoserver on authentication failure/unauthenticated request. Out of the box, a Java url follows the redirect request and and the proxy receives an HTTP 200 and a login form from the CAS server (depends on the authentication mechanism configured on the CAS server). This is quite nasty, I know this from the CAS online test.
Getting back an HTTP respone “Access Denied” is easier to handle. What is a better solution, adding an url parameter or a request header attribute causing the geoserver cas filter to send back an “Access Denied”.
Hmmm… no strong preference. I would think perhaps a header attribute would be more correct from a pure HTTP standpoint.
Christian
2012/10/12 Justin Deoliveira <jdeolive@anonymised.com>
Hey Christian,
I think i agree with your assessment and i like having the browser be the typical case and making a bit more work for the proxy application developer. However can you illuminate why the standard procedure is not desirable for the proxy application? Is it because the proxy application should handle the redirect itself? And no the geoserver auth filter?
On Fri, Oct 5, 2012 at 8:29 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
Hi all,
I need some opinions about how to integrate the CAS authentication point. Let us assume GeoServer OGC services are protected by a CAS authentication filter. There are 2 types of clients
- A user sitting in front of a browser
- A remote software doing proxy authentication
If the unauthenticated client sends a ticket, everything works fine. Example
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
But how to react if there is no ticket (and no authenticated HTTP Session) ?. Example
http://mygeoserver/geoserver/wms?request=getCapabilities
The current implementation returns an HTTP 401 (Unauthorized). This is fine for clients like 2), but this is not nice for clients as described in 1)
The standard procedure for CAS works as follows:
- Geoserver redirects the request to the cas server ( HTTP 307 ) with the following URL
https://mycasserver/login?service=http://mygeoserver/geoserver/wms?request=getCapabilities
- A login form is presented and on successful login, the CAS server redirects the client to the original URL (including a ticket parameter)
http://mygeoserver/geoserver/wms?request=getCapabilities&ticket=ST_abdgkalgsd
- Geoserver validates the ticket and gets the user name from the CAS server
This standard procedure is nice for clients described in 1), but unlucky for clients described in 2).
Possible Solution:
The normal entry point should be the CAS standard procedure, a client like 2) may include an additional parameter
noredirect=true. If the parameter is present, Geoserver send back a 401. I think this is not a big challenge, since the developer of the proxy app has to add the ticket parameter anyways. Adding an additional parameter is not such an effort.
Opinions ?
Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
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.