[2.26.x] DDF-6636 adds support for proxied request audit logging

[jlcsmith]

What does this PR do?

https://github.com/codice/ddf/pull/6637 added more extensive support for audit logging of client information. However, it didn't take into account the scenario where a proxy sits in front of DDF. In this setup, the "client" information logged is that of the proxy rather than the actual client. This PR adds support for the X-FORWARDED-* HTTP headers which are typically set by a proxy to pass the actual client information.

Who is reviewing it?

@glenhein @derekwilhelm

Select relevant component teams:

@codice/security

How should this be tested?

Setup

Build and install the standard profile add the UI features (this requires updating ddf-ui to point to this SNAPSHOT version of DDF and building that branch) enable web sockets in the Catalog UI config

Test non-proxied requests

Sanity check that normal, non-proxied requests (searches, downloads, etc) still create audit log entries with the client IP and Port. Client IP should be 127.0.0.1 since you are running this locally.

Test proxied HTTPS requests

Using postman (or a similar tool), send a request to DDF with the following HTTP headers set: x-forwarded-for = <some non local IP address> x-forwarded-port = <a port address>

Verify that the audit logs for the request use the IP/port in the "forwarded" headers rather than your localhost address

Test proxied websocket requests

Using postman (or a similar tool), create a websocket request to wss://localhost:8993/search/catalog/ws with the following additional headers specified: Authorization: <basic auth value> Cookie: <you need to copy the jsession ID from an Intrigue session using the network tools. Ask me for details> Host: localhost:8993 Origin: https://localhost:8993 x-forwarded-for = <some non local IP address> x-forwarded-port = <a port address>

Verify that the audit logs for the request use the IP/port in the "forwarded" headers rather than your localhost address

Any background context you want to provide?

What are the relevant tickets?

Fixes: #6636

Screenshots

Checklist:

• [ ] Documentation Updated
• [ ] Update / Add Threat Dragon models
• [ ] Update / Add Unit Tests
• [ ] Update / Add Integration Tests

Notes on Review Process

Please see Notes on Review Process for further guidance on requirements for merging and abbreviated reviews.

Review Comment Legend:

• ✏️ (Pencil) This comment is a nitpick or style suggestion, no action required for approval. This comment should provide a suggestion either as an in line code snippet or a gist.
• ❓ (Question Mark) This comment is to gain a clearer understanding of design or code choices, clarification is required but action may not be necessary for approval.
• ❗ (Exclamation Mark) This comment is critical and requires clarification or action before approval.

[jlcsmith]

build now

[cxddfbot]

Internal build has been started, your results will be available at build completion.

[cxddfbot]

Build FAILURE See the job results in legacy Jenkins UI or in Blue Ocean UI.

[cxddfbot]

Internal build has been started, your results will be available at build completion.

[cxddfbot]

Build SUCCESS See the job results in legacy Jenkins UI or in Blue Ocean UI.

[cxddfbot]

Internal build has been started, your results will be available at build completion.

[cxddfbot]

Build SUCCESS See the job results in legacy Jenkins UI or in Blue Ocean UI.

[derekwilhelm]

🎉 Hero Successful 🎉 Attempted the normal setup first using both websockets and without to verify that the client IP and port were being logged as before. Then, I added the x-forwarded-for and x-forwarded-port headers and verified that the provided values were logged instead for both websockets and normal requests.