mod_auth_cas for authn and mod_auth_ldap for authz

[Smith, Matt]

Good analysis - makes sense to me.  Phil and I seem to be of the same
opinion that adding LDAP-specific functionality to mod-auth-cas would
not be a good idea.  Does Apache 2.2's mod-authnz-ldap really allow
better separation, such that it can do a correct search of LDAP to find
a DN from REMOTE_USER during the AuthZ phase?  If so, it would seem this
is preferential.

Here is a link to a thread on the Shibboleth list with largely the same
discussion:
https://mail.internet2.edu/wws/arc/shibboleth-users/2007-06/msg00158.html

-Matt

On Mon, 2007-08-06 at 13:26 -0400, Josh Kelley wrote:
> On 8/3/07, Smith, Matt <matt.smith at uconn.edu> wrote:
> >
> >   I have not tried mod-auth-cas + mod-auth-ldap myself yet, but I have seen discussion on other lists (Shibboleth most recently) about using mod-auth-ldap for the authorization phase only.  As already mentioned, Apache 2.2 seems to handle this better - or more specifically, the version of mod-auth-ldap included with Apache 2.2 (renamed mod-authnz-ldap) seems to better handle authz when not also handling authn.  The general consensus on these other lists seems to be that unless your distro vendor has backported certain functionality into mod-auth-ldap, it is not possible (or at least, not worth the effort) with anything earlier than 2.2.
> 
> I investigated some more, and here's what I was able to figure out.
> If anyone finds that I'm mistaken on any points, I'd appreciate
> correction.
> 
> The first problem, as I said, is that mod_auth_ldap may cause Apache
> to segfault if it's called for authz but not called at all for authn.
> This bug has been fixed in recent versions of Apache, and vendors such
> as Red Hat have backported the fix.  The workaround is to make sure
> that mod_auth_ldap is loaded before mod_auth_cas.
> 
> The second problem is that mod_auth_ldap only looks up the user's DN
> if it is used for authn.  This is the key difference between Paul
> Ortman's config and mine and is why my config works:  our LDAP
> directory uses the posixGroup objectClass, with memberUid listing
> members' usernames, and so mod_auth_ldap's AuthLDAPGroupAttributeIsDN
> is set to off, and so mod_auth_ldap is able to look up group
> membership by username.  I'm assuming that Paul's directory uses the
> groupOfUniqueNames objectClass (or equivalent), with membership listed
> by users' DN, and his Apache config uses the default of
> AuthLDAPGroupAttributeIsDN on, and so mod_auth_ldap is unable to look
> up group membership by DN, since it never looks up the user's DN.
> 
> I can think of a few possible solutions to this second problem:
> Upgrade to Apache 2.2, or try one of the standalone LDAP modules for
> Apache 2.0 (http://modules.apache.org/search?query=true&search=ldap)
> to see if they support separate authn and authz, or try mod_auth_pam
> with your system configured to use nss_ldap, or modify the LDAP
> directory to list membership by username instead of (or in addition
> to) DN.  (In my tests, listing both ways doesn't seem to cause any
> problems.)  It also looks like it would be fairly straightforward to
> patch Apache's mod_auth_ldap to make it work just for authz, but I
> don't know how Apache admins would feel about having to maintain a
> patch like that.  Thoughts?
> 
> As far as changing mod_auth_cas to make it work, the only solution
> that I could see is for it to rewrite r->user to be a DN during the
> authn phase then set AuthLDAPGroupAttributeIsDN to off, so that Apache
> thinks it's looking up usernames when it's really looking up DNs.  I
> believe this would require either a fixed template for user DNs (e.g.,
> uid=%s,ou=People,dc=example,dc=com) or an LDAP lookup from within
> mod_auth_cas, and it puts r->user in a format that's less usable for
> other applications.  All of that seems like a really big hack.
> 
> Do you have any links to the discussions on other lists?  I tried
> searching and couldn't find anything; I'm curious to see what was
> said.
> 
> Thanks.
> 
> Josh Kelley
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
-- 
Matthew J. Smith <matt.smith at uconn.edu>
University of Connecticut UITS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://tp.its.yale.edu/pipermail/cas/attachments/20070806/58000ef7/attachment.bin