Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Add support for pre-authorization via HTTP header (to be used with pre-authentication)

Description

Background

When the OpenNMS web UI is set up behind a reverse proxy such as Apache HTTPD or NGINX, the authentication and authorization of users can be farmed out to some AAA module. In these scenarios, the OpenNMS webapp trusts the username and role(s) conveyed in a pair of custom HTTP headers. Docs exist for configuring this functionality, but they are pretty bare-bones.

 

Problem

  1. The header configured for userHeader is honored, but the header configured for credentialsHeader is ignored.

  2. The docs do not mention that, if the user enables this feature, a value must be provided for credentialsHeader.

 

Steps to Reproduce

  1. Start with a fresh install

  2. Edit $OPENNMS_HOME/jetty-webapps/opennms/WEB-INF/spring-security.d/header-preauth.xml as follows:

    1. Change the value of the enabled property to true

    2. Set the value of the credentialsHeader property to X-Remote-Roles

  3. Restart OpenNMS

  4. Run curl -H 'X-Remote-User: admin' -H 'X-Remote-Roles: ROLE_ADMIN' http://127.0.0.1:8980/opennms/rest/info and see that the info endpoint's output appears – pre-authentication worked

  5. Run curl -H 'X-Remote-User: ulf' -H 'X-Remote-Roles: ROLE_ADMIN' http://127.0.0.1:8980/opennms/rest/info

 

Expected Result

Output of the info endpoint appears as it did for the admin user

 

Actual Result

Request is rejected with code 401 Full authentication is required

 

 

Further Notes

The admin user works just fine because the ROLE_ADMIN assignment for that built-in user is coming from users.xml.

Jesse thought the filter code might be returning a principal rather than a role assignment. I might be off the mark in recollecting his exact words here, my Spring Security knowledge is lacking.

Acceptance / Success Criteria

  • Role(s) correctly passed through from the header named in the credentialsHeader property for users that do not exist in users.xml

  • Docs updated to reflect that credentialsHeader must have a value configured – probably should add a default one in both the docs and the shipping config file.

  • Docs specify how to pass multiple roles in the credentialsHeader header – does comma-separated work?

Lucidchart Diagrams

Activity

Show:

Alex May April 21, 2023 at 3:54 PM

Any thoughts on the comment above? Default behavior and what kind of pre-auth we support seems like more of a product question.

Alex May April 5, 2023 at 4:38 PM

While looking into I ran into a few discrepancies with how pre-authentication is implemented and configured versus how it is described here.

  1. Roles aren’t configured via the credentialsHeader, it all seems to be done through the authenticationHeader. I can’t seem to find any use for the credentialsHeader beyond it needing to be set to something if it is configured.

  2. The default configuration only allows for authentication against users in users.xml, and existing roles cannot be overridden with either authenticationHeader or credentialsHeader.

  3. With the configuration given in the documentation, all roles need to be specified in the authenticationHeader. userHeader is never compared against users.xml.

In the linked issue, Chris suggested changing the default config to match what is given in the documentation. I’m fine with doing that, but then we’d kind of ‘lose’ the ability to authenticate against existing users unless we put the current default somewhere in the docs. I don’t know if this would be a problem.

A few questions:

  1. Is the behavior I’m seeing intended?

  2. Does credentialsHeader have any use? I can’t figure out what Spring expects this method to return, or how it is used.

  3. Should the default configuration be changed to what’s in the documentation?

Alberto June 8, 2022 at 2:49 PM

merged to foundation-2020

Alberto June 6, 2022 at 12:31 PM
Edited

Backporting to foundation-2020 PR: https://github.com/OpenNMS/opennms/pull/4826

Jeff Gehlbach June 2, 2022 at 8:01 PM

Reopening since we've had a support customer inquire about back-porting this work to Meridian.

I'm naming Meridian 2022, but if it's just as easy to go back to 2020, we should do that.

Done

Details

Assignee

Reporter

Docs Needed

Yes

Story Points

Components

Sprint

Fix versions

Affects versions

Priority

PagerDuty

Created March 8, 2022 at 11:58 PM
Updated April 21, 2023 at 3:54 PM
Resolved June 8, 2022 at 2:49 PM