So, I turn my attention to markup and layer editing. Authentication and authorization must precede this. In my searches, I found this summary document from CamptoCamp from FOSS4G
2011 2010, with some great schema on the different options. The basic breakdown as I read it is this: there are two categories of protection: integrated authentication, such as the GeoServer Security Subsystem, and proxied authentication, such as 52˚ North WSS, SecureOWS, or GeoShield. The proxied systems can be further subdivided into systems which create an https tunnel with separate client and server software to provide a decoding localhost to prevent packet sniffing (i.e. SecureOWS), a web security service (WSS) service layer (i.e. 52˚ North WSS), and GeoShield– which can either act as a proxy or a (soon to be released) plugin for GeoServer’s existing subsystem (if I understand things correctly– which by things I mean this document from FOSS4G 2011, as I missed the presentation itself).
The nice part for SecureOWS, as I see it, is that it creates a tunneled connection, so if you’re interested in preventing sniffing, man-in-the-middle attacks, etc., the extra complication of running a localhost decoder for SecureOWS might be worth it. It’s a minor complication, but it is not as simple as HTTP BASIC authentication, which is what e.g. the GeoServer security sub-system does. SecureOWS also should work with any client software that can access OWS services. What I like about GeoShield is the ability to use Common Query Language (CQL) (and hopefully ECQL) to constrain almost every bit of behavior, from the extent returned, to the styles available, etc. etc., all that using a language construct common to GeoServer users, in addition to service level stuff like GetFeatureInfo, etc.. And finally, it seems that
52˚ North WSS (or WSS setups in general) are meant to handle end to end security, including encryption. I don’t know if this level of complexity constrains potential client software, but it seems like it could. This point might be moot, if the objective is to use a modern browser as the client, but could matter with legacy desktop applications (I’m now into the territory of suppositions and guesses, so please correct me if I’m wrong). That said
52˚ North WSS also has fine control over geographic extent, service level, layers, etc., much as GeoShield.
What’s my conclusion? I wish I knew. I’m going to have to do some yak shaving tests. GeoShield passed initial tests. It seems, so far, to be easy to set up and maintain, and the Ext “Desktop” look and feel is downright cute. GeoServer’s subsystem can authenticate against other services, such as LDAP, so I’ll be playing with that too. We’ll see how far I get from there, and whether I test the encrypted options (SecureOWS and 52˚ North WSS) to ensure end-to-end security as well.
4 thoughts on “OGC Web Services and Security”
I just would like to let you know that another mean of securing OGC webservices layers (WMS, WFS, CSW, WMTS) exists with the OS project EasySDI PROXY (http://www.easysdi.org / http://forge.easysdi.org/projects/proxy/wiki) with HTTP Basic authentification. You can define filters per users on layers, attributes, methods… It also have others features such as WMS aggregation, XML rewriting, XSL transformation, and have logs of requests (for statistics purpose for examaple).
Any feedback would be appreciated 🙂
Beyond proxying/authentication, the list of specs is impressive as far as enhancing and building out an SDI. Thanks Xavier. I will definitely be looking into this.
(Not that I use it) but any plans of implementing SOS as a secured service in addition to WMS, WFS, CSW, and WMTS?
No, no plan so far to implement SOS.
There were some idea with TJS (http://www.opengeospatial.org/standards/tjs) but no real work done until now.