Re: [Cosign-discuss] 3.0.0 filter not getting kerberos tickets

[Andrew M. <adm...@um...>]

On Apr 21, 2009, at 10:39 AM, Toby Blake wrote:

>> Hmm. I've had a couple other reports about similar problems with
>> directives which should work in location blocks. I'll see what I can
>> find out what's going on, and release 3.0.2. In the meantime, I hope
>> this workaround helps.
>
> Great, thanks, but not ideal for the longer term.  Also I can leave v2
> filters running against a v3.0 server for the moment, so I can
> preserve per-location settings.
>
> If I can provide any more debugging information on this, let me know.
> e.g. backtraces, etc.

Kevin Coffman of Umich ran into this problem while working with proxy  
cookies. He tracked it back to a long standing bug in mod_cosign,  
which is that proxy cookies and tickets are only retrieved if the  
filter believes the current request is the first authenticated visit  
by the user. Cosign 3 exercises the bug because of the new validation  
URL, which is always visited before redirection to the service URL. If  
CosignGetProxyCookies or CosignGetKerberosTickets is set in a  
Directory or Location context, they will not be retrieved because the  
handler configuration is in its own Location context. I'm working on a  
fix.

The same problem does exist in the legacy filters, though. If you have  
this setup:

<Location /gateway>
	CosignProtected	On
</Location>

<Location /filespace>
	CosignProtected On
	CosignGetKerberosTickets On
</Location>

and you visit the /gateway URI first, you won't have tickets when you  
visit the /filespace URI. If you visit /filespace first, you'll get  
the tickets. But those tickets are also available to the /gateway URI:  
mod_cosign will read the cookie, observe that there's a value for the  
kerberos ticket path, and set the KRB5CCNAME environment.

Toby, what's the value for you in having CosignGetKerberosTickets  
available in Location or Directory contexts?

andrew