ASP.NET 将用户凭据重定向到区域站点
我们有两个相同的网站。一个位于 apac.ourdomain.com，另一个位于 eu.ourdomain.com。这些网站的唯一区别是一个位于澳大利亚，另一个位于伦敦。他们支持的数据库具有相同的架构，除了一个位于澳大利亚，另一个位于伦敦，每个数据库都存储与我们在该地区的合作伙伴相关的数据。
我们想要做的是使用表单身份验证实现某种形式的集中登录页面@ www.ourdomain.com。一旦合作伙伴登录 www.ourdomain.com，我们会将其重定向到 apac 或 eu 服务器。我的挑战是如何将用户凭据从登陆站点传输到区域站点？我所说的凭据是指从用户名到角色/权限的所有内容。一旦用户被重定向到区域站点，如果需要修改其详细信息，我如何让他们返回登陆站点？
我知道我需要为登陆站点建立一个集中的用户详细信息数据库，但我不确定之后与区域站点之间的通信。有什么指点吗？
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 authentication. 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在这个通用数据库中，您可能只有一些基本信息，例如用户名和密码或密码哈希（视情况而定），但没有权限和其他内容。权限和其他此类信息可以/应该驻留在各自的区域数据库中。
当用户通过身份验证时，您实际上已经设置了一个 cookie。 cookie 通常是加密的。但碰巧加密是特定于机器的。因此，除非您在配置文件中配置 machineKey，否则期望它能够在另一台服务器上工作将无法工作
http://msdn.microsoft.com/en-us/library/ff649308.aspx
默认的 ASP.NET 设置确保表单身份验证票证防篡改和加密，并且 ViewState 防篡改。这可确保服务器处理数据时检测到客户端计算机上或网络上对 ViewState 或身份验证票证的任何修改。
Cookie 是特定于域的，除非您在设置 Cookie 时指定根域，否则子域将无法使用它。
原则上，假设您自己设置了一个 cookie。该 cookie 包含 userId 作为值和日期时间。此信息已加密，并且 cookie 是为根域设置的。然后，当您重定向到区域网站时，您可以提取 cookie、解密它并“自动登录”用户。
如果您依赖 FormsAuthentication 框架来为您完成所有工作，那么您不能简单地调整设置来使其正常工作。现在您可以使用 FormsAuthentication 概念并进行自己的身份验证。但如果您不太熟悉 Http 和 ASP.NET 之类的东西，这可能会太复杂。
另一种选择可能更好，具体取决于需要的安全程度，就是执行我之前描述的操作，不同之处在于，当区域站点收到此重定向页面时，您可以通过使用 HttpWebRequest 或类似工具进行常规 http 调用来对中央数据库进行确认到中央 Web 应用程序上的处理程序，以验证用户确实从中央系统获得了此 cookie。
另一个选择是为什么要费心去多个物理站点。只需托管一个中央系统，并根据日志使用的用户，连接到不同的数据库，其他方面也可能会发生变化，但系统只有一个实例和一个域。
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.