Setting REMOTE_USER from proxy header

RT Users
1

I’m trying to set up rt-server to run within a podman (docker) container, proxied behind a web server that does the authentication. I have the web server setting a header (X-Proxy-Remote-User), but I have not yet figured out how to get rt-server to read this header and set REMOTE_USER so that I can use Set($WebRemoteUserAuth, '1').

I think I need to add this Plack Middleware: Plack::Middleware::SetEnvFromHeader - Set environment variables from the values of request headers - metacpan.org . However, I’m not sure how to hook this into rt-server. I tried

/opt/rt4/sbin/rt-server -e 'enable SetEnvFromHeader => REMOTE_USER => "X-Proxy-Remote-User"'

but this isn’t working for me.

Does anybody know how to add Plack middleware? Or, failing that, does anybody have a way to set the RT user based on a proxy header?

2

FYI this is probably not a good idea but I’m going down the road of overriding lib/RT/Interface/Web.pm’s WebCanonicalizeInfo function. Unfortunately because this function is explicitly specified (RT::Interface::Web::WebCanonicalizeInfo) it’s a bit tricky to override.

3

I ended up building this patch, which adds Plack::Middleware::SetEnvFromHeader. This will take the X-Proxy-Remote-User header and populate the REMOTE_USER variable. If there is a better way to do this, I’d love to know! This is for RT 4.4.6.

diff -ru lib2/RT/Interface/Web/Handler.pm lib/RT/Interface/Web/Handler.pm
--- lib2/RT/Interface/Web/Handler.pm	2023-07-06 21:15:04.990533320 +0000
+++ lib/RT/Interface/Web/Handler.pm	2023-07-06 22:56:12.877928155 +0000
@@ -352,6 +352,11 @@
         path => $path,
         headers => $headers,
     );
+
+    $builder->add_middleware(
+	    'Plack::Middleware::SetEnvFromHeader',
+             REMOTE_USER => 'X-Proxy-Remote-User',
+    );
     for my $root (RT::Interface::Web->StaticRoots) {
         $builder->add_middleware(
             'Plack::Middleware::Static',
4

Hey there, I got this working with a combination of haproxy and authelia.

haproxy sets the REMOTE_USER header so no changes are required in RT:

backend rt5
  http-request set-header REMOTE_USER %[var(req.auth_response_header.remote_user)] if remote_user_exist

Can you reconfigure your web server to set REMOTE_USER instead of X-Proxy-Remote-User ? I’ve found different backends expect different headers for the user identity so I need that kind of flexibility in the frontend proxy layer…

1 Like
5

Can you reconfigure your web server to set REMOTE_USER instead of X-Proxy-Remote-User ? I’ve found different backends expect different headers for the user identity so I need that kind of flexibility in the frontend proxy layer…

Yep, that’s actually what I started with. Right now (at least) I’m running rt-server directly as the container application, and then proxying requests to/from it via Apache httpd 2.4. I’m not super sure that’s a good idea, either. That said, when rt-server is running in standalone mode like this I don’t see any way to get it to pay attention to REMOTE_USER when passed as a header.

6

Ah that’s a good point, I put this together a while ago so you’ve jogged my memory :slight_smile:

I too got to WebCanonicalizeInfo which helped me solve it in my case. Finding the implementation in RT uses environments variables allowed me to determine the following Apache config was necessary in my configuration:

SetEnvIfNoCase Remote-User "(.*)" REMOTE_USER=$1

However, that won’t work in your configuration with Apache proxying requests to the rt-server directly.

Unless RT gains support for reading the user from a header directly, your patch looks like the best compromise for your configuration… Thanks for sharing though! There isn’t a lot written about fronting applications with authentication so putting more info out will be handy reference for others.

7

Gotcha; thank you! I think partly this is a question of container design. Should the container process be:

  • rt-server on its own?
  • Apache httpd 2.4 + rt-server?
  • nginx + rt-server?
  • some other Perl front-end + rt-server, a la Python’s gunicorn (I’m guessing this is what Plack is though, which is already part of rt-server)

I haven’t done much testing yet to see what other issues might crop up by running rt-server directly, but since it has a standalone mode I’m hoping it will work OK.