smithj4 at bnl
Sep 24, 2009, 11:48 AM
Post #1 of 1
(709 views)
Permalink
|
|
ExternalAuth fallback to InternalAuth behavior.
|
|
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 |
| 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
