-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josh Kelley wrote:
> On 8/3/07, Paul Ortman <[EMAIL PROTECTED]> wrote:
>> I have an existing application (cacti) that currently is using
>> mod_auth_ldap for authentication (authn) and authorization (authz)
>> to limit access to a selected LDAP group. This is a fairly common
>> usage scenario -- we need authz in addition to authn for pre-build
>> web applications that don't contain their own authz. So, I decided
>> to fiddle a bit, but things aren't working too well, and I thought
>> I'd ask to see if anybody else has made this work, or if it is
>> known broken or whatever.
>
> We're currently running the setup you describe with a mix of
> RHEL/CentOS 3 (httpd 2.0.46), 4 (httpd 2.0.52), and 5 (httpd 2.2.3).
> We've only been running it for a day or two, but everything appears
> to be working so far.
>
> The biggest problem I ran into was that mod_auth_ldap apparently must
> be loaded before mod_auth_cas. This makes mod_auth_ldap run first
> so that it can properly store the username during the authn phase
> (even though it fails to authenticate the user) so that it can then
> check for authorization on that username during the authz phase.
> Which module do you load first?
Well, both mod_auth_ldap and mod_auth_cas have their own snippets of
apache config stored in /etc/apache2/modules/ as
40_mod_auth_ldap.conf and 91_mod_auth_cas.conf respectively. Their
loaded into the global httpd.conf via an "include
/etc/apache2/modules.d/*.conf" directive. I also tried explicitly
including them in the correct order, but that seemed to have no
affect.
> If mod_auth_cas is listed before mod_auth_ldap, then mod_auth_cas
> authenticates the user, so mod_auth_ldap never initializes its
> username info. Depending on your version of httpd, it may then cause
> httpd to segfault from trying to use uninitialized user info during
> the authz phase. Is it possible that what you're seeing is a
> segfaulting httpd rather than a hanging browser?
That makes a certain amount of sense. Unfortunately, even after I
turn on full apache debugging, I can't seem to see that anything is
going wrong. After the browser is bounced to the login CAS server
and back to the client server, the only thing that shows up in the
apache error log with "log level" set to debugging is:
[debug] util_ldap.c(1690): Initialisation of global mutex
/tmp/fileXYo0iH in child process 26932 successful.
That seems to indicate that apache is at least starting up
mod_auth_ldap correctly for a new ldap connection, presumably to check
with the ldap server.
> From what I gather, Apache 2.2 is supposed to more cleanly separate
> authn from authz, so it might be easier to make it work, but I doubt
> you want to upgrade right now.
An upgrade doesn't really help me prove my position that CAS +
mod_auth_cas + mod_auth_ldap serves to replace our current
every-webapp-needs-a-SSL-cert-just-so-they-can-limit-authz.
Too bad.
Is there any chance I could take a look at your apache directives
for the protected directories or hosts? Your equivalent to:
<Directory "/var/www/localhost/htdocs/cacti">
AllowOverride AuthConfig
Order allow,deny
Allow from all
AuthType CAS
AuthName "CACTI Monitor"
AuthLDAPURL ldap://openldap.goshen.edu:389/dc=goshen,dc=edu?uid?sub?
require group cn=super_tech,ou=groups,dc=goshen,dc=edu
</Directory>
Thanks for the note.
- --
Paul Ortman
PGP Key: 55602C81
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGs4H6fw8KGlVgLIERAoNDAJ4jNFiF0wviOUByaNeZann01bnUfQCeODQW
AMrVTZrZDlvX6U01e/2Fqpc=
=nI/H
-----END PGP SIGNATURE-----
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
