Is anyone successfully using $WebRemoteUserAuth in RT4 under Apache?

RT Users
1

Hi. I’m trying to set up RT 4.4.2 (installed from Ubuntu packages on Ubuntu 18.04, running under Apache using fcgid), and I can’t get WebRemoteUserAuth to work.

(This is probably a dumb question and quite possibly really about the Debian package or about fcgid rather than about RT configuration itself; my apologies.)

As I understand it, in RT4, setting

Set($WebRemoteUserAuth, 1);

in RT4 should cause RT to check the REMOTE_USER environment variable for the user Apache thinks we’re authenticated as. (In this case that has the form of an email address; the RT database has email addresses as usernames.) Running a dumb Perl CGI script (but not under fcgid!) to dump the environment shows me that REMOTE_USER is being set properly by Apache, but I still get an RT login form.

Interestingly, I still get the RT login form even if I unset WebFallbackToRTLogin, or set it to false or undef. This makes me wonder whether RT is actually reading my config properly (from /etc/request-tracker4/RT_SiteConfig.d). However, it was giving me cross-site scripting warnings until I set ReferrerWhitelist in the same directory, so some changes I make are being honored.

fcgid seems to be being called with RT_SITE_CONFIG set to /etc/request-tracker4/RT_SiteConfig.pm, which is empty except for comments saying RT now reads from files in /etc/request-tracker4/RT_SiteConfig.d . I’ve been dutifully editing files in /etc/request-tracker4/RT_SiteConfig.d, but I see no difference in behavior if I concatenate them all into /etc/request-tracker4/RT_SiteConfig.pm .

(As I understand it, $WebExternalAuth, which is what we used to get this behavior in RT3.8, is no longer relevant. However, I’ve tried setting that as well as WebRemoteUserAuth with no change in behavior and no errors.)

BTW, we’re using the Apache OIDC module to set REMOTE_USER; as mentioned, that part is working (at least with a regular non-fcgid CGI script).

Relevant snippets from /etc/request-tracker4/RT_SiteConfig.d/40-csail-defaults :

Set($WebRemoteUserAuth, 1);
Set($WebFallbackToRTLogin, 1);

(but I still get the login form without WebFallbackToRTLogin).

Relevant snippets from my RT vhost config in Apache:

...
OIDCRemoteUserClaim email
...
Include /etc/request-tracker4/apache2-fcgid.conf
<Location /rt>
  <RequireAll>
    Require valid-user
    Require ssl
    Require claim iss:https://oidc.csail.mit.edu/
  </RequireAll>
  AuthType openid-connect
</Location>

In case it matters, I also have another vhost configured which does not use OIDC (so should fall back to RT’s native authentication), with the idea that that way we can log in as root or another administrative user, or use the REST interface via the command-line rt tool with a password. But for testing purposes I’ve tried removing that vhost and I don’t see changed behavior.

I’m kind of fuzzy on how Apache passes environment variables to fcgid CGI scripts. But the fact that I still get the RT login form even with $WebFallbackToRTLogin unset suggests that there’s something more fundamental here that I’m missing.

(We don’t want to auto-create users; only RT admins will be able to log in this way, and they all already have accounts.)

Thanks for any advice anybody can give!

Jay

2

Just to make sure, after you change your config you restart Apache right?

3

Yes, I restart Apache. (And I can see that that kills the FastCGI process until another request is made.)

4

By way of experiment, I switched to mod_perl. That did not get REMOTE_USER working. (It did, however, prevent pages from loading properly; I’d randomly get some fraction of the page to load, generally minus any of the CSS.)

So I switched back to mod_fcgid, and pages are loading fully again, but REMOTE_USER is still being ignored (or perhaps not passed properly).

I’m not clear on how REMOTE_USER is supposed to be passed anyway, if you’re running under mod_fcgid or mod_perl, since the long-running process inherits its environment from Apache only on first load. But presumably there’s a protocol for passing stuff like that, because otherwise WebRemoteUserAuth (RT4)/WebExternalAuth (RT3) wouldn’t work for anybody, unless they were running RT as traditional short-lived CGI scripts. (Is there even a supported way to do that?)

I note also that the Debian/Ubuntu apache2-modperl2.conf and apache2-fcgid.conf explicitly set an initial environment variable RT_SITE_CONFIG to /etc/request-tracker4/RT_SiteConfig.pm – but do not mention /etc/request-tracker4/RT_SiteConfig.d, which is where the Debian maintainers tell you to put your configuration. Is that OK? (As noted above, I did try cat’ting my entire config into /etc/request-tracker4/RT_SiteConfig.pm with no change in behavior.)

5

I’m using $WebRemoteUserAuth with the Debian 10 package and fcgi, with mod_auth_openidc. In my Apache vhost config I have:

Include /etc/request-tracker4/apache2-fcgid.conf
OIDCRemoteUserClaim preferred_username

(and other oidc stuff). In /etc/request-tracker4/RT_SiteConfig.d/60-local.pm I have:

Set($WebRemoteUserAuth, 1);
Set($WebRemoteUserContinuous, 1);
Set($WebRemoteUserAutocreate, 0);
Set($WebFallbackToRTLogin, 0);

Your config looks ok so I’m not really sure why it doesn’t work for you.

6

Hi,

We’re using RT with OIDC as well. I’ve the following in my RT_SiteConfig.pm:

Set($WebExternalAuth , 1);
Set($WebFallbackToInternalAuth , 1);
Set($WebExternalAuto , 1);

Are you positive that the email attribute is included from your OIDC system? I’ve often seen that mappers/scope definitions are missing for the OIDC config.

7

Yes, I’m sure the email attribute is included correctly, because when I run a test (non-FCGI) perl script to dump the environment, REMOTE_USER (and OIDC_CLAIM_email and a bunch of other stuff) are correctly set. One of my colleagues has a theory that something about passing the environment variables to a FastCGI script might rename them, but it doesn’t look like that’s the case for you.

(Note that I’m not using $WebExternalAuth, but $WebRemoteUserAuth, like hmoffatt above. Having RT talk directly to OIDC itself would be fine, though, and arguably better. I’d be interested in seeing a working example of $WebExternalAuth with OIDC if it’s easy to show me sufficiently sanitised configs.)

8

Figured it out, and it was a really dumb mistake!

I edited the files in /etc/request-tracker4/RT_SiteConfig.d/ (like 51-dbconfig-common.pm) and put appropriate information in them.

Then I created a new file 40-csail with all our site-specific configuration like $WebRemoteUserAuth. See anything missing? The filename didn’t end in .pm. So RT was reading the other files but ignoring the one with the remote-authentication configuration in it.

I feel extremely dumb, but I have a working RT config now.

2 Likes
9

I can see there is a mixture of config parameters

#### 4.2.0 UPGRADE RENAMED SOME CONFIG PARAMS:
#    WebExternalAuth           => WebRemoteUserAuth
#    WebExternalAuthContinuous => WebRemoteUserContinuous
#    WebFallbackToInternalAuth => WebFallbackToRTLogin
#    WebExternalGecos          => WebRemoteUserGecos
#    WebExternalAuto           => WebRemoteUserAutocreate
#    AutoCreate                => UserAutocreateDefaultsOnLogin

hmoffatt - using 4.2.x or higher version
Jonathan_Petersson - using 3.8.x <> 4.2.x version
I am using 5.0.2 version with the newly renamed variables, but still cannot get it working
Other applications using php can receive env variable REMOTE_USER which is set via apache openidc module

Tried all the possible combinations by turning it on/off with them:

Set($WebRemoteUserAuth, 1);
Set($WebRemoteUserContinuous, 1);
Set($WebRemoteUserAutocreate, 1);
Set($WebFallbackToRTLogin, 1);
Set($UserAutocreateDefaultsOnLogin, { Privileged => 1 } );
Set($RestrictReferrer, 0);
Set(@ReferrerWhitelist, qw(*.domain.name:443 *.domain.name:80));

Set($WebFallbackToInternalAuth , 1); = shows login form
Set($WebFallbackToInternalAuth , 0); = shows Unauthorized, contact your rt admin…
either way both of them does nothing with REMOTE_USER, does not create new user … even logs in debug mode stays quiet…

any help?