Anyone? I'm still at a dead stop - can't figure this out. Why wouldn't the service cookies get created on the client server? There seems to be a major lack of documentation for the setup of version 3 of Cosign, I've printed and read all the README files and even the man page for cosign.conf, but I'm still unable to make this work.
Does anyone have a working client and server config I can reference? Pretty please? Thanks, Josh -----Original Message----- From: Andrew Mortensen [mailto:[email protected]] Sent: Thursday, June 04, 2009 11:18 AM To: Josh Campbell Cc: [email protected]; [email protected] Subject: Re: [Cosign-discuss] Cosign Apache Help On Jun 3, 2009, at 11:56 PM, Josh Campbell wrote: > 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? If the cookie isn't getting set in the browser (which I asked you about earlier), that means validation of the cookie at /cosign/valid failed, which can subsequently cause browser looping. It can fail for a number of reasons, but the most common one we saw during our upgrade was of a certificate not allowed to ask cosignd about the particular service name you're using. If this validation fails, mod_cosign will NOT create a locally cached cookie because cosignd refused to give out the information about the user. > There's not much in the Apache logs on the client server Yes, a long-standing shortcoming of mod_cosign. We're hoping to address that in a future release. > 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]: read_cookie: > cosign=d6Xv8T5W-s1ONMsfaVpZPvewkncHI5jN5UKLN46jt5uZpJN-8ytvd9es > +z22Ob0Yk5mRk > KdiwvwWi0DCKcPsu4RWgX40Re99VyQPSDuXGNlPUOiI0vMEm-q7PngN: Permission > denied This "permission denied" error suggests that the directory isn't owned by the right user, or has permissions otherwise incorrectly set, but since three hours pass between this error and what appears to be a successful monster pass, it appears you've already addressed this. andrew ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
