Patch to allow alternate REMOTE_USER variable for WebExternalAuth

RT Developers
1

We are are testing WebAuth with RT and for it to work with
WebExternalAuth, I needed to have RT look for a variable name different
than the default REMOTE_USER. Since Apache reserves REMOTE_USER for its
own purposes, WebAuth cannot use that variable. So, we have our WebAuth
server set a different variable which contains the user’s login name.
The attached patch adds an additional config variable and changes the
WebCanonicalizeInfo function to return the value of that variable, if
specified, or the default REMOTE_USER if not set.

I tested this with our WebAuth server and rt-3.8.5.

~Jason

/------------------------------------------------------------------
| Jason A. Smith Email: smithj4@bnl.gov |
| Atlas Computing Facility, Bldg. 510M Phone: +1-631-344-4226 |
| Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 |
| Upton, NY 11973-5000, U.S.A. |
------------------------------------------------------------------/

rt-3.8.5-webauth-remote-user.patch (1.7 KB)

smime.p7s (3.81 KB)

2

It’s our intent that sites override WebCanonicalizeInfo locally (to do
something like what you have done). Because of that, I’m not sure it
makes a lot of sense to clutter that sub with options.On Thu, Sep 24, 2009 at 03:08:09PM -0400, Jason A. Smith wrote:

We are are testing WebAuth with RT and for it to work with
WebExternalAuth, I needed to have RT look for a variable name different
than the default REMOTE_USER. Since Apache reserves REMOTE_USER for its
own purposes, WebAuth cannot use that variable. So, we have our WebAuth
server set a different variable which contains the user’s login name.
The attached patch adds an additional config variable and changes the
WebCanonicalizeInfo function to return the value of that variable, if
specified, or the default REMOTE_USER if not set.

I tested this with our WebAuth server and rt-3.8.5.

~Jason

–
/------------------------------------------------------------------
| Jason A. Smith Email: smithj4@bnl.gov |
| Atlas Computing Facility, Bldg. 510M Phone: +1-631-344-4226 |
| Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 |
| Upton, NY 11973-5000, U.S.A. |
------------------------------------------------------------------/

diff -urN rt-3.8.5-dist/etc/RT_Config.pm rt-3.8.5/etc/RT_Config.pm
— rt-3.8.5-dist/etc/RT_Config.pm 2009-09-14 13:57:24.000000000 -0400
+++ rt-3.8.5/etc/RT_Config.pm 2009-09-22 10:17:12.000000000 -0400
@@ -975,6 +975,15 @@

Set($WebExternalAuth, undef);

+=item C<$WebExternalAuthVarName>
+
+If C<$WebExternalAuthVarName> is defined, RT will use that environment
+variable instead of the default REMOTE_USER.
+
+=cut
+
+Set($WebExternalAuthVarName, undef);
+
=item C<$WebFallbackToInternalAuth>

If C<$WebFallbackToInternalAuth> is defined, the user is allowed a chance
diff -urN rt-3.8.5-dist/etc/RT_Config.pm.in rt-3.8.5/etc/RT_Config.pm.in
— rt-3.8.5-dist/etc/RT_Config.pm.in 2009-09-14 13:23:22.000000000 -0400
+++ rt-3.8.5/etc/RT_Config.pm.in 2009-09-22 10:22:08.000000000 -0400
@@ -975,6 +975,15 @@

Set($WebExternalAuth, undef);

+=item C<$WebExternalAuthVarName>
+
+If C<$WebExternalAuthVarName> is defined, RT will use that environment
+variable instead of the default REMOTE_USER.
+
+=cut
+
+Set($WebExternalAuthVarName, undef);
+
=item C<$WebFallbackToInternalAuth>

If C<$WebFallbackToInternalAuth> is defined, the user is allowed a chance
diff -urN rt-3.8.5-dist/lib/RT/Interface/Web.pm rt-3.8.5/lib/RT/Interface/Web.pm
— rt-3.8.5-dist/lib/RT/Interface/Web.pm 2009-09-14 13:23:22.000000000 -0400
+++ rt-3.8.5/lib/RT/Interface/Web.pm 2009-09-22 14:29:28.000000000 -0400
@@ -123,7 +123,8 @@
=cut

sub WebCanonicalizeInfo {

  • return $ENV{‘REMOTE_USER’}? lc $ENV{‘REMOTE_USER’}: $ENV{‘REMOTE_USER’};
  • my $var = $RT::WebExternalAuthVarName ? $RT::WebExternalAuthVarName : ‘REMOTE_USER’;
  • return $ENV{$var}? lc $ENV{$var}: $ENV{$var};
    }

}}}

List info: The rt-devel Archives

3

It’s our intent that sites override WebCanonicalizeInfo locally (to do
something like what you have done). Because of that, I’m not sure it
makes a lot of sense to clutter that sub with options.

Hi Jesse,

Ok, I understand, although it is much easier for a sysadmin to modify a
config setting than create their own Mason file to override an internal
RT function. Also, consider the fact that single sign-on systems
outside of apache (which therefore can’t use REMOTE_USER) are becoming
more popular, maybe it would be worth it to add an additional config
option. There may be more people in the future who encounter the same
problem I did when trying to put RT behind their local SSO, and wonder
how to get RT to read the username. Either way, I now know how to fix
it for us now.

Thanks,
~Jason> On Thu, Sep 24, 2009 at 03:08:09PM -0400, Jason A. Smith wrote:

We are are testing WebAuth with RT and for it to work with
WebExternalAuth, I needed to have RT look for a variable name different
than the default REMOTE_USER. Since Apache reserves REMOTE_USER for its
own purposes, WebAuth cannot use that variable. So, we have our WebAuth
server set a different variable which contains the user’s login name.
The attached patch adds an additional config variable and changes the
WebCanonicalizeInfo function to return the value of that variable, if
specified, or the default REMOTE_USER if not set.

I tested this with our WebAuth server and rt-3.8.5.

~Jason

/------------------------------------------------------------------
| Jason A. Smith Email: smithj4@bnl.gov |
| Atlas Computing Facility, Bldg. 510M Phone: +1-631-344-4226 |
| Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 |
| Upton, NY 11973-5000, U.S.A. |
------------------------------------------------------------------/

smime.p7s (3.81 KB)

4

It’s our intent that sites override WebCanonicalizeInfo locally (to do
something like what you have done). Because of that, I’m not sure it
makes a lot of sense to clutter that sub with options.

Hi Jesse,

Ok, I understand, although it is much easier for a sysadmin to modify a
config setting than create their own Mason file to override an internal
RT function.

Right, but the range of what users want here turns out to end up at
“write a local-specific subroutine” far more often than, say, the code
you propose. There’s just too wide a variation in how these systems
work.

That said, you can do this entirely from the config file.

in RT_SiteConfig;

use RT::Interface::Web;
{ no warnings ‘redefine’;
sub RT::Interface::Web::CanonicalizeUserInfo {
my $self = shift;
# do some stuff

}
}

5

Right, but the range of what users want here turns out to end up at
“write a local-specific subroutine” far more often than, say, the code
you propose. There’s just too wide a variation in how these systems
work.

That said, you can do this entirely from the config file.

in RT_SiteConfig;

use RT::Interface::Web;
{ no warnings ‘redefine’;
sub RT::Interface::Web::CanonicalizeUserInfo {
my $self = shift;

do some stuff

}
}

Hi Jesse,

Thanks for the suggestion, I hadn’t thought of doing it that way, I will
try it out. Did you see my other email about “ExternalAuth fallback to
InternalAuth behavior”? If I understand the code correctly, it looks
like when WebExternalAuth is enabled, the existing $session data is
always ignored and reloaded from scratch for every RT access. In
addition there are a few redundant calls to create the session object in
rt-3.8.5/share/html/autohandler:

$session{‘CurrentUser’} = RT::CurrentUser->new;

~Jason

/------------------------------------------------------------------
| Jason A. Smith Email: smithj4@bnl.gov |
| Atlas Computing Facility, Bldg. 510M Phone: +1-631-344-4226 |
| Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 |
| Upton, NY 11973-5000, U.S.A. |
------------------------------------------------------------------/

smime.p7s (3.81 KB)

6

try it out. Did you see my other email about “ExternalAuth fallback to
InternalAuth behavior”? If I understand the code correctly, it looks
like when WebExternalAuth is enabled, the existing $session data is
always ignored and reloaded from scratch for every RT access. In
addition there are a few redundant calls to create the session object in
rt-3.8.5/share/html/autohandler:

$session{‘CurrentUser’} = RT::CurrentUser->new;

That’s going to be the user in the session, not the session itself.