ASP.NET redirecting users credentials to regional sites

we have two identical websites. One located at apac.ourdomain.com and the other at eu.ourdomain.com. The only differences about these websites are one is hosted in Australia, and the other is in London. The databases they backed onto have identical schema, except one is in Australia, and the other is in London, each storing data related to our partners in the region.

What we want to do is implement some form of centralise landing page @ www.ourdomain.com using forms authe开发者_如何学JAVAntication. Once a partner logs on to www.ourdomain.com, we will redirect them to either the apac or the eu server. My challenge is how do I transfer the user credentials from the landing site to the regional site? By Credentials, I mean everything from their username to their roles / permissions. And once a user is redirected to the regional site, how do i get them back to the landing site should they required to modify their details?

I know I will need to have a centralised user details db for the landing site, but it is the communication to and from the regional site afterward that I'm uncertain about. Any pointers?

You could have only some basic information in this common database such as username and password or password hash as the case may be but none of the permissions and things. The permissions and other such information can/should reside in the respective regional databases.

When a user is authenticated you've essentially set a cookie. The cookie is typically encrypted. But it so happens that the encryption is machine specific. so expecting it to work one the other server won't work, unless you configure the machineKey in your config file http://msdn.microsoft.com/en-us/library/ff649308.aspx

The default ASP.NET settings ensure that forms authentication tickets are tamper proof and encrypted, and that ViewState is tamper proof. This ensures that any modification of the ViewState or authentication tickets either on the client's computer or over the network is detected when the server processes the data.

Cookies are domain specific and unless you specify the root domain when setting a cookie, it won't be available to sub domains.

In principal, lets say you set a cookie yourself. This cookies contained the userId as the value and a datetime. This information is encrypted and the cookie is set for the root domain. Then when you redirect to the regional website you can extract the cookie, decrypt it and "auto log-in" the user.

If you're relying on the FormsAuthentication framework to do all the work for you then you can't simply tweak a setting to get this working. Now you can use the FormsAuthentication concept and do you own authentication. But this might be too complicated if you're no very familiar with Http and ASP.NET and things.

Another alternative and probably better depending on how secure things need to be is to do what I described earlier with the difference that when a regional site receives this redirected page, you can confirm against the central database by making a regular http call using HttpWebRequest or similar to a handler on central web application to verify that the user was indeed given this cookie from your central system.

another option is why bother with multiple physical sites. Simply host a central system and depending onthe user that logs use, connect to a difference database and potentially other aspects change as well but there is only one instance of the system and one domain.