When you authenticate the user, set the authentication cookie's domain to the second-level domain, i.e. parent.com. Each sub-domain will receive the parent domain's cookies on request, so authentication over each is possible since you will have a shared authentication cookie to work with.
Authentication code:
System.Web.HttpCookie authcookie = System.Web.Security.FormsAuthentication.GetAuthCookie(UserName, False);
authcookie.Domain = "parent.com";
HttpResponse.AppendCookie(authcookie);
HttpResponse.Redirect(System.Web.Security.FormsAuthentication.GetRedirectUrl(UserName,
False));
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:
- Set your cookies correctly.
- 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:
- 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.
- 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.
- 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"
Best Answer
The form authentication does not depend on the domain. It only depends on a unique
applicationNamefor filtering the records if you have a shared Membership database.