Dynamic Geoserver nodes for geopublication

Date	2014-02-05	Contacts	Landry Breuil
Status	Brainstorming	Release	2.12/3.0?
Resources	Available (planned for february/march)	Ticket #	Not yet
Source code	landryb/core-geonetwork/feature/geopublish-by-org
Funding	Needed & developped by CRAIG

Overview

The existing Geoserver/Geopublication integration is a bit static, and doesnt allow for a lot of flexibility. If new users (in the case of a 'large' SDI) register, they need to be able right away to publish geospatial data in geoserver, but in dedicated workspaces where only a subset of users can write and read. As of now, one needs to manually create workspaces, groups and ACLs for the new users before they are able to use them.

The idea is to rely on LDAP groups to tell geonetwork to:

create workspaces on the fly via REST for a given user being part of a given group
modify ACLs in security/layers.properties to allow given users to access the workspace, and given users to write/administrate the geoserver workspace to be able to add styles/data. (yes, that assumes that geonetwork and geoserver share a directory, for geonetwork to be able to write to geoserver's datadir)
reload ACLs via REST POST on /reload

My usecase:

user a is in ldap group ORG_FOO
user b is in ldap group ORG_BAR and ACCESS_ORG_FOO_BAZ
user a needs to have write access to geoserver workspace foo_public (which is freely readable) and foo_members (which is limited to ROLE_AUTHENTICATED within geoserver)
user b needs to have write access to geoserver workspace bar_public (which is freely readable) and bar_members (which is limited to ROLE_AUTHENTICATED within geoserver)

As a user, when opening the geopublishing widget, geonetwork fetches the list of available workspaces via GET /workspaces, and filters out the workspaces where the user can write (proposed convention: if user belongs to ldap group ORG_FOO, then he has write access to all workspaces which start by 'foo')

Specialcase: Admin wants to allow user b to have read access to some data published by user a Admin manually creates a workspace named foo_baz, and adds the geoserver ACL to allow ROLE_ACCESS_ORG_FOO_BAZ to read foo_baz. As a direct consequence, user a can automatically write to it (since geonetwork shows it in the list of available workspaces) and user b can read from it.

As an administrator profile, you have write access to any workspace.

Technical Details:

Geonetwork needs to update on the fly geoserver-nodes.xml to account for newly created remote nodes.

The proposal is either to keep it static (as it is now, to avoid changing behaviour for users of geopublisher) or allow for a 'node template' giving:

an admin/password couple allowed to create templates
the base URL for the global REST accesspoint
the base url for services provided by workspaces on that server
the list of 'children' workspaces to create for a given org/user
the path to security/layers.properties in geoserver's datadir

The other parameters (namespacePrefix, namespaceUrl, id, name..) for existing nodes would be populated from the given workspaces to create on the fly.

<nodetemplate>
<adminUrl>http://localhost:9080/geoserver/rest</adminUrl>
<wxsUrlBase>http://public.geoserver.fqdn/geoserver</wxsUrlBase>
<stylerUrl>http://public.geoserver.fqdn/geoserver/www/styler/</stylerUrl>
<user>admin</user>
<password>admin</password>
<children>public</children>
<children>members</children>
<aclpath>/var/lib/tomcat/webapps/geoserver/data/security/layers.properties</aclpath>
</nodetemplate>

Geonetwork also needs to access a specific branch of ldap groups (which might not be the same branch as groups/profiles) so the proposal is to extend spring's config-security-ldap.xml and config-security.properties with a bunch of stanzas like:

ldap.privilege.search.geoserver.attribute=cn
ldap.privilege.search.geoserver.object=ou=groups
ldap.privilege.search.geoserver.query=(&(objectClass=*)(memberUid={0})(cn=ORG_*))
ldap.privilege.search.geoserver.pattern=ORG_(.*)

This way, geonetwork would know that the user logging in is in ORG_FOO, and if the given user accesses the geopublisher, it'll create FOO_public and FOO_members.