CoSign: Collaborative Single Sign-On  
AnnouncementsDiscussion
 

cosign-discuss at umich.edu
general discussion of cosign development and deployment
 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mod_cosign / mod_authz_ldap behavior



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!







 
Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010