I’ve seen various messages in the archives about using LDAP to
authenticate users, but everything I see seems to point to the
LookupSenderInExternalDatabase chain of defines, which is great for
E-Mail, but doesn’t do anything for user ‘foo’ who wants to login to
the web interface and check on his/her tickets.
Is there anyone who is auth’ing the web interface against LDAP as well?
(with the MySQL backend, obviously, holding permissions and such for
users who have them). Can someone point me at either relevant howto’s,
archived messages, etc., because I’m not seeing them… :-/
Is there anyone who is auth’ing the web interface against LDAP as well?
(with the MySQL backend, obviously, holding permissions and such for
users who have them). Can someone point me at either relevant howto’s,
archived messages, etc., because I’m not seeing them… :-/
I don’t think this is in RT/FM though (so you’ve got an out )
Maybe I’m dense.
I don’t see where that actually AUTH’s a web user against it. (e.g.,
nowhere in that code is there any mention of a password, so when
someone goes to the web interface and enters in a username and
password, how does that userid/password get compared against the LDAP
server?)
I think what you’re missing is enabling $WebExternalAuth in the config.pm
and then having apache perform basic auth with the LDAP backend via such
modules as Apache::AuthenLDAP and Apache::AuthzLDAP (I’d toss
Apache::AuthenCache and Apache::AuthzCache around them, though).
Thanks,
Christian
Christian Gilmore
Technology Leader
GeT WW Global Applications Development
IBM Software Group
I don’t think this is in RT/FM though (so you’ve got an out )
Maybe I’m dense.
I don’t see where that actually AUTH’s a web user against it. (e.g.,
nowhere in that code is there any mention of a password, so when
someone goes to the web interface and enters in a username and
password, how does that userid/password get compared against the LDAP
server?)
Only problem with basic auth, to my knowledge, is that anyone with a
sniffer watching long enough will be able to grab passwords since with
basic auth they are sent as plain text.
John
At 02:56 PM 12/2/2002, Christian Gilmore wrote:
I think what you’re missing is enabling $WebExternalAuth in the config.pm
and then having apache perform basic auth with the LDAP backend via such
modules as Apache::AuthenLDAP and Apache::AuthzLDAP (I’d toss
Apache::AuthenCache and Apache::AuthzCache around them, though).
Thanks,
Christian
Christian Gilmore
Technology Leader
GeT WW Global Applications Development
IBM Software Group
I don’t think this is in RT/FM though (so you’ve got an out )
Maybe I’m dense.
I don’t see where that actually AUTH’s a web user against it. (e.g.,
nowhere in that code is there any mention of a password, so when
someone goes to the web interface and enters in a username and
password, how does that userid/password get compared against the LDAP
server?)
Only problem with basic auth, to my knowledge, is that anyone with a
sniffer watching long enough will be able to grab passwords since with
basic auth they are sent as plain text.
JG> Only problem with basic auth, to my knowledge, is that anyone with a
JG> sniffer watching long enough will be able to grab passwords since with
JG> basic auth they are sent as plain text.
JG> Only problem with basic auth, to my knowledge, is that anyone with a
JG> sniffer watching long enough will be able to grab passwords since with
JG> basic auth they are sent as plain text.
SSL, man, SSL!
And the only problem with SSL is that you can’t use it with
multiple named vhosts on the same IP address. I like to give
every web service its own hostname because this makes it easy
to move around as machines are changed or upgraded without
affecting anything else and it is a lot easier to do this with
CNAMES than IP addresses. When you run these over ssl the browser
always pops up a warning that the hostname on the certificate
doesn’t match the requested host - but it does work as long as the
user clicks the OK button. Is there any way to avoid this that
doesn’t tie the name to an IP address as a side effect?
LM> And the only problem with SSL is that you can’t use it with
LM> multiple named vhosts on the same IP address. I like to give
LM> every web service its own hostname because this makes it easy
Unfortunately, no. There is a patch proposed for Apache2 that does
the equivalent of TLS for SMTP mail (ie, connect to the same port as
normal, do vhost things, then negotiate SSL), but there are no clients
that support that yet.
I just put my RT instance in different port number and its own
instance of apache – no vhosting. This keeps my RT module bloat from
adding to the regular mod_perl server module bloat
JG> Only problem with basic auth, to my knowledge, is that anyone with a
JG> sniffer watching long enough will be able to grab passwords since with
JG> basic auth they are sent as plain text.
LM> And the only problem with SSL is that you can’t use it with
LM> multiple named vhosts on the same IP address. I like to give
LM> every web service its own hostname because this makes it easy
Unfortunately, no. There is a patch proposed for Apache2 that does
the equivalent of TLS for SMTP mail (ie, connect to the same port as
normal, do vhost things, then negotiate SSL), but there are no clients
that support that yet.
This really needs to be tied to a different form of authentication
anyway - if the client passes the host: header it would probably
also pass the headers with basic authentication in the clear. In
many cases nothing but the password really needs to be encrypted.
I just put my RT instance in different port number and its own
instance of apache – no vhosting. This keeps my RT module bloat from
adding to the regular mod_perl server module bloat
This is a different issue familiar to mod_perl users that can be hidden
by a front-end proxy. It is still more painful than necessary when
you want to move it to a different machine or are forced to change
all of your IP addesses.
And the only problem with SSL is that you can’t use it with
multiple named vhosts on the same IP address. I like to give
every web service its own hostname because this makes it easy
to move around as machines are changed or upgraded without
affecting anything else and it is a lot easier to do this with
CNAMES than IP addresses. When you run these over ssl the browser
always pops up a warning that the hostname on the certificate
doesn’t match the requested host - but it does work as long as the
user clicks the OK button. Is there any way to avoid this that
doesn’t tie the name to an IP address as a side effect?
Yes, get a wildcard certificate, i.e. *.example.com. Then you can use
name based virtual hosts site1.example.com, site2.example.com, etc.
without receiving a certificate mismatch warning.
We’ve been using them for years. Thawte used to be the only game in town,
but now you can get them from other Certificate Authorities. Our current
wildcard certificate is from Geotrust/Equifax.
If that doesn’t work for you, you could probably NAT it. For example,
on a linux box you could use iptables to translate the virtual hostname
back to the real server. The NAT box and webserver need not be the same
machine, though they very well could be. You would need to adjust the
webserver config and DNS records accordingly, as well. My group isn’t
currently serving RT over SSL so we aren’t actually using NAT for that,
though we do translate other things due to this exact SSLcert/vhost
issue.
We are serving RT over SSL. We are using logical interfaces on
solaris/apache. I think there might have been a reason you didn’t want
to do this. SSL is attached to the hostname, not the ip anyhow. So if
you move services around, you just need to repoint the DNS. But who
wants to do that anyway
Indeed, specifically we are using NAT to resolve SSL cert name issues
for round-robin webservers. However, I think Rick makes a great point
and a virtual IP should do the trick for the virtual host SSL cert
issue.
On a sidenote, I’m going to be clustering RT into a failover
configuration as soon as I get a chance to finish it up. I’ll be using
a virtual-IP-based scheme to do so.
Matt
Rick Rezinas writes:>On Tue, 03 Dec 2002, Matt Disney wrote:
We are serving RT over SSL. We are using logical interfaces on
solaris/apache. I think there might have been a reason you didn’t want
to do this. SSL is attached to the hostname, not the ip anyhow. So if
you move services around, you just need to repoint the DNS. But who
wants to do that anyway
)
