[an error occurred while processing the directive]
![]() |
cosign-discuss at umich.edu |
general discussion of cosign development and deployment | |
> I'm not on the cosign development team, but I'm curious -- > what other information aside from REMOTE_USER and REMOTE_REALM > are you looking for? I'm not using Kerberos at the moment (couldn't get my debian woody box to authenticate against AD, so I gave up and did the wacky hack described earlier), so I don't have anything but REMOTE_USER set. But I can feed other things to the basicosign.cgi if it'll take them. > I run several cosign-enabled web servers, and use require-group > all the time. I use both DBM and LDAP groups. mod_auth_dbm > for Apache uses the user information provided by cosign to do > the group lookup. Got an httpd.conf snippet you can share? That's the direction I was going, but was trying to see if I can keep the other webmasters from needing any knowledge of the internal structure - it's a lot easier to say "add require-group developer" than to give them an LDAP lookup string... > I also write a large number of Perl CGIs > that use the REMOTE_USER environment variable to do their > own group checks via LDAP and other means. Yep, probably where I'll end up. > cosign's job is authentication. Authorization is a separate > task that takes place outside of cosign after authentication > occurs. Authorization is usually handled the same way you > handle authorization when using any other form of authentication > other than cosign. Quite true - it's just that apache's ldap-based access often does both of these by virtue of the searches it uses. -- Brian Hatch "I have recently made Systems and the resolution not to Security Engineer have visitors on http://www.ifokr.org/bri/ Thursday between seven and nine in the evening." Every message PGP signed
Attachment:
signature.asc
Description: Digital signature