Error during GeoServer bootstrapping (InsufficientAuthenticationException)

Description

GeoServer does not load settings of a protected workspace when using Catalog Mode == Mixed

Steps to reproduce:

  • Add a role "testrole"

  • Add a workspace "testworkspace"

Add the following data access rules:

testworkspace.*.r
testworkspace.*.w

and assign these rules to the role "testrole"

Restart GeoServer and have a look at the log file. There is a stack trace caused by

org.springframework.security.authentication.InsufficientAuthenticationException

As a consequence, GeoServer does not load the workspace settings for "testworkspace" and falls back to the default values. Unfortunately there is no indicator on the admin GUI that something went wrong.

A debug session shows that GeoServer uses the SecureCatalog implementation during bootstrapping. During this phase is the current user is null (treated as anonymous).

Ideas/questions:

1) Is it possible to use the non secure implementation of the catalog during bootstrapping
2) If not, does it make sense to boostrap as "admin" or even better as "root" user.

Environment

None

Activity

Show:
Andrea Aime
March 21, 2018, 8:27 AM

Using the non secured catalog might work, there is the issue of not opening up paths for privilege escalation attacks though, as the REST API in general can be used by non full admins. The bootstrap as admin might seem a better idea, if you can ensure the authentication only lasts during the startup, and it's not involved in any other operation (e.g, catalog reload later, for example).

Christian Mueller
March 21, 2018, 8:46 AM
Edited

Would something like this be an acceptable solution
(Sorry about the former attempts, trying to learn Jira formatting....)

Andrea Aime
March 22, 2018, 6:52 PM

It seems like it would work, yes, isBootstrapping would be true only once no?

Christian Mueller
March 23, 2018, 4:08 AM

Yep, isBootstrapping is true only once.

Can you give me an hint where to look for the start of the the bootstrap sequence.

Thanks

Andrea Aime
March 23, 2018, 9:34 AM

That is controlled by Spring, which instantiates beans the order it prefers (following dependencies of course). I'd suggest to put a breakpoint in the place where it breaks now and see.

Assignee

Unassigned

Reporter

Christian Mueller

Triage

None

Fix versions

None

Affects versions

Components

Priority

High
Configure