IIS and new Service Provider v2.5

[Martin B. Smith]

On 11/06/2012 01:13 PM, Cantor, Scott wrote:
> I suspect it's happening because of a tail match of something that ends in
> "st". What I would note is that I think they have safeHeaderNames turned
> off. That results in some slightly different logic for checking the names
> and is probably where the tail matching problem is showing up.

Hey Scott & all,

You're correct -- safeHeaderNames defaults to false, and many of these 
configurations are using older config files from previous versions of 
the SP where safeHeaderNames isn't specified at all.

I'm being told some folks have cast some suspicion on the following 
cookie as the place the SP software is detecting the "st:" --

Cookie: foo=bar; 
https%3a%2f%2fmy.ufl.edu%2fpsp%2fps%2femployee%2fempl%2frefresh=list:%20%3ftab%3dstaff_page%7c%3frefresh_all_pagelets%3dstaff_page%7c%3ftab%3duf_custom%7c%3frefresh_all_pagelets%3duf_custom%7c|

Is it possible there's a bug in parsing that cookie and somehow the SP 
thinks there's a header named "st:" being injected from ALL_HTTP? In any 
case, I'll file a bug and let you decide what to do from there. I'll 
also recommend safeHeaderNames be turned on.

Thanks,
-- 
Martin B. Smith, Systems Administrator
smithmb at ufl.edu - (352) 273-1329
UF Information Technology, CNS/Open Systems Group
University of Florida

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3740 bytes
Desc: S/MIME Cryptographic Signature
Url : http://shibboleth.net/pipermail/users/attachments/20121106/c87121e7/attachment.bin