[Rt-devel] ExternalAuth fallback to InternalAuth behavior.

[Jason A. Smith]

I am setting up a new RT server to replace our old one during a later
upgrade and was thinking of taking this opportunity to integrate our
existing WebAuth system into it.  The problem is that our RT user DB is
already populated with hundreds of existing users, most of which have
their RT login names set to an email address, not the same as their
WebAuth login names.  So, I was planning on trying to use the fallback
to internal auth during a transitional period, until everyone gets
either their login names changed (or we could use the GECOS field) to
their WebAuth name.

The problem is, that once they have authenticated with WebAuth, the
remote user name is present, and the auth code then tries to load a
valid user.  For the initial access to RT, it works as expected and they
are presented with the internal login page since their name is not
found.  The problem is that every following page access to RT, they are
again presented with the internal login page.  I think this happens
because every time the remote user info is present, the session data is
immediately over-written when RT attempts to load the user data, but
since the remote user name does not match the internal name, this fails
of course, but now since the previous session info has been deleted,
they are asked to login again.  Basically this part of the code does not
care about the value of the WebFallbackToInternalAuth config setting.
That config variable is only used if the external auth remote user name
is missing.

If I understand the code correctly, I may be able to come up with a
patch, but I am not sure if this is the way internal auth fallback would
be expected to work by others.

Also, while looking at the Auth code in rt-3.8.5/share/html/autohandler
to see how it works, I noticed an unnecessary duplicate line, see #157 &
#165 below (I didn't include a patch since I don't know which one you
would prefer to keep):


151     # do we actually have a REMOTE_USER equivlent?
152     if ( RT::Interface::Web::WebCanonicalizeInfo() ) {
153 
154         my $orig_user = $user;
155 
156         $user = RT::Interface::Web::WebCanonicalizeInfo();
157         $session{'CurrentUser'} = RT::CurrentUser->new();
158         my $load_method = RT->Config->Get('WebExternalGecos') ? 'LoadByGecos' : 'Load';
159 
160         if ( $^O eq 'MSWin32' and RT->Config->Get('WebExternalGecos') ) {
161             my $NodeName = Win32::NodeName();
162             $user =~ s/^\Q$NodeName\E\\//i;
163         }
164 
165         $session{'CurrentUser'} = RT::CurrentUser->new();
166         $session{'CurrentUser'}->$load_method($user);
167 
168         if ( RT->Config->Get('WebExternalAuto') && !$session{'CurrentUser'}->Id ) {


Both of those also just recreate the session object that is also created
in line #137, if it doesn't exist to begin with.  This is really the
cause of my problem since it looks like, whenever WebExternalAuth is
used, the CurrentUser session object is created and reloaded from
scratch, regardless of its previous state.

~Jason


-- 
/------------------------------------------------------------------\
|  Jason A. Smith                          Email:  smithj4 at 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.                                   |
\------------------------------------------------------------------/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3906 bytes
Desc: not available
Url : http://lists.bestpractical.com/pipermail/rt-devel/attachments/20090924/f140eb6b/attachment.bin