GSIP 82

GSIP 82 - Reworking security filter chains

Overview

Reworking  security filter chains.

Proposed By

[Christian Mueller]

Assigned to Release

2.3.0

State

Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred

Motivation

The current security filter chains are implemented using one class called RequestFilterChain. Unfortunately there are some different types of such chains, namely

1. Constant chains  (/jspringsecurity_check)
2. Logout chain (/jspringsecurity_logout)
3. Login chain for the GUI  (/web/)
4. Login chains for services (/wms)

It is cumbersome to add validation code and the admin GUI allows to put each filter on each chain which is not reasonable at all.

The new design should be prepared for adding Single Sign Out extensions like CAS.

Proposal

The single class RequestFilterChains is replaced by a class hierarchy.  The following properties are added:

• allow session creation (boolean flag)
• GeoserverRoleFilter name (filter returning the roles of an authenticated principal in an HTTP response attribute)
• disable security for a chain

An active authentication filter implementing the Spring LogoutHandler interface is called during the GeoServer log out process. The log out filter chain itself is a constant chain.

GUI enhancements:

Included is a bug fix for the filter chain configuration on the GUI. If the user changes the configuration and switches to another chain (combo box), all modifications are lost.

• Add check box for “allow session creation”
• Add combo box for selecting a GeoserverRoleFilter
• Add check box for “disabling security”
• Remove constant filter chains and the log out filter chains from the “select chain” combo box.
• Only present filters which are appropriate for the type of the chain (e. g. no form login filter for stateless services).

The patch is here and was reviewed by Justin.

For a proof of concept, the CAS security extensions was completely rewritten to test proper integration. The current CAS implementation does not work well and it is not recommended to use it in production systems. The new implementation works better but is not yet finished.

During this proof of concept some improvements in the core code have happened. (e. g. avoid caching an authentication token if the system knows that an HTTP session will be created and the token will be stored in this session).

Feedback

This section should contain feedback provided by PSC members who may have a problem with the proposal.

Backwards Compatibility

A migration (security directory) from 2.2.x is necessary since

1. There are some additional configuration options
2. The filter chain types know about their mandatory filters and these filters have to be removed from the variable part of the filter list.

Voting

Andrea Aime: Alessio Fabiani: Ben Caradoc Davies: [Christian Mueller]: +1 Gabriel Roldan: Justin Deoliveira: Jody Garnett: Mark Leslie: Rob Atkinson: Simone Giannecchini:

Links

JIRA Task Email Discussion Wiki Page