166794 - Add support for authentication by webserver using, among others, netegrity single-signon

Status: RESOLVED WORKSFORME

(Bugzilla :: Administration, task, P4)

Description

[Joel Peshkin]

Add support for Bugzaill CGIs to accept a variable from the webserver indicating
the userid (email) of the logged-in user.  This should be compatible with
webserver authentication as well as add-ins such as netegrity.

Comment 1

[Dave Miller [:justdave]]

I'm pretty sure this is a dupe, but I can't find the original right now.  I know
this has been discussed at length in another bug somewhere...

Comment 2

[Dave Miller [:justdave]]

OK, found it.  not a dupe.  The bug it originally got discussed in was
mentioning several different ways to get around the "changing IP breaks your
login" problems, and that was suggested as one of the solutions.

The relevant discussion is in bug 20122 comment 16 through bug 20122 comment 36.

Comment 3

[Bradley Baetz (:bbaetz)]

I'm wondering if the easiest way to do this is via a mod_perl module. Under
apache 2.latest, we can register as an auth provider (athough I don't know if
those hooka are available from perl), and just get asked to validate the
password, leavnig the http stuff to apache. This has the advantage that we get
digestauth for free[1], against the disadvatage of only working with apache.

This isn't dependant on making bugzilla work under mod_perl (except the dbi
stuff); its a separate handler

We can do the auth stuff with apache1, but then we can only do basic auth unless
we reimplement the digest stuff ourself, in which case we may as well not do it
via mod_perl. However, basic auth is insecure, even more than the curent system,
since the pasword would be send in plaintext on each page request

[1] OK, not really - we have to change the encoding mechanism used for the
password in the db so that we can validate against teh md5sum used in digest
auth. We'd have to do that even w/o mod_perl if we want to support encoded
passwords, though.

Comment 4

[Dave Miller [:justdave]]

*** Bug 104520 has been marked as a duplicate of this bug. ***

Comment 5

[Dave Miller [:justdave]]

*** Bug 237390 has been marked as a duplicate of this bug. ***

Comment 6

[Dave Miller [:justdave]]

Bug 218917 is not a prerequisite for this, but it'll probably help in many
situations.  I think the two are substantially independent of each other, though
you'll get added capabilities to the environment var login if the login doesn't
have to match the email.

This would best be done as a new Bugzilla::Auth:: subclass module (similar to
Bugzilla::Auth::DB)

I can't help for copyright reasons (I already did it for hire and they didn't
release it) but I'll be happy to advise. :)

Basic premise is the module gets called once first passing it the CGI handle so
it can check the form variables passed to see if the username and password
fields were present.  In this case, we see the environment variable that we're
looking for and look up the user and log them in based on that.

Comment 7

[Christopher Nebergall]

Below is mostly a copy of the comments I orginally made in Bug 237390 which is a
dup of this one.

(In reply to comment #3)
> I'm wondering if the easiest way to do this is via a mod_perl module. Under
> apache 2.latest, we can register as an auth provider (athough I don't know if
> those hooka are available from perl), and just get asked to validate the
> password, leavnig the http stuff to apache. This has the advantage that we get
> digestauth for free[1], against the disadvatage of only working with apache.

The purpose of using Netegrity or any other SSO app is usually that that there
is that no password sent to this web server.  Most likely the user logged into a
different web server and using domain cookies, etc to login to the web server
running bugzilla.  

Most web sso products just set REMOTE_USER to the user's authenticated username.
 I believe this is an option for EVERY web sso app and every web server they
support.

>However, basic auth is insecure, even more than the curent system,
>since the pasword would be send in plaintext on each page request

If authentication is decoupled from bugzilla the security of authentication is
no longer the web apps concern. The web server admin is already responsible for
determinging if SSL should be used on the server. In addition, there are several
apache authentication methods (some only supported by 3rd party modules) which
do not require plain text passwords: digest auth, mod_spnego, mod_ntlm, ssl
client certificates, plus new auth schemes not available yet.  There are already
web server modules available which can validate passwords using LDAP, Databases
or flat files, and Kerberos already widely in use.

I'm not advacating removing the current auth scheme, I think it is good for most
situations, but if bugzilla is to be used in a corporate environment the auth
schemes supported by the company should be used instead of bugzilla's internal
schemes and most companies rely on web server based authentication.

I also agree that bug 218917 would really need to be fixed in order for this to
work correctly.

Comment 8

[Joel Peshkin]

I agree with Comment 7 except for the dependency on email addresses.  While
changing that opens up opportunities to use mechanisms like apache's basic auth
with other userids, this can still be done without changing that to support...

a) SSO services that can provide the email address of any validated user to
Bugzill. (e.g.  I authenticate with e.fudd and it knows that my email address
[e-mail])

b) Apache authentication where the apache passwd file uses the email address.

In case (b), we could use the emailsuffix to cover still more cases.


Incidentally, my feelings will no be hurt if someone wants to implement this
before I get around to it.

Comment 9

[Karsten Huneycutt]

Attachment: make the other part of the authN selectable

Comment 10

[Karsten Huneycutt]

I have done one preliminary thing for this -- the module used for the initial
"login" method (from Bugzilla.pm) should be selectable in the same way the
DB/LDAP module is selectable.

I've added a parameter, which I called "logindatamethod" (though it really
should be called "loginmethod"; the other should have been some variation of
"password validation method", but that probably can't be changed right now).

This did require me to briefly disable strict 'refs', but I think that's the
only way to get done what needs to be done, in this case.

Comment 11

[Karsten Huneycutt]

Three patches coming; the first is the patch to the pre-existing code in the
tree.  It incorporates and extends the patch I submitted earlier today.  The
second and third are the two additional Auth modules that implement the Apache
authentication.

Together, these three provide one solution for this bug.  To make it work,
choose "logindatamethod" as Apache, "loginmethod" as Nopass, and decide and set
whether you want user autocreation.  Make sure your Apache module is configured
to return the thing in login_name (be it e-mail address or not, given the local
configuration).

Comment 12

[Karsten Huneycutt]

Attachment: the non-new-file parts

Comment 13

[Karsten Huneycutt]

Attachment: Bugzilla::Auth::Apache

This is essentially a copy of Bugzilla::Auth::CGI, hacked up a little.

Comment 14

[Karsten Huneycutt]

Attachment: Bugzilla::Auth::Nopass

This is essentially a copy of Bugzilla::Auth::DB, hacked to remove the password
validation.  It can be dangerous, and should only be enabled in the case of the
Apache module submitted before.

Comment 15

[Joel Peshkin]

Sorry, I didn't add the dependencies before.
Bug 241900 certainly will impact this.  Please look at bug 241903 and see if
these are dupes of each other.

Comment 16

[Karsten Huneycutt]

241903 does seem to be a dupe of this one; 241900 is a much more elegant
solution, I think.  I'll

Comment 17

[Dave Miller [:justdave]]

ok, bug 241903 has been fixed.  How does that impact this bug?

Comment 18

[Joel Peshkin]

The general solution solves this.

Comment 19

[Dave Miller [:justdave]]

clearing target of DUPLICATE/WONTFIX/INVALID/WORKSFORME so they'll show up as
untriaged if they get reopened.