Cosign: Web Single Sign-On

Caroline,

What version of the IIS filter are you using?  It looks like the IP  
mismatch should only be reported to the Event Viewer if  
<WriteDataToEventViewer> is set to "true".  I'd recommend setting this  
to "false" unless you're trying to troubleshoot something.

The reason this event is interesting to cosign is it is letting you  
know that a user has changed IP addresses since logging in and it is  
possible somebody is trying to replay their service cookie.  (Of  
course, there are many other benign reasons for an IP address change.)


Jarod

On Apr 28, 2009, at 10:16 AM, Caroline Couture wrote:

> Hi Folks!
>
> We have been getting this cosign warning since we installed it. It  
> seems to be happening every time a user authenticates. They have no  
> problems authenticating or using the application in question.
>
> I think this means we are missing something in our cosign set up.
>
> Any clues as to what this means?
>
> Event Type:	Information
> Event Source:	CosignFilter
> Event Category:	(1)
> Event ID:	1
> Date:		4/28/2009
> Time:		12:19:14 AM
> User:		N/A
> Computer:	WEBxxx
> Description:
> The description for Event ID ( 1 ) in Source ( CosignFilter ) cannot  
> be found. The local
> computer may not have the necessary registry information or message  
> DLL files to display messages from a remote computer. You may be  
> able to use the /AUXSOURCE= flag to retrieve this description; see  
> Help and Support for details. The following information is part of  
> the event: Server IP info for client 130.91.241.xxx does not match  
> browser IP 130.91.240.xxx.
>
> Thanks!
> Caroline
>
> Caroline Couture
> College House Computing
> 3702 Spruce Street
> Philadelphia, PA 19104
>
> You must never confuse faith that you will prevail in the end --  
> which you can never afford to lose -- with the discipline to  
> confront the most brutal facts of your current reality, whatever  
> they might be.
> -- Vice Admiral James Bond Stockdale
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code  
> vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Cosign-discuss mailing list
> Cosign-discuss@...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>

Hi Jarod,

As for the version of the filter, it appears to be version 2.1.0-rc2. I am unsure why we would be getting this error. Can you explain to me the circumstances under which it would occur? (If possible.)

Is this flag set to on by default?

Thanks!
Caroline

Caroline Couture
College House Computing
3702 Spruce Street
Philadelphia, PA 19104

You must never confuse faith that you will prevail in the end -- which you can never afford to lose -- with the discipline to confront the most brutal facts of your current reality, whatever they might be.
-- Vice Admiral James Bond Stockdale
-----Original Message-----
From: Jarod Malestein [mailto:jarod@...] 
Sent: Tuesday, April 28, 2009 4:51 PM
To: Caroline Couture
Cc: cosign-discuss@...
Subject: Re: [Cosign-discuss] Cosign warning in log file?

Caroline,

What version of the IIS filter are you using?  It looks like the IP mismatch should only be reported to the Event Viewer if <WriteDataToEventViewer> is set to "true".  I'd recommend setting this to "false" unless you're trying to troubleshoot something.

The reason this event is interesting to cosign is it is letting you know that a user has changed IP addresses since logging in and it is possible somebody is trying to replay their service cookie.  (Of course, there are many other benign reasons for an IP address change.)


Jarod

On Apr 28, 2009, at 10:16 AM, Caroline Couture wrote:

> Hi Folks!
>
> We have been getting this cosign warning since we installed it. It 
> seems to be happening every time a user authenticates. They have no 
> problems authenticating or using the application in question.
>
> I think this means we are missing something in our cosign set up.
>
> Any clues as to what this means?
>
> Event Type:	Information
> Event Source:	CosignFilter
> Event Category:	(1)
> Event ID:	1
> Date:		4/28/2009
> Time:		12:19:14 AM
> User:		N/A
> Computer:	WEBxxx
> Description:
> The description for Event ID ( 1 ) in Source ( CosignFilter ) cannot 
> be found. The local computer may not have the necessary registry 
> information or message DLL files to display messages from a remote 
> computer. You may be able to use the /AUXSOURCE= flag to retrieve this 
> description; see Help and Support for details. The following 
> information is part of the event: Server IP info for client 
> 130.91.241.xxx does not match browser IP 130.91.240.xxx.
>
> Thanks!
> Caroline
>
> Caroline Couture
> College House Computing
> 3702 Spruce Street
> Philadelphia, PA 19104
>
> You must never confuse faith that you will prevail in the end -- which 
> you can never afford to lose -- with the discipline to confront the 
> most brutal facts of your current reality, whatever they might be.
> -- Vice Admiral James Bond Stockdale
> ----------------------------------------------------------------------
> -------- Register Now & Save for Velocity, the Web Performance & 
> Operations Conference from O'Reilly Media. Velocity features a full 
> day of expert-led, hands-on workshops and two days of sessions from 
> industry leaders in dedicated Performance & Operations tracks. Use 
> code vel09scf and Save an extra 15% before 5/3. 
> http://p.sf.net/sfu/velocityconf 
> _______________________________________________
> Cosign-discuss mailing list
> Cosign-discuss@...
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>

<WriteDataToEventViewer> is set to false by default.  If it is set to  
true, the Event Viewer would be flooded with other messages.  Is this  
"Server IP info does not match" the only 'error' showing up or are  
there other "Cosign" or "CosignFilter" events?


Jarod

On Apr 30, 2009, at 10:13 AM, Caroline Couture wrote:

> Hi Jarod,
>
> As for the version of the filter, it appears to be version 2.1.0- 
> rc2. I am unsure why we would be getting this error. Can you explain  
> to me the circumstances under which it would occur? (If possible.)
>
> Is this flag set to on by default?
>
> Thanks!
> Caroline
>
> Caroline Couture
> College House Computing
> 3702 Spruce Street
> Philadelphia, PA 19104
>
> You must never confuse faith that you will prevail in the end --  
> which you can never afford to lose -- with the discipline to  
> confront the most brutal facts of your current reality, whatever  
> they might be.
> -- Vice Admiral James Bond Stockdale
> -----Original Message-----
> From: Jarod Malestein [mailto:jarod@...]
> Sent: Tuesday, April 28, 2009 4:51 PM
> To: Caroline Couture
> Cc: cosign-discuss@...
> Subject: Re: [Cosign-discuss] Cosign warning in log file?
>
> Caroline,
>
> What version of the IIS filter are you using?  It looks like the IP  
> mismatch should only be reported to the Event Viewer if  
> <WriteDataToEventViewer> is set to "true".  I'd recommend setting  
> this to "false" unless you're trying to troubleshoot something.
>
> The reason this event is interesting to cosign is it is letting you  
> know that a user has changed IP addresses since logging in and it is  
> possible somebody is trying to replay their service cookie.  (Of  
> course, there are many other benign reasons for an IP address change.)
>
>
> Jarod
>
> On Apr 28, 2009, at 10:16 AM, Caroline Couture wrote:
>
>> Hi Folks!
>>
>> We have been getting this cosign warning since we installed it. It
>> seems to be happening every time a user authenticates. They have no
>> problems authenticating or using the application in question.
>>
>> I think this means we are missing something in our cosign set up.
>>
>> Any clues as to what this means?
>>
>> Event Type:	Information
>> Event Source:	CosignFilter
>> Event Category:	(1)
>> Event ID:	1
>> Date:		4/28/2009
>> Time:		12:19:14 AM
>> User:		N/A
>> Computer:	WEBxxx
>> Description:
>> The description for Event ID ( 1 ) in Source ( CosignFilter ) cannot
>> be found. The local computer may not have the necessary registry
>> information or message DLL files to display messages from a remote
>> computer. You may be able to use the /AUXSOURCE= flag to retrieve  
>> this
>> description; see Help and Support for details. The following
>> information is part of the event: Server IP info for client
>> 130.91.241.xxx does not match browser IP 130.91.240.xxx.
>>
>> Thanks!
>> Caroline
>>
>> Caroline Couture
>> College House Computing
>> 3702 Spruce Street
>> Philadelphia, PA 19104
>>
>> You must never confuse faith that you will prevail in the end --  
>> which
>> you can never afford to lose -- with the discipline to confront the
>> most brutal facts of your current reality, whatever they might be.
>> -- Vice Admiral James Bond Stockdale
>> ----------------------------------------------------------------------
>> -------- Register Now & Save for Velocity, the Web Performance &
>> Operations Conference from O'Reilly Media. Velocity features a full
>> day of expert-led, hands-on workshops and two days of sessions from
>> industry leaders in dedicated Performance & Operations tracks. Use
>> code vel09scf and Save an extra 15% before 5/3.
>> http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> Cosign-discuss mailing list
>> Cosign-discuss@...
>> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>>
>>
>
>
>

Hi Jarod,

Looking at the filter log it looks like that error is not the most frequent one. We are seeing this as well:

[3-17-2009	2:22:4] OnPreprocHeaders(): Could not get cookie.
[3-17-2009	2:31:43] OnPreprocHeaders(): Could not get cookie.
[3-17-2009	2:31:48] netcheck_cookie::snet_getline_multi failed.
[3-17-2009	9:58:59] netcheck_cookie::snet_getline_multi failed.

Thanks!
Caroline

Caroline Couture
College House Computing
3702 Spruce Street
Philadelphia, PA 19104

You must never confuse faith that you will prevail in the end -- which you can never afford to lose -- with the discipline to confront the most brutal facts of your current reality, whatever they might be.
-- Vice Admiral James Bond Stockdale

On Apr 28, 2009, at 11:06 AM, Steve Devine wrote:

> I am now successfully getting authenticated by cosign. But I do not
> initially get a ticket in /ticket on the application server.
> If I go into /var/cosign/filter and delete the files in there and then
> refresh the browser I will then get the ticket.
> On the cosign server the /ticket directory does get a ticket  
> immediately.

What's your Apache config look like? cosign 3.0 exercises a long- 
standing bug, as described here:

<http://sourceforge.net/mailarchive/message.php?msg_name=CD9EB616-B9C9-422A-96FF-DFEBF9214E83%40umich.edu 
 >

> Also these tickets are not working with modwaklog - I know thats a
> different list but maybe others are running into this.

The tickets will need to be forwardable. Check the flags on the  
tickets with "klist -f /path/to/ticket". You should see something like  
this:

Ticket cache: FILE:/ticket/5vr2tG3aYBIz
Default principal: admorten@...

Valid starting     Expires            Service principal
04/28/09 13:52:32  04/28/09 23:52:32  krbtgt/UMICH.EDU@...
	Flags: FIA, Etype (skey, tkt): DES cbc mode with CRC-32, AES-256 CTS  
mode with 96-bit SHA-1 HMAC

You're interested in the Flags section. 'F' means the ticket is  
forwardable.

andrew

Andrew Mortensen wrote:
> 
> On Apr 28, 2009, at 11:06 AM, Steve Devine wrote:
> 
>> I am now successfully getting authenticated by cosign. But I do not
>> initially get a ticket in /ticket on the application server.
>> If I go into /var/cosign/filter and delete the files in there and then
>> refresh the browser I will then get the ticket.
>> On the cosign server the /ticket directory does get a ticket immediately.
> 
> What's your Apache config look like? cosign 3.0 exercises a
> long-standing bug, as described here:
> 
> <http://sourceforge.net/mailarchive/message.php?msg_name=CD9EB616-B9C9-422A-96FF-DFEBF9214E83%40umich.edu>
> 
> 
>> Also these tickets are not working with modwaklog - I know thats a
>> different list but maybe others are running into this.
> 
> The tickets will need to be forwardable. Check the flags on the tickets
> with "klist -f /path/to/ticket". You should see something like this:
> 
> Ticket cache: FILE:/ticket/5vr2tG3aYBIz
> Default principal: admorten@...
> 
> Valid starting     Expires            Service principal
> 04/28/09 13:52:32  04/28/09 23:52:32  krbtgt/UMICH.EDU@...
>     Flags: FIA, Etype (skey, tkt): DES cbc mode with CRC-32, AES-256 CTS
> mode with 96-bit SHA-1 HMAC
> 
> You're interested in the Flags section. 'F' means the ticket is
> forwardable.
> 
> andrew
> 
Andrew
It is indeed this bug. If I put "CosignGetKerberosTickets on" in the
'global' section of the apache configs rather then inside the
<Directory> tags I get the ticket immediately.
I can live with this since I will always need the ticket.

As for my other problem with modwaklog not getting a token.
Here is output of  klist -f /ticket/lKgE2p06hwk3

Ticket cache: FILE:/ticket/lKgE2p06hwk3
Default principal: sad2@...
Valid starting     Expires            Service principal
04/28/09 16:06:08  04/29/09 02:06:08  krbtgt/MSU.EDU@...
        Flags: FIA
04/28/09 16:06:08  04/29/09 02:06:08  afs@...
        Flags: FAT


Also when I run php_info()
I get this in the apache environment section.

KRB5CCNAME 	no value

So I put the line in the cosign.conf file
set       cosigndticketcache  /ticket
and I passed it as a configure switch like so:
-with-ticketcache=/ticket

Still no joy. Is cosignd (on the cosign server)  supposed to set this
environment variable?

Thanks
/sd



-- 
Steve Devine
Email & Storage
Academic Technology Services
Michigan State University

313 Computer Center
East Lansing, MI 48824-1042
1-517-432-7327

On Apr 28, 2009, at 4:27 PM, Steve Devine wrote:

> Also when I run php_info()
> I get this in the apache environment section.
>
> KRB5CCNAME 	no value
>
> So I put the line in the cosign.conf file
> set       cosigndticketcache  /ticket
> and I passed it as a configure switch like so:
> -with-ticketcache=/ticket
>
> Still no joy. Is cosignd (on the cosign server)  supposed to set this
> environment variable?

cosignd never talks to Apache, so cosignd never sets KRB5CCNAME.  
mod_cosign should be setting KRB5CCNAME if the cosign cookie in /var/ 
cosign/filter contains a ticket path. Do you have a /ticket path on  
your cosign client? That's the default location where mod_cosign will  
save tickets retrieved from cosignd.

andrew

Andrew Mortensen wrote:
>
> On Apr 28, 2009, at 4:27 PM, Steve Devine wrote:
>
>> Also when I run php_info()
>> I get this in the apache environment section.
>>
>> KRB5CCNAME     no value
>>
>> So I put the line in the cosign.conf file
>> set       cosigndticketcache  /ticket
>> and I passed it as a configure switch like so:
>> -with-ticketcache=/ticket
>>
>> Still no joy. Is cosignd (on the cosign server)  supposed to set this
>> environment variable?
>
> cosignd never talks to Apache, so cosignd never sets KRB5CCNAME. 
> mod_cosign should be setting KRB5CCNAME if the cosign cookie in 
> /var/cosign/filter contains a ticket path. Do you have a /ticket path 
> on your cosign client? That's the default location where mod_cosign 
> will save tickets retrieved from cosignd.
>
> andrew
>
Yes looks like I do have the cookie:
v2
i68.255.60.14
pmailtest
rMSU.EDU
fMSU.EDU
k/ticket/LnsnpTjfBE4c
 
and I checked and the apache user can read it and /ticket as well.


-- 
Steve Devine
Email & Storage
Academic Technical Services
Michigan State University

313 Computer Center
East Lansing, MI 48824-1042
1-517-432-7327

Baseball is ninety percent mental; the other half is physical.
- Yogi Berra

On Apr 28, 2009, at 10:35 PM, Steve Devine wrote:

> /ticket/LnsnpTjfBE4c

And does klist think this is a valid ticket? E.g.:

export KRB5CCNAME=/ticket/LnsnpTjfBE4c; klist

Quoting "Andrew Mortensen" <admorten@...>:

>
> On Apr 28, 2009, at 4:27 PM, Steve Devine wrote:
>
>> Also when I run php_info()
>> I get this in the apache environment section.
>>
>> KRB5CCNAME 	no value
>>
>> So I put the line in the cosign.conf file
>> set       cosigndticketcache  /ticket
>> and I passed it as a configure switch like so:
>> -with-ticketcache=/ticket
>>
>> Still no joy. Is cosignd (on the cosign server)  supposed to set this
>> environment variable?
>
> cosignd never talks to Apache, so cosignd never sets KRB5CCNAME.  
> mod_cosign should be setting KRB5CCNAME if the cosign cookie in  
> /var/cosign/filter contains a ticket path. Do you have a /ticket  
> path on your cosign client? That's the default location where  
> mod_cosign will save tickets retrieved from cosignd.
>
> andrew
>
>


OK Problem solved.
Again not really the right list but mod_waklog.c has
3 Defines that need to be modified:
#define KEYTAB                  "/etc/keytab.wwwserver"
#define KEYTAB_PRINCIPAL        "someplacewwwserver"
#define AFS_CELL      "someplace.edu"

I will post this to their list as well.
Thanks for your help. I think I am set.

Steve Devine
Email & Storage
Academic Technology Services
Michigan State University

On Apr 24, 2009, at 4:47 PM, Steve Devine wrote:

> Well I am making progress but I am pretty sure I am not getting the  
> idea
> behind this new conf file in version 3.
>
> Can some one give me an example of what you might put in the  
> cosign.conf
> file on the weblogin server if the directory on the application server
> mytestserver.ats.msu.edu
> was like so :
>
> <Directory "/home/www/ssl-htdocs/protected">
>        CosignProtected On
>        CosignService          MyTest
>      Options Indexes FollowSymLinks MultiViews
>        Order allow,deny
>        Allow from all
> </Directory>

This is all fine.

> This is what I have now:
>
> service cosign-MyTest https://mytestserver.ats.msu.edu/cosign/valid T
> MyTest\mytestserver\.ats\.msu\.edu

This looks fine, too, except for maybe a missing dot after the first  
backslash. Is your certificate CN really  
"MyTest.mytestserver.ats.msu.edu"? Or is the CN just  
mytestserver.ats.msu.edu?

> Also whats the purpose of  /cosign/valid ?

This is the location mod_cosign intercepts to validate the cookie and  
the service URL. You need to tell Apache that mod_cosign will handle  
requests for this URI. This is what we're recommending:

<Location /cosign/valid>
	SetHandler		cosign
	CosignProtected Off
	Allow from all
	Satisfy any
</Location>

> Does this need to exist on the filesystem?

No, see above.

> My apache logs are giving me this
>
> [Fri Apr 24 16:28:28 2009] [notice] mod_cosign: invalid destination:
> https://mytestserver.ats.msu.edu/protected

This suggests your CosignValidReference regex does not match that  
service URL. What have you got it set to?

andrew

On Thu, Apr 23, 2009 at 4:38 PM, Phil Pishioneri <pgp@...> wrote:
> First time I'm trying out the _passwd_ keyword (in v3, not 2.x), having
> trouble keeping the username as just the kerberos principal.
>
> Let's say my krb5 realm is K.PSU.EDU. Either of the following two config
> entries
>
> passwd kerberos ([^@]+)   $1@...   K.PSU.EDU
> passwd kerberos ([^@]+)   $1   K.PSU.EDU   [using the default realm in
> krb5.conf]
>
> will work if someone enters their account name as "foo" in the _login_ input
> field. (USER="foo", REALM="K.PSU.EDU")
>
> I'd like to add another config line so that if someone entered
> "foo@..." into the login field, it would be equivalent to the above
> keywords, setting the User to "foo". My attempts:
>
> passwd kerberos ([^@]+)@K.PSU.EDU   $1@...  K.PSU.EDU
> passwd kerberos ([^@]+)@(K\.PSU\.EDU)   $1@...   K.PSU.EDU
>
> etc., are all the same. Whatever string is entered into the login field,
> becomes the USER: "foo@..." (for that input). The realm is set
> correctly, and the kerberos ticket is the desired one. Even
>
> passwd kerberos ([^@]+)@bar   $1@...   K.PSU.EDU
>
> gets the user set to "foo@..." (for that input).  Seems to be acting like
> the mysql option (using the "email address"), where I'd prefer that it just
> used the principal (and /instance if set?).
>
> Is this the intended behavior?

What we do here is something like this, which should work for 3.0
(assuming that part of the code hasn't changed, still need to test
that):

passwd kerberos ([^@]+) $1 BX.PSU.EDU

I tried to do something fancy like you had above and just match with
something like

passwd kerberos (.+)@BX.PSU.EDU $1 BX.PSU.EDU

but gave up as backrefs didn't quite seem to be working correctly

We also have some javascript that appends the realm to the login
variable before submitting, which plays into our use of a drop-down
dialog to allow the user to select the realm to login to. You could
probably do something similar to strip off your 'default' realm before
submission if the user inputs that.

--andy

On Tue, Apr 21, 2009 10:29 AM, Andrew Mortensen <admorten@...> wrote:
>>> Does it work if you move the CosignGetKerberosTickets and
>>> CosignKerberosSetupGss directives outside of that Location block
>>> into the vhost context?
>>>       
>> Yes, this does work.
>>     
>
> 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.
>   


For anyone who is having this problem with directives in Location 
blocks, I've had a similar problem with mod_authnz_ldap under Apache 
HTTPD 2.2.9.  In the mod_authnz_ldap case, Andrew's suggestion (above) 
worked, but what also worked was keeping the directives in the Location 
block and adding the same directives in the corresponding Directory 
stanza (if there is one).


For example, if you have

<Location /some/path>
    # some directives
</Location>

And

DocumentRoot /var/www-secure/htdocs

Try keeping the above directives and adding

<Directory /var/www-secure/htdocs/some/path>
    # same directives here as in Location block
</Directory>

(Make sure that /var/www-secure/htdocs/some/path exists, of course, even 
if it is empty).

I'd be very curious as to whether this works with mod_cosign.  If anyone 
is able to try it, please let me know.

                Mark Montague
                ITCS Web/Database Team
                The University of Michigan
                markmont@...

On 21 Apr 2009, at 19:05, Mark Montague wrote:

> For anyone who is having this problem with directives in Location  
> blocks, I've had a similar problem with mod_authnz_ldap under Apache  
> HTTPD 2.2.9.  In the mod_authnz_ldap case, Andrew's suggestion  
> (above) worked, but what also worked was keeping the directives in  
> the Location block and adding the same directives in the  
> corresponding Directory stanza (if there is one).
>
>
> For example, if you have
>
> <Location /some/path>
>     # some directives
> </Location>
>
> And
>
> DocumentRoot /var/www-secure/htdocs
>
> Try keeping the above directives and adding
>
> <Directory /var/www-secure/htdocs/some/path>
>     # same directives here as in Location block
> </Directory>
>
> (Make sure that /var/www-secure/htdocs/some/path exists, of course,  
> even if it is empty).
>
> I'd be very curious as to whether this works with mod_cosign.  If  
> anyone is able to try it, please let me know.

Doesn't work, I'm afraid...

<Location /test>
     CosignProtected On
     CosignGetKerberosTickets On
     CosignKerberosSetupGss On
</Location>
<Directory /var/www/html/test>
     CosignProtected On
     CosignGetKerberosTickets On
     CosignKerberosSetupGss On
</Directory>

Still results in no tickets and incorrect values for the directives in  
*cfg

Cheers
Toby


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

On Wed, Apr 22, 2009 4:42 AM, Toby Blake <toby@...> wrote:
> Doesn't work, I'm afraid...
>
> <Location /test>
>     CosignProtected On
>     CosignGetKerberosTickets On
>     CosignKerberosSetupGss On
> </Location>
> <Directory /var/www/html/test>
>     CosignProtected On
>     CosignGetKerberosTickets On
>     CosignKerberosSetupGss On
> </Directory>
>
> Still results in no tickets and incorrect values for the directives in 
> *cfg

Thanks for trying it, though.   Sorry about the red herring.

                Mark Montague
                ITCS Web/Database Team
                The University of Michigan
                markmont@...

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

On 22 Apr 2009, at 19:00, Andrew Mortensen wrote:

> 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.

Aha, very interesting.  A fix would be much appreciated.  Let me know  
if you want me to test anything.

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

It's mainly just to allow separation of services which need tickets  
from those that don't, i.e. not to have to get tickets if we don't  
need them.  It's certainly not a show-stopper though, now we know the  
way round it.

Cheers
Toby


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.