Single sign on cookie removed by anti spyware software

Question

We have a single sign on implementation for a family of websites where the authentication cookie comes from the root domain (e.g. bar.com), allowing them to be logged into a child domain (e.g. foo.bar.com). The implementation is in C# using standard .net forms authentication.

Unfortunately, some of our users are having their authentication cookies deleted by anti spyware software. I've been able to recreate this situation by using PC Tools Anti Spyware and IE8.

The practical upshot is that users log into the site, navigate to another page, and then get asked to log in again.

The cookie is flagged as a low risk tracking cookie by the anti spyware software.

Is there any way to make the cookie more palatable to the apparently rather picky tastes of our user's anti spyware software?

Update:

I've looked into the leading "." issue and it's a red herring. IE Doesn't care and, as I found out via this post, the RFC 2965 Specification requires that implementors supply a leading dot.

Further reading led me to the article "Privacy alert: Cookie variants can be used to skirt blockers, anti-spyware tools". Essentially, many websites are using subdomains as a way hide tracking cookies.

It looks like some anti-spyware software will respect P3P (Platform for Privacy Preferences) declarations on the parent domain. Unfortunately, due to lack of support from browser implementors, work has been suspended on P3P.

At this stage I think the solution to the problem will be as one user suggested: the subdomain will need to create its own authentication cookie.

Answer 1

You could check that your auth cookie is using the domain .bar.com which should work at www.bar.com, foo.bar.com, etc.bar.com.

This exact behavior is up to the browser but this is the common practice to allow the same cookie across multiple sub-domains. Note that if your auth cookie originally set www.bar.com then a good browser should reject it for foo.bar.com but not for foo.www.bar.com

Am I making any sense? :-)

Update: Looks like you can override the domain in the <forms section of your Web.config, here's a link. I'd start there.

Answer 2

You may examine default transports in SAML SSO protocol specifications to have more ideas. Archive with all docs is here http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip look into "Assertions and protocols" for protocol description and "Bindings" for possible transports (in particular at redirect and POST).

Common idea there is to somehow query SSO server if current user is authenticated and then cache that status with own cookie. This way every application sets only cookies on own domain.

Answer 3

I built a system like this. There is one domain that does the login (auth site). If the login is successful it redirects the user from the auth site to the site that initiated the login with a one off token. Then that site sets its own cookie and bobs your uncle. When you logout you have to go directly to the auth site which deletes the cookie as part of the redirect back to the site. Your site then deletes its own cookie. Hahaha hope that makes sense!