Apache authentication, then RT authentication?

Found something odd … I re-configured RT and Apache so that
$WebExternalAuth was set and created a local password file for Apache to
use. Restarted Apache etc.

This is what happens:

  1. Open http://…/rt2/ and receive popup browser password prompt as
    expected;

  2. On entering username/password correctly, I get dumped at the RT login
    screen - asking for username and password as it used to before I enable
    $WebExternalAuth. (RT works normally once entering after entering this
    username/password BTW)

Why does (2) happen? Doesn’t the use of $WebExternalAuth negate the
need for the RT login and password? I edited the code in
WebRT/html/Elements/Header to show the value of REMOTE_USER and it is
definitely set to the right value. What’s gone wrong?

I am using version 2.0.11 which has been tweaked a little, but not in
any way that I would have thought would cause the above behaviour.

Any hints?

Dave.

Dave Ewart
Dave.Ewart@cancer.org.uk
Computing Manager, Epidemiology Unit, Oxford
Cancer Research UK
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370

  1. Open http://…/rt2/ and receive popup browser password prompt as
    expected;

  2. On entering username/password correctly, I get dumped at the RT login
    screen - asking for username and password as it used to before I enable
    $WebExternalAuth. (RT works normally once entering after entering this
    username/password BTW)

I have this same problem as well, with a fresh/otherwise unmodified build of
2.0.14, with mod_auth_pam 1.1.1 compiled statically into Apache 1.3.26.
Authenticate once fine, then get the RT login screen. Of course, in this
case, the RT login requires the local/RT password – it doesn’t end up
passing it off to PAM (which works for other similarly protected webspace on
this server).

Ideas, anyone? Perhaps I’m setting $WebExternalAuth improperly (couldn’t
find any relevent documentation or useful examples in mailing list archives).

Gretchen K. Wagner
gkwagner@cats.ucsc.edu

Ideas, anyone? Perhaps I’m setting $WebExternalAuth improperly (couldn’t
find any relevent documentation or useful examples in mailing list archives).

After toying about with the WebExternalAuth setting (pointing it to differing
PAM libraries), I now get passed/logged directly into RT, but then I get “You
are not an authorized user” for any function, and “logout” is now missing.

FWIW, here’s some relevent config detail from apache:

Alias /rt2 "/rt/RT2/WebRT/html"
PerlRequire /rt/RT2/bin/webmux.pl
<Location /rt2>
    AuthType Basic
    AuthName "Kerberos authentication for RT2"
    require valid-user
    SetHandler perl-script
    PerlHandler RT::Mason
</Location>

Gretchen K. Wagner
gkwagner@cats.ucsc.edu

Gretchen K. Wagner wrote:

After toying about with the WebExternalAuth setting (pointing it to differing
PAM libraries), I now get passed/logged directly into RT, but then I get “You
are not an authorized user” for any function, and “logout” is now missing.

The missing “logout” is, I believe normal, as authentication
is now not RT’s responsibility.

As for “not an authorized user”, my reading of the code suggests
that this means it couldn’t find the user in the RT database.

You’ll still need to create your users as per usual; WebExternalAuth
only provides authentication, not authorisation.

(Disclaimer: I don’t use WebExternalAuth. I could be speaking crap.)
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

Ideas, anyone? Perhaps I’m setting $WebExternalAuth improperly
(couldn’t find any relevent documentation or useful examples in
mailing list archives).

After toying about with the WebExternalAuth setting (pointing it to
differing PAM libraries), I now get passed/logged directly into RT,
but then I get “You are not an authorized user” for any function, and
"logout" is now missing.

Why are you “pointing it to PAM libraries” etc.? I thought the idea was
that if WebExternalAuth is defined (i.e. ANYTHING other than ‘undef’)
then the RT environment will use the value of REMOTE_USER as its
authenticated user. The actual value of $WebExternalAuth is ignored,
as far as I can tell. The code in WebRT/html/autohandler would seem to
support this.

What I don’t understand is why the browser authentication is not also
logging me into RT!

Anyone shed any more light on this?

Dave.
Dave Ewart
Dave.Ewart@cancer.org.uk
Computing Manager, Epidemiology Unit, Oxford
Cancer Research UK
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370

As for “not an authorized user”, my reading of the code suggests
that this means it couldn’t find the user in the RT database.

FWIW, all of the user accounts are defined in RT. When attempting to log in,
it appears that authentication is successful, as each testing user arrives at
the RT start page with "Signed in as ", but when clicking on
Search or Configuration, then the error "You are not an authorized user"
appears.

Gretchen K. Wagner
gkwagner@cats.ucsc.edu

Ideas, anyone? Perhaps I’m setting $WebExternalAuth improperly
(couldn’t find any relevent documentation or useful examples in
mailing list archives).

After toying about with the WebExternalAuth setting (pointing it to
differing PAM libraries), I now get passed/logged directly into RT,
but then I get “You are not an authorized user” for any function, and
"logout" is now missing.

Why are you “pointing it to PAM libraries” etc.? I thought the idea was
that if WebExternalAuth is defined (i.e. ANYTHING other than ‘undef’)
then the RT environment will use the value of REMOTE_USER as its
authenticated user. The actual value of $WebExternalAuth is ignored,
as far as I can tell. The code in WebRT/html/autohandler would seem to
support this.

The following is based on my experience with older versions of RT, and the
assumption that RT hasn’t changed significantly in this regard in newer
versions. Standard disclaimers also apply:

The point is that the session must get past the browser’s authentication
mechanism first in order to proceed. This then keeps out all
unauthenticated users whether they are authorized or not (or, to put it more
prosaically, if a person claiming to be johndoe can’t demonstrate that s/he
is johndoe, it doesn’t matter if johndoe is authorized or not, the
claimant isn’t getting in).

Access is granted through PAM in the following general way: remote user
requests introductory page from .htaccess-protected directory; apache requests
authentication credentials (username password) from remote user to satisfy
.htaccess restrictions and then passes these off to PAM via mod_auth_pam;
PAM in turn uses one of many different types of authentication modules (we
use kerberos, as it appears UCSC is also trying to use). Once PAM, and
therefor the web server, is satisfied with the credetials, the user can then
proceed to call any links in the .htaccess protected directory.

(Apologies if this belabors the point. Corrections, as always, welcome.)

I can confirm the earlier report that RT needs the username configured
locally in RT to match that authenticating to the web server (ie, my
kerberos principal is “deejoe” and my RT account is also named “deejoe”).

The sticking point here might be that, at least with the versions of RT I’ve
used, a local password must also be configured for the account. This may
have something to do with a restriction against empty passwords, but that’s
only a guess.

The local password need never actually be used, but it does need set.

If you have local passwords set for the accounts in question, then I’m all
out of problem-solving ideas at the moment.

Another caveat: Cookies are used for RT’s built-in authentication. When
external authentication is configured, no cookies are generated. Therefore
it effectively becomes impossible to log out without closing the browser
session and wiping the cache since http basic authentication can never be
canceled or expired otherwise. This behavior (no cookies from RT) may have
changed with more recent RT versions, I don’t know.

What I don’t understand is why the browser authentication is not also
logging me into RT!

–Joe

(Apologies if this belabors the point. Corrections, as always, welcome.)

Quite excellent summary of Things As They Are with regards to this situation
:slight_smile: FWIW, yes, all accounts are configured, all accounts have passwords, and
I’ve tried various combinations of same/different passwords for the
krb/unix/rt accounts (all same username).

Another caveat: Cookies are used for RT’s built-in authentication. When
external authentication is configured, no cookies are generated. Therefore
it effectively becomes impossible to log out without closing the browser
session and wiping the cache since http basic authentication can never be
canceled or expired otherwise. This behavior (no cookies from RT) may have
changed with more recent RT versions, I don’t know.

I think this may be the sticking point. RT2 appears to accept the external
authentication, but it doesn’t proceed beyond that initial page. Perhaps RT2
still wants cookies, but they’re not being generated as part of the Apache
basic auth. Hrm…

Gretchen K. Wagner gkwagner@cats.ucsc.edu
Unix Systems Administrator
Distributed Computing Group
Communications and Technology Services
University of California Santa Cruz

(Apologies if this belabors the point. Corrections, as always, welcome.)

Quite excellent summary of Things As They Are with regards to this situation
:slight_smile: FWIW, yes, all accounts are configured, all accounts have passwords, and
I’ve tried various combinations of same/different passwords for the
krb/unix/rt accounts (all same username).

Another caveat: Cookies are used for RT’s built-in authentication. When
external authentication is configured, no cookies are generated. Therefore
it effectively becomes impossible to log out without closing the browser
session and wiping the cache since http basic authentication can never be
canceled or expired otherwise. This behavior (no cookies from RT) may have
changed with more recent RT versions, I don’t know.

I think this may be the sticking point. RT2 appears to accept the external
authentication, but it doesn’t proceed beyond that initial page. Perhaps RT2
still wants cookies, but they’re not being generated as part of the Apache
basic auth. Hrm…

Am wondering if anyone ever solved this problem. I’m still running v1 RT
installation. Now that I’ve migrated it to new hardware twice, I’m finally
feeling like I might be up to upgrading to RT2 at some point.

Hearing that the problem described above has been solved would be further
encouragement towards that.

Regards,

–Joe

(Apologies if this belabors the point. Corrections, as always, welcome.)

Quite excellent summary of Things As They Are with regards to this situation
:slight_smile: FWIW, yes, all accounts are configured, all accounts have passwords, and
I’ve tried various combinations of same/different passwords for the
krb/unix/rt accounts (all same username).

Another caveat: Cookies are used for RT’s built-in authentication. When
external authentication is configured, no cookies are generated. Therefore
it effectively becomes impossible to log out without closing the browser
session and wiping the cache since http basic authentication can never be
canceled or expired otherwise. This behavior (no cookies from RT) may have
changed with more recent RT versions, I don’t know.

I think this may be the sticking point. RT2 appears to accept the external
authentication, but it doesn’t proceed beyond that initial page. Perhaps RT2
still wants cookies, but they’re not being generated as part of the Apache
basic auth. Hrm…

Am wondering if anyone ever solved this problem. I’m still running v1 RT
installation. Now that I’ve migrated it to new hardware twice, I’m finally
feeling like I might be up to upgrading to RT2 at some point.

Hearing that the problem described above has been solved would be further
encouragement towards that.

I must say that I don’t really understand the problem. I am using
external authentication with rt2. My config.pm is located at
/usr/local/rt2/etc/config.pm and has the following as the first line:

$Header: /usr/local/rt2/etc/RCS/config.pm,v 1.2 2002/09/20 17:54:52

root Exp root $

My apache is configured to authenticate our users via our shadow files,
under https. After we do this, we are logged in to rt without any
further ado. I hate to say this, but for us, after we set up RT to
accept the username from the apache server as authoritative, it “just
worked”.

rob

I’ve been following this thread as well, trying to get a clear
understanding of the problem. I am running RT 2.0.13 authenticating
against apache using a Samba authentication, and have had no problems
with it (since getting apache to work with Samba, at least!).

Is the problem that you can’t log out?

One thing is that the user needs to exist in RT to get in. seph
(thanks!) has a snappy script that worked in our environment with few
modifications that will autoadd users when the authenticate through
apache…
http://lists.fsck.com/pipermail/rt-devel/2002-May/002357.html

if the user doesn’t exist in RT you’ll just see the first page with no
authentication mechanism, and won’t get any further.

rickOn Sun, 24 Nov 2002, Rob Walker wrote:

On Thu, 2002-11-14 at 12:49, deejoe@iastate.edu wrote:

On Tue, Aug 13, 2002 at 12:10:27PM -0700, Gretchen K. Wagner wrote:

On Mon, 12 Aug 2002 deejoe@iastate.edu wrote:

(Apologies if this belabors the point. Corrections, as always, welcome.)

Quite excellent summary of Things As They Are with regards to this situation
:slight_smile: FWIW, yes, all accounts are configured, all accounts have passwords, and
I’ve tried various combinations of same/different passwords for the
krb/unix/rt accounts (all same username).

Another caveat: Cookies are used for RT’s built-in authentication. When
external authentication is configured, no cookies are generated. Therefore
it effectively becomes impossible to log out without closing the browser
session and wiping the cache since http basic authentication can never be
canceled or expired otherwise. This behavior (no cookies from RT) may have
changed with more recent RT versions, I don’t know.

I think this may be the sticking point. RT2 appears to accept the external
authentication, but it doesn’t proceed beyond that initial page. Perhaps RT2
still wants cookies, but they’re not being generated as part of the Apache
basic auth. Hrm…

Am wondering if anyone ever solved this problem. I’m still running v1 RT
installation. Now that I’ve migrated it to new hardware twice, I’m finally
feeling like I might be up to upgrading to RT2 at some point.

Hearing that the problem described above has been solved would be further
encouragement towards that.

I must say that I don’t really understand the problem. I am using
external authentication with rt2. My config.pm is located at
/usr/local/rt2/etc/config.pm and has the following as the first line:

$Header: /usr/local/rt2/etc/RCS/config.pm,v 1.2 2002/09/20 17:54:52

root Exp root $

My apache is configured to authenticate our users via our shadow files,
under https. After we do this, we are logged in to rt without any
further ado. I hate to say this, but for us, after we set up RT to
accept the username from the apache server as authoritative, it “just
worked”.

rob


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Rick Rezinas 503-889-7091
Unix Systems Administrator
Qsent, Inc.

When Gladstone was British Prime Minister he visited Michael Faraday’s
laboratory and asked if some esoteric substance called `Electricity’
would ever have practical significance.
“One day, sir, you will tax it,” was the answer.
– Science, 1994