|Version 6 (modified by heikki, 2 years ago)|
|Contact(s)||Heikki Doeleman & Jose Garcia|
|Status||Draft In Progress|
|Assigned to release||2.7|
|Resources||Nordic countries (Denmark, Finland, Norway and Sweden)|
Short description of the improvement proposal. ...
- 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 ...
- Email discussions:
- Other wiki discussions:
- Vote proposed by X on Y, result was +/-n (m non-voting members).
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).
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.
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.
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.
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.
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.
A UML component model to illustrate our proposal is this:
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.
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:
Because the Users and Groups DBMS tables are moved to GAAP, their information is part of the SecurityToken; where currently GeoNetwork has numerous places where it consults the DBMS to look up the current user's groups, these lookups are modified to use the SecurityToken instead. SecurityTokens are kept in an application-scope map, with session-id as the key to look them up. If the user does not log in, the SecurityToken is an anonymous SecurityToken.
The delegation is handled by a Servlet Filter, GeoNetwork Security Filter. This filter intercepts all requests to GeoNetwork, checks if the current session id is known in the SecurityToken Map and if not, it forwards the request to GAAP. GAAP returns a SecurityToken that is added to the Map, so subsequent requests from the same client (as long as the session is valid) do not need to consult GAAP again. After this, GeoNetwork Security Filter lets the request continue normally to its destination (one of the GeoNetwork services).
A more detailed UML Sequence diagram showing GeoNetwork delegating to GAAP is this:
Backwards Compatibility Issues
New libraries added
Explain which and why new libraries are required for that proposal ...
- List of participants and role (if necessary) in current GIP
(32.7 KB) - added by heikki
2 years ago.
(31.7 KB) - added by heikki
2 years ago.
Security Filter activity diagram
(38.7 KB) - added by heikki
2 years ago.
Security Filter sequence diagram
(46.3 KB) - added by heikki
2 years ago.
Login sequence diagram
(15.6 KB) - added by heikki
2 years ago.
Logout sequence diagram
(84.0 KB) - added by heikki
2 years ago.
Spring Security AuthenticationService? activity diagram
(38.4 KB) - added by heikki
2 years ago.
SAML Authentication activity diagram