[Geoserver-devel] New Community Module - JWT Headers (security)

Hi,

This is a request to create a new community module.

This is a fairly simple security module for header-based OAUTH2/OIDC type authentication - for example Apache mod_auth_openid and robot-base-access with JWT Access Tokens.

New functionality:

  1. Extract user name from a JSON header (including json path)
  2. Extract user name from an attached JWT token
  3. Extract Roles from JSON Header (including json path)
  4. Extract Roles from JWT Header (including json path)
  5. Role Translation from the external (IDP) names to internal GeoServer role names
  6. Access Token Validation;
  • signature validation
  • expiry validation
  • IDP external endpoint validation (including subject validation)
  • audience validation

Test coverage is about 90%.

I will create a PR when approved.

Code - https://github.com/davidblasby/geoserver/tree/_jwtheaders/src/community/jwt-headers

Doc - https://github.com/davidblasby/geoserver/tree/_jwtheaders/doc/en/user/source/community/jwt-headers

NOTE: I just put together the docs today - will be making them a bit “nicer” next week.

Some of the functionality is available in the very simple Headers security extension and the oauth2-* community modules. This module is much simpler, much more complete, and MUCH easier to maintain/test/configure.

In fact, if you want to use OIDC and are willing to put your geoserver behind apache (with mod_auth_openid), this module makes it MUCH MUCH easier to setup and maintain wrt the oauth2-* community modules. If you want to have GeoServer communicate DIRECTLY with your OIDC IDP, continue using the oauth2-* community modules.

NOTE: I am planning to add similar functionality to GeoNetwork.

Thanks,
Dave

+1 although I am your co-worker, others may have questions :slightly_smiling_face:

I know you are aware the transition to spring-framework 6 is planned; so the community module will need to be rewritten before becoming an extension; or did you just stick to spring-security core?

I would like to get your PR in promptly so the docs are picked up in mkdocs migration.

···


Jody Garnett

It doesn’t really depend on spring - just mostly via other GS classes like GeoServerPreAuthenticatedUserNameFilter. It uses a little spring to do some JWT-parsing/manipulation, so it would be easy to move to another library if the new spring doesn’t support it.

So, it shouldn’t be an issue to move to a later spring framework. The oauth2-* stuff will be a lot of work…

Dave

···


Jody Garnett

PR - https://github.com/geoserver/geoserver/pull/7440

···


Jody Garnett