Re: mod_cosign / mod_authz_ldap behavior

[Kris Steinhoff <steinhof@xxxxxxxxx>]

To work around the mod_cosign / mod_authz_ldap problem I've written a 
PHP application that produces a list of tools that the user is 
authorized to use. And by modifying the 401 error my server produces to 
give the user a link the list of tools, I can effectively get around 
the problem.

The scripts find all the .htaccess files in your document root then 
parses each file looking for the "Require group" directive, adding the 
groups to an array. Additionally the .htaccess file is parsed for what 
I'll call pseudo-directives, basically an Apache configuration comment 
that only has meaning to the tools_list scripts. The .htaccess file, 
might look like this:

Require group mygroup othergroup
#tools_list url https://myserver.umich.edu/service
#tools_list title Service Name

The first word that follows "#tools_list" will be the key in the 
tools_list array, and the rest of the line will be the value. This is a 
method to provide nice looking links to the end user.

The scripts query the LDAP server to check for the user's 
($_SERVER['REMOTE_USER']) group membership (modify the LDAP server 
connection variables on lines 39, 41, and 43 of www/index.php to match 
your setup). If the user is a member of one of the groups listed by the 
"Require group" directive, then the array of information about that 
directory (the url and title, etc), is added to the list of links to be 
displayed. The scripts call a rudimentary template system to display 
the links.

If you drop these scripts into your document root, and modify the 
$get_tools->doc_root property to fit your setup (line 30 of 
www/index.php), the scripts should just work. You can also keep the 
classes and templates directories out of the document root and just add 
the index.php file, in this case you will need to modify the 
$class_file variable (line 18 in index.php) in the __autoload function 
and the $template->dir property (line 50 in index.php).

There are some things I'd like to update in these scripts to make them 
easier to use and modify, but I'm using this version on my server now 
and it works well. Please let me know if this is useful to you.

thanks
-kris

Attachment: tools_list.zip
Description: Zip archive

On Sep 7, 2005, at 3:53 PM, johanna bromberg craig wrote:

> Hey Kris,
>
> 1) Not sure why the patch failed, I'll double check it. If group 
> checking is working at all, then your manual implementation of the 
> patch worked :)
>
> 2) The behavior that you are seeing is in fact the way things work at 
> present. mod_authz_ldap is not perfect, and there are several changes 
> we'd like to make to have it integrate more smoothly with our 
> environment ( or other cosign deploys ), but until we have the 
> resources to do such a development effort, things stand as is.
>
> My suggestion, though admittedly hackish and ugly, would be to have a 
> splash page that would force authentication ( with no AuthZ 
> requirements ) and set a SiteEntry policy (CosignSiteEntry) that'll 
> redirect back to /broken instead of the splash page. Or you could just 
> publish a link, but SiteEntry is less hackish and ugly.
>
> We can talk further about workarounds off-list and summarize the 
> discussion for on-list if you'd like - that's just a jumping off 
> point. :)
>
> -J
>
> On Sep 7, 2005, at 9:29 AM, Kris Steinhoff wrote:
>
> > I have mod_cosign setup and working nicely on my OS X Server (10.4.2),
> > and I've followed the directions for setting up mod_authz_ldap to work
> > with cosign:
> >   http://www.umich.edu/~umweb/downloads/mod_authz_ldap-NOTES-UMICH.txt
> >
> > However using that file to patch mod_authz_ldap fails in two places:
> >
> >   patching file module/auth.c
> >   patching file module/mod_authz_ldap.h
> >   Hunk #1 FAILED at 52.
> >   Hunk #2 FAILED at 61.
> >   2 out of 2 hunks FAILED -- saving rejects to file
> >   module/mod_authz_ldap.h.rej
> >   patching file module/modconf.c
> >
> > I've applied the changes in those two hunks by hand and compiled
> > mod_authz_ldap.
> >
> > Things seem to work pretty well, but there is a problem with my server
> > not redirecting to the weblogin server when the browser requests a
> > directory which has a "Require group ..." directive associated with
> > it. But it works just fine if the browser already has the cosign
> > cookies set.
> >
> > For example, take two directories "/broken" and "/ok." The directory
> > entries in httpd.conf are the same for both, but "/broken" includes a
> > "Require group ... " directive. If I visit "/broken" the browser gets
> > a 401 error and
> >
> >   basic LDAP authentication of user '(null)' failed
> >
> > is printed to my server's error log. But if I then visit "/ok" the
> > browser is redirected normally to the weblogin server. After I
> > authenticate at the weblogin server and the cosign cookies are set I
> > can visit "/broken" without any trouble.
> >
> > It seems like mod_authz_ldap is doing its thing before mod_cosign gets
> > a chance to, but I've double checked to make sure that mod_cosign is
> > loaded before mod_authz_ldap, so I'm not sure if that the problem.
> >
> > Any suggesting about where I might start looking to fix this? Could it
> > be the problem I had with the patch? Something else?
> >
> > thanks
> > -kris
> >
> >
> >
> >
> >
> > --
> > Kris Steinhoff
> > University of Michigan Health Service
> > Information Technology Services
> >
> > Electronic mail is not secure, may not be read every day,
> > and should not be used for urgent or sensitive issues.
> >
> > !DSPAM:431eeb7c39884308470059!

--
Kris Steinhoff
University of Michigan Health Service
Information Technology Services

Electronic mail is not secure, may not be read every day,
and should not be used for urgent or sensitive issues.


--
Kris Steinhoff
University of Michigan Health Service
Information Technology Services

Electronic mail is not secure, may not be read every day,
and should not be used for urgent or sensitive issues.