[Geoserver-devel] Security interactions between web console and OGC services

GeoServer GeoServer Developer
1

Hi,
recently I was thinking about what the following sentence should mean: “OGC services are supposed to be stateless”.

In my opinion, from the security point of view, it means that OGC services should completely ignore an eventual security context saved into the user session by other Geoserver requests (for example those created by logging into the web UI).

Currently this is not true, due to the fact that we always have a GeoServerSecurityContextPersistenceFilter in the filter chains, also for the OGC services (default) chain.
The only difference is that the default chain does not create a new session, if it does not exist yet, but it uses an existing one. When I say it uses the session I do not only mean that it reads security info from the session, but it also saves a new one if specified on the request.

I think we should add one more option to the chains to configure the possibility to completely ignore the session for OGC services, in addition to the existing “do not create HTTPSession” option.

Any opinion? Does this make any sense?

Thanks
Mauro

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer

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

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

2

On Fri, Jul 25, 2014 at 11:37 AM, Mauro Bartolomeoli <
mauro.bartolomeoli@anonymised.com> wrote:

Hi,
recently I was thinking about what the following sentence should mean:
"OGC services are supposed to be stateless".

In my opinion, from the security point of view, it means that OGC services
should completely ignore an eventual security context saved into the user
session by other Geoserver requests (for example those created by logging
into the web UI).

Personally I find it rather handy to have the web gui login work for
subsequent OGC requests from the same browser too.

But I agree there should be a way to avoid that in case the admin wants to

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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 1660272
mob: +39 339 8844549

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

-------------------------------------------------------

3

On Fri, Jul 25, 2014 at 3:37 AM, Mauro Bartolomeoli <
mauro.bartolomeoli@anonymised.com> wrote:

Hi,
recently I was thinking about what the following sentence should mean:
"OGC services are supposed to be stateless".

In my opinion, from the security point of view, it means that OGC services
should completely ignore an eventual security context saved into the user
session by other Geoserver requests (for example those created by logging
into the web UI).

Currently this is not true, due to the fact that we always have
a GeoServerSecurityContextPersistenceFilter in the filter chains, also for
the OGC services (default) chain.
The only difference is that the default chain does not create a new
session, if it does not exist yet, but it uses an existing one. When I say
it uses the session I do not only mean that it reads security info from the
session, but it also saves a new one if specified on the request.

Not sure I understand you here. My understanding was that for the default

chain the session integration will never create a new session, only
integrate with an existing one. Am I wrong about that?

I think we should add one more option to the chains to configure the
possibility to completely ignore the session for OGC services, in addition
to the existing "do not create HTTPSession" option.

Agreed. But I would call the option "Session Integration", as it is

referred to by spring security.

Any opinion? Does this make any sense?

Thanks
Mauro

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer

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

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

-------------------------------------------------------

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
VP Engineering | Boundless <http://boundlessgeo.com/&gt;
jdeolive@anonymised.com
@boundlessgeo <http://twitter.com/boundlessgeo/&gt;

4

Hi Justin,

···

2014-07-25 16:28 GMT+02:00 Justin Deoliveira <jdeolive@anonymised.com3839…>:

I’ll try to explain with an example:

  1. the user loads the web console as anonymous user: this creates a new session (the session is created before authentication happens, if current chain is enabled to), but doesn’t fill it with security info, because the user is not authenticated
  2. the user sends a WFS GetFeature request using basic authentication headers: the session is there, created by the previous request and now is filled with authentication from basic auth
  3. the user refreshes the web console and now he is logged in automatically as the user from previous WFS GetFeature basic auth (note that if it was already logged in as admin, for example, now it could be loggedin as a different user)

Sounds good. Thank you.

Mauro

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer

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

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

On Fri, Jul 25, 2014 at 3:37 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:

Hi,
recently I was thinking about what the following sentence should mean: “OGC services are supposed to be stateless”.

In my opinion, from the security point of view, it means that OGC services should completely ignore an eventual security context saved into the user session by other Geoserver requests (for example those created by logging into the web UI).

Currently this is not true, due to the fact that we always have a GeoServerSecurityContextPersistenceFilter in the filter chains, also for the OGC services (default) chain.
The only difference is that the default chain does not create a new session, if it does not exist yet, but it uses an existing one. When I say it uses the session I do not only mean that it reads security info from the session, but it also saves a new one if specified on the request.

Not sure I understand you here. My understanding was that for the default chain the session integration will never create a new session, only integrate with an existing one. Am I wrong about that?

I think we should add one more option to the chains to configure the possibility to completely ignore the session for OGC services, in addition to the existing “do not create HTTPSession” option.

Agreed. But I would call the option “Session Integration”, as it is referred to by spring security.