使用 WIF 在 .NET Web Farm 中为多个电子商务网站实施 SSO？
我有一个我认为相当复杂的问题，所以我会尽力在这里阐明它。
我正在寻找单点登录 (SSO) 解决方案。我知道有很多选择，但在我添加了它们需要满足的标准时排除了其中的大多数。以下是标准：
1.) SSO 必须添加到现有“系统”中。
2.) 现有“系统”由“X”个网站组成。
3.) 所有“x”网站都是电子商务网站。
4.) 这些网站均归 Y 公司所有，该公司 95% 的系统是内部构建的。
5.) “X”个网站中的每一个都位于同一个网络场中。
6.) 所有网站共享以下组件：
- DAL（数据访问层）
- 数据库（购物车、订单、用户、库存等）
- 身份验证（WebForms 和 MVC 中的表单身份验证）。
7.) 为了使当前环境正常工作，机器密钥已经在负载平衡服务器之间同步（并且已经同步了一段时间）。
8.) 由于流量非常，因此需要高可用性和稳定性。
所有这些标准都引导我走上了 WIF 和自定义 STS 的道路，以便与我们现有的会员身份验证服务一起使用。像 OpenID 和其他开源解决方案这样的东西似乎都倾向于跨公司的互操作性；这是不需要或不想要的。理想的解决方案将是 100% 内部的，并允许用户登录网站“1”，做他们想做的任何事情，然后转到网站“2”（也托管在负载均衡器后面，甚至可能在同一个负载均衡器上） Web 服务器（如用户访问网站“1”）并已登录。
以下是我研究过的替代方法的列表以及排除它们的相应原因（或者我应该重新考虑其中一些替代方法？）。
- OpenID：这个被排除有几个原因，主要是因为我 组织正在寻找“内部”SSO 并与 外部网站或与外部网站一起使用的 ID 系统不是 想要的。
- CAS：在大多数情况下，这似乎也是一个不错的选择。 最终它被排除了，因为它使用的技术（Java、 Apache、Maven 等...）将需要额外的努力和金钱来 理解、实施、支持和扩展（主要是 .NET 商店）。
- OAuth：似乎它更适合公开受保护的数据 通过网络服务。完全定制 (http://www.codeproject.com/KB/aspnet/CrossDomainSSOModel.aspx): 一个 完全定制的方法可能需要太长的实施时间 而且这种方法更关心安全性。
- DotNetOpenAuth：依赖/基于 OpenID。
所以问题是：考虑到负载均衡器和跨网站已经共享的用户帐户数据，WIF 是否可以在我们现有的环境中工作，或者是否有更好的方法？
如果您需要任何说明，请告诉我。
编辑：
只是为了澄清我想要实现的目标（或者考虑到我所做的研究，我认为我正在努力实现的目标）是：
I have what I think is a fairly complicated question so I will do my best to articulate it here.
I am looking for a single sign on (SSO) solution. I am aware of many of the options out there but have ruled most of them out as I add criteria that they need to meet. Here are the criteria:
1.) The SSO must be added to an existing "system".
2.) The existing "system" consists of "X" number of websites.
3.) All of the "x" websites are e-commerce.
4.) The websites are all owned by company Y, for whom 95% of the system was built in-house.
5.) Each of the "X" number of websites is in the same Web Farm.
6.) All of the websites share the following components:
- DAL (Data Access Layer)
- Database (Carts, Orders, Users, Inventory, etc...)
- Authentication (Forms Auth in both WebForms and MVC).
7.) In order for the current environment to work, Machine Key's have already been synchronized among the load balanced servers (and have been for some time).
8.) High availability and stability is required due to a very large volume of traffic.
All of these criteria have led me down the path of WIF and a custom STS to use with our existing membership authentication services. Things like OpenID and other open source solutions all seem to lean towards cross company interoperability; Which is not needed or wanted. The ideal solution will be 100% internal and allow a user to log in on website "1", do whatever it is they want to do and then go to website "2" (also hosted behind the load balancer and potentially even on the same web server as the user was for website "1") and be logged in already.
Here is a list of alternative methods I have looked at and the corresponding reason for ruling them out (or should I re-consider some of these alternatives?).
- OpenID: This was ruled out for several reasons, mainly because my
organization is looking for "in-house" SSO and integration with
external websites or an ID system used with external websites is not
desired. - CAS: For the most part, this also seems like a decent alternative.
Ultimately it was ruled out because the technologies it uses (Java,
Apache, Maven, etc...) will require additional effort and money to
understand, implement, support, and extend (Primarily a .NET Shop). - OAuth: Seems like it is geared more towards exposing protected data
via web services. Totally Custom
(http://www.codeproject.com/KB/aspnet/CrossDomainSSOModel.aspx): A
totally custom approach may have too high of an implementation time
and security is more of a concern with this method. - DotNetOpenAuth: Dependant / based upon OpenID.
So the question is: will WIF work in our existing environment given the load balancer and the already shared user account data accross websites or is there a better approach?
Please let me know if you need any clarification.
EDIT:
Just to clarify what I am looking to achieve (or think I am trying to achieve given the research I've done) is:
Current Setup (JPEG hosted on dropbox)
Desired Setup (JPEG hosted on dropbox)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
ADFS v2.0 仅针对 AD 进行身份验证。如果您当前的身份验证方法是其他方法（例如 SQL Server），那么您需要自定义 STS。
这些应用程序都是ASP.NET吗？
如果是这样，它们都需要使用 WIF 启用声明。
如果没有，例如 Java，您将必须使用另一种解决方案（例如 OpenSSO / Ping Federate）保护它们，并将该产品与 ADFS 联合。
如果是经典 ASP，有多种方法可以让 ADFS 处理身份验证，但授权是一个问题。这些角色将位于经典 ASP 无法访问的声明对象内。您也可以使用 C2WTS 来实现此目的。
您正在考虑身份验证或授权或两者兼而有之？ ADFS 提供声明对象内的角色，因此程序中现有的授权机制可能必须更改。
您可以对 ADFS 站点进行负载平衡。
ADFS 当然可以在您的所有站点上启用 SSO。如果您将来需要考虑的话，它还可能允许您与其他站点/组织联合并通过 Azure ACS 使用外部凭据（例如 Facebook）。
它还允许您与 SharePoint 2010、CRM Dynamics 2010 和 Office 365 集成，所有这些都启用了声明。
ADFS v2.0 only authenticates against AD. If your current authentication method is something else (e.g. SQL Server) then you need a custom STS.
Are these applications all ASP.NET?
If so, they all need to be claims enabled using WIF.
If not, if e.g. Java you'll have to protect them with another solution e.g. OpenSSO / Ping Federate and federate this product with ADFS.
If Classic ASP, there are ways to allow ADFS to handle the authentication but authorisation is a problem. The roles will be inside a claims object which Classic ASP has no way of accessing. You could also use C2WTS for this.
Are you looking at authentication or authorisation or both? ADFS supplies the roles inside a claims object so the existing authorisation mechanism in your programs may have to change.
You can load balance ADFS sites.
ADFS can certainly enable SSO across all your sites. It also potentially allows you to federate with other sites / organisations and use external credentials (e.g. Facebook) via Azure ACS if that's something you need to consider in the future.
It also allows you to integrate with SharePoint 2010, CRM Dynamics 2010 and Office 365 all of which are claims enabled.