Gents, Thanks for the responses, I've been trying to get a basic directory block working but I've been having the same loop errors. I think there's something going on with cosign and its cookies, it appears that it's issuing a cookie but when the client is trying to verify it cosign can't perform the validation.
I have a large number of cookies showing up under /var/lib/cosign/daemon (owned by cosign user with RW permissions) on the CAS server and on the client I seem to have nothing showing up under the filter directory (which is owned by apache). Why wouldn't Cosign be creating the cookies locally in the filter directory? There's not much in the Apache logs on the client server, but on the CAS server I see entries like the following - note the time stamps seem to match when my browser is looping while trying to authenticate: Jun 3 20:18:35 auth04 monster[12928]: eat_cookie failure: cosign=QDXi2j3hDjGyx8qN+3Gs3WvBVYe7Tahpa7Gucqm-tiJXnRuuIhh4Ey-V-V-M807A6hCLl UQ9JjXNaJ5gzJ5sVpfkn56OrLt4CE58spVWmi2B3Q4HM77eNh6sRZHY Jun 3 20:18:35 auth04 monster[12928]: read_cookie: cosign=d6Xv8T5W-s1ONMsfaVpZPvewkncHI5jN5UKLN46jt5uZpJN-8ytvd9es+z22Ob0Yk5mRk KdiwvwWi0DCKcPsu4RWgX40Re99VyQPSDuXGNlPUOiI0vMEm-q7PngN: Permission denied Jun 3 20:18:35 auth04 monster[12928]: read_cookie error: cosign=d6Xv8T5W-s1ONMsfaVpZPvewkncHI5jN5UKLN46jt5uZpJN-8ytvd9es+z22Ob0Yk5mRk KdiwvwWi0DCKcPsu4RWgX40Re99VyQPSDuXGNlPUOiI0vMEm-q7PngN Jun 3 20:18:35 auth04 monster[12928]: eat_cookie failure: cosign=d6Xv8T5W-s1ONMsfaVpZPvewkncHI5jN5UKLN46jt5uZpJN-8ytvd9es+z22Ob0Yk5mRk KdiwvwWi0DCKcPsu4RWgX40Re99VyQPSDuXGNlPUOiI0vMEm-q7PngN Jun 3 20:18:35 auth04 monster[12928]: read_cookie: cosign=d6Xv8T5W-s1ONMsfaVpZPvewkncHI5jN5UKLN46jt5uZpJN-8ytvd9es+z22Ob0Yk5mRk KdiwvwWi0DCKcPsu4RWgX40Re99VyQPSDuXGNlPUOiI0vMEm-q7PngN: Permission denied Jun 3 20:18:35 auth04 monster[12928]: read_cookie error: cosign=d6Xv8T5W-s1ONMsfaVpZPvewkncHI5jN5UKLN46jt5uZpJN-8ytvd9es+z22Ob0Yk5mRk KdiwvwWi0DCKcPsu4RWgX40Re99VyQPSDuXGNlPUOiI0vMEm-q7PngN Jun 3 20:18:35 auth04 monster[12928]: eat_cookie failure: cosign=d6Xv8T5W-s1ONMsfaVpZPvewkncHI5jN5UKLN46jt5uZpJN-8ytvd9es+z22Ob0Yk5mRk KdiwvwWi0DCKcPsu4RWgX40Re99VyQPSDuXGNlPUOiI0vMEm-q7PngN Jun 3 23:25:59 auth04 cosignd[9316]: connect: 127.0.0.1 Jun 3 23:25:59 auth04 cosignd[9316]: STARTTLS 127.0.0.1 2 login.company.com Jun 3 23:25:59 auth04 cosignd[9316]: REGISTER testuser ldap 172.16.13.245 cosign-plone Jun 3 23:26:43 auth04 monster[3156]: STATS MONSTER: 0/0/6 login 0/60 service Jun 3 23:28:43 auth04 monster[3156]: STATS MONSTER: 0/0/6 login 0/60 service Jun 3 23:29:59 auth04 cosignd[9301]: STATS CHECK 172.16.13.245: PASS 1.00000 / sec Jun 3 23:30:43 auth04 monster[3156]: STATS MONSTER: 0/0/6 login 0/60 service Any ideas? What can I look at? Thanks! Josh -----Original Message----- From: Andrew Mortensen [mailto:[email protected]] Sent: Tuesday, June 02, 2009 10:36 PM To: Josh Campbell Cc: [email protected] Subject: Re: [Cosign-discuss] Cosign Apache Help > The helloCosign test scrips are failing, the user in the headers > isn't being recognized and I don't know why. Also I think it's not > getting the correct Plone URL (http://web01.company.com/plone works > fine) redirected back, but I don't know. Wes is right. Concentrate on getting the test scripts working first. cosign 3.0 adds one additional validation step to the cosign scheme, which involves redirection to a well-known location intercepted by the cosign module. mod_cosign steps in to claim requests for the /cosign/ valid URI, setting the cookie and redirecting to the protected page if both cookie and destination are valid. Are you sure cookies are being set? Check your browser's cookie cache for the "cosign-plone" cookie. > Here's the URL redirected back when Zope reports the error of > Resource not found - Resource: cosign GET: ... It sounds like Zope is somehow intercepting the request for /cosign/ valid before mod_cosign is getting to it. Zope is looking for a resource called "cosign" at the docroot, and not finding it. It shouldn't, since /cosign/valid is a virtual URI only meaningful to mod_cosign, but it's possible Zope won't be happy until you create / cosign/valid. Certain java implementations seem to require the presence of /cosign/valid for the 3.0 java cosign filter to work correctly. > I've also been getting a lot of loop errors, not sure why. Any help > is greatly appreciated! If validation fails at the well-known location, mod_cosign redirects to the protected page without setting a cookie, on the best thing to do is to try running through things once more. If some error in configuration is preventing mod_cosign from handling requests for / cosign/valid (e.g., /cosign/valid is itself cosign-protected, a rewrite rule is mangling the URL, etc), you'll get the looping errors. andrew ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
