Proposal title

Date	2010/12/15
Contact(s)	​Heikki Doeleman & ​Jose Garcia
Last edited	2010/12/15
Status	Draft In Progress
Assigned to release	2.7
Resources	Nordic countries (Denmark, Finland, Norway and Sweden)

Overview

Short description of the improvement proposal. ...

Proposal Type

• Type: GUI Change, Core Change, Module Change, Guideline and project governance procedures, ...
• App: GeoNetwork or !Intermap
• Module: eg. Harvester, Kernel, Data Manager, Metadata Import, Lucene Index, Search Interface ...

Links

• Documents:
• Email discussions:
• Other wiki discussions:

Voting History

• Vote proposed by X on Y, result was +/-n (m non-voting members).

---

Motivations

This document describes the architecture we propose to enable and enhance the use of various security providers with GeoNetwork opensource. We will give an overview of the current way of dealing with security in GeoNetwork 2.x and GeoNetwork 3.x, after which we will present this proposal in more detail.

This proposal entails the use of ​Spring Security, a well-known framework that supports the use of one or several security providers. It also entails the introduction of a dedicated GN security component (GAAP), which is already in use in GeoNetwork 3.x, into GeoNetwork 2.x.

current situation in GeoNetwork 2.x

This section describes the implementation of authentication and authorization in the current releases of GeoNetwork 2.x (as also in trunk).

Users and Groups

GeoNetwork maintains DBMS tables for Users and Groups. A User is an entity that can log in, log out, has a Profile (this is best understood as a Role), and is part of one or more Groups. Access to metadata is restricted by Profile and Group. The Group privileges to access a metadata are stored in a DBMS table and also in the Lucene index. In the code these access privileges are overridden by checking on Profile (esp. Users with Profile "Administrator" are permitted access to all metadata). The metadata access is further specified in access types (View, Edit, and a few other ones).

LDAP

It is possible to configure an external LDAP security provider. In this case, after a successful login, the User information obtained from LDAP is temporarily inserted into the GeoNetwork Users DBMS table. When the session ends (upon logout or expiration) they remain in the database. It is not possible to configure more than one LDAP provider.

current situation in GeoNetwork 3.x

This section describes the implementation of authentication and authorization in the current branch of GeoNetwork 3.x.

In GeoNetwork 3.x the picture is slightly changed because of the introduction of a new, separate Web application, GeoNetwork CSW/ebRIM. This application restricts access to its ebRIM metadata based on the privileges for the ISO19139 metadata (in "Legacy" GeoNetwork) that the ebRIM metadata was created for. In order to separate concerns an extra new Web application was introduced, GAAP (GeoNetwork Authentication & Authorization Application).

The GeoNetwork Users and Groups DBMS tables, as well as the metadata privileges table in GeoNetwork 3.x are moved to GAAP. GeoNetwork CSW/ebRIM consults GAAP to control access to its ebRIM metadata. Legacy GeoNetwork consults GAAP to control access to its metadata.

outline of proposed changes

This section summarizes our proposed changes. The changes are intended to:

• allow for the use of more than one authentication provider, simultaneously
• add support for ​SAML-based authentication (Single-Sign On)
• allow for the use of other types of external security providers
• improve on the implementation when using GeoNetwork Authentication and/or one or more external security providers
• improve performance as compared to the current GeoNetwork 3.x code
• The proposal involves the introduction of GAAP in GeoNetwork 2.x and modifications to the working of GAAP and Legacy GeoNetwork.

Proposal

basic architecture

security token map

GeoNetwork maintains an in-memory map of security tokens, SecurityTokenMap. This map associates a session id with a security token. The token contains all information GeoNetwork uses to allow access to its resources: the User Profile and list of Groups the User is part of. When determining access rights, the metadata privileges as stored in the DBMS and Lucene (depending on type of access -- Lucene is used for free text searches) are compared to the Groups found in the security token in the current session.

security servlet filter

A servlet filter intercepts all requests to GeoNetwork and verifies whether the current session id is present in SecurityTokenMap. If it is, nothing special happens and the request continues to its destination service in GeoNetwork. If the session id is not in SecurityTokenMap, the filter requests GAAP for an anonymous security token. The session id is mapped to this anonymous token and stored in SecurityTokenMap.

logging in

When a User is logging in, the login form is requested from GAAP. GAAP uses Spring Security to access one or more security providers. If the credentials provided in the login form can be matched against one of them, a security token is created that contains all required information, the User's name (and possibly other info like contact details), Profile, and list of Groups. This security token is returned to GeoNetwork that adds or updates the entry for the current session in SecurityTokenMap. When the User logs out or the session expires the corresponding entry is removed from SecurityTokenMap.

logged in

When a User is logged in and accessing some resource where authorization is involved, SecurityTokenMap is consulted to match this User's privileges to the permissions set for the resource. As an example when a (text) search is done, the privileges stored in Lucene for each document matching the text search are compared to the Groups in SecurityTokenMap to decide whether to include a text search result in the result set returned to the client.

administration

Users with Profile "Administrator" are authorized to manage Groups, Users, and configure external (e.g. LDAP) security providers. The actual DBMS and web pages enabling this currently reside in GeoNetwork, but in our proposed architecture this belongs in GAAP. So we'll move the administration of users and groups, and also the configuration of security providers, to GAAP.

The security provider configuration data is stored in a SecurityProvider DBMS table and dynamically applied to the Spring Security configuration. Security providers may be marked as ACTIVE or INACTIVE by the Administrator. When performing an authorization, GAAP's Spring Security will only consult the security providers marked as ACTIVE.

component model

A UML component model to illustrate our proposal is this:

GeoNetwork application

This section discusses the changes to the GeoNetwork application.

GeoNetwork uses session to maintain state about the privileges of the current user. This remains exactly the same in this proposal.

authentication

The main difference lies in how the authentication is performed. In this proposal GeoNetwork delegates authentication to GAAP; the result of this authentication is a SecurityToken returned by GAAP and associated to the current session.

A UML Activity diagram giving a high-level view of GeoNetwork delegating to GAAP is this:

Backwards Compatibility Issues

New libraries added

Explain which and why new libraries are required for that proposal ...

Risks

Participants

• List of participants and role (if necessary) in current GIP