25

I have two domains, domain1.com and domain2.com pointing at the same asp.net website which uses asp.net build in form authentication. The problem is that even if the domains point to the same website the user only get authenticated for one domain at a time. So if he uses www.domain1.com first and then visits www.domain2.com it's the same website in the back but he only is authenticated for www.domain1.com. The same thing happens if he uses www and not www when visiting the sites.

This is what I use to login:

FormsAuthentication.RedirectFromLoginPage(username, cookie.Checked);

To check login:

User.Identity.IsAuthenticated

How can I make the user gets authenticated for all domains that points to the same website?

Martin
  • 1,675
  • 11
  • 34
  • 46
  • The authentication cookie, like most cookies, are stored by domain to avoid cross-domain pollenation and impersonation. Why would you want to do this? – Lazarus Jan 13 '10 at 12:56
  • 3
    Because sometimes you have multiple sites you want the user to be able to use seamlessly, without having to log into each one separately. – Zhaph - Ben Duguid Jan 13 '10 at 13:06
  • Why not follow the StackOverflow methodology and use an external authentication provider such as OpenID. – Lazarus Jan 13 '10 at 13:14
  • 1
    You'd still need a mechanism to transfer the ticket to the second domain, even if you use OpenID - when SO was using UserVoice.com for it's bug/issue tracking, I still had to log in there even though I was using the same OpenID provider on both sites... – Zhaph - Ben Duguid Jan 14 '10 at 11:00

3 Answers3

45

What you're after is a Single Sign-on solution.

As ASP.NET authentication is at it's heart generally cookie based, there are two things to look at:

  1. Set your cookies correctly.
  2. Bounce your users to the alternative domain during signup.

Looking at both of these in more depth:

1. Setting cookies correctly

You need to ensure that ASP.NET is writing the authentication ticket cookies to the root domain, rather than the explicit domain this is done using the domain attribute of the forms element:

<forms 
   name="name" 
   loginUrl="URL" 
   defaultUrl="URL"
   domain=".example.com">
</forms>

You should set your domain to ".example.com" - note the leading period - this is the key. This way requests to example.com and www.example.com will both read the cookie correctly, and authenticate the user.

2. Bounce users to the alternative domain

What we have implemented on a few sites that use a single sign on is a round trip login process. The user authenticates on the first domain, we encrypt the login details, and redirect them to a known page on the second domain, log them in there, and then redirect back to the original server.

This client side redirection is important - cookies are only written when there is a response back to the client, and the browser has to visit the second domain to actually see the cookies.

Other details to consider in this sort of set-up:

  1. You probably want to have a timeout on the encrypted sign-in details - so that recalling that URL from the browser history doesn't automatically log the user in.
  2. If the domains are on different servers, you will need to ensure that either the machine keys are configured the same, so that you can encrypt and decrypt the details correctly, or use some other shared key.
  3. You will probably want to have a mechanism in place to recall the users ReturnUrl from the original server so that you can send them back to the correct place.

You could also take a look at "Forms Authentication Across Applications"

Zhaph - Ben Duguid
  • 26,785
  • 5
  • 80
  • 117
  • I know this question is old but I'm struggling with a similar situation. I am creating a mobile site and I need it to share authentication with the main site (an existing site). I followed the suggestions in the article you linked at the end but still no luck. I tried adding the `domain=".example.com"` attribute (replaced with the domain of the main site), but now authentication doesn't seem to be working at all. (Logging off has no effect, I even cleared out the browsers cookies.) I'd consider paying a reasonable consulting fee if you could spend some time helping me. – Jonathan Wood Nov 23 '14 at 21:36
  • Step 2 sounds a bit fishy... encrypt login details & redirect them to a known page on the second domain.... hmmm... a hacker could potentially intercept the encrypted data between your server & the client, then log into the victim's account from the 2nd domain using that encrypted data. They wouldn't even have to decrypt the data. They'd just use your client-side javascript code and inject the encrypted data into your own system, and then compromise it. Even if you made that encrypted data expire within milliseconds, the hacker could be quicker than the user being redirected. – Mark Entingh May 12 '15 at 13:59
  • Hi Mark - indeed - ideally all of this should be over SSL - which should mitigate most of those concerns - indeed the encrypted data has to live longer than milliseconds as we're talking network traffic and latency. Not sure where the JavaScript assumption came from (I could have been more specific) we were issuing `302` redirects as a response which would get the browser to issue the appropriate request to the next server in the chain - however if I recall correctly this was still relying on query strings - hence the use of SSL. Then we were more limited to SSL compromises. – Zhaph - Ben Duguid May 12 '15 at 17:51
  • @JonathanWood the `domain` attribute should not have a period (full stop) in it. set it to `domain="example.com"` and it should work. – hynsey Dec 21 '17 at 11:09
  • @hynsey that depends on how you are hosting your site. If it's on `www.example.com` setting the cookie domain without the period will not match your host and the cookie will be rejected, in which case you should set it to either `www.example.com` or just `.example.com` to match all sub-domains. – Zhaph - Ben Duguid Dec 21 '17 at 11:36
  • @Zhaph-BenDuguid - that was my point. but we seem to differ on how to apply this. In my experience (I currently run a domain, with 3 sub-domains using Forms Auth), I have to set the `domain` attribute to the master domain only, without the full stop. All sub-domains accept the auth cookie in this setup. – hynsey Dec 22 '17 at 14:29
3

You could try setting cookieless="true".

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
-4

You should read Explained: Forms Authentication on MSDN. They cover Cross-Domain Authentication.

Filip Ekberg
  • 36,033
  • 20
  • 126
  • 183
  • 5
    @Filip, where in that doc does it refer to cross-domain authentication? I've skimmed the doc and can't find any info beside the points that would seem to preclude cross-domain authentication. There is a link to an article talking about authentication across multiple AD domains which is obviously a different problem space. – Lazarus Jan 13 '10 at 13:08