使用WIF在.NET Web场中为多个电子商务网站实现SSO? [英] Implementing SSO in a .NET Web Farm for several e-commerce websites with WIF?

问题描述

我有一个我认为是一个相当复杂的问题，所以我会尽力在这里阐明它.

I have what I think is a fairly complicated question so I will do my best to articulate it here.

我正在寻找单点登录(SSO)解决方案.我知道那里有很多选择，但是当我添加了它们需要满足的标准时，大多数选择就被排除在外了.条件如下:

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.)必须将SSO添加到现有的系统"中.
2.)现有的系统"由"X"个网站组成.
3.)所有"x"网站都是电子商务.
4.)网站全部归Y公司所有，其95％的系统是在内部建立的.
5.)每个"X"个网站都在同一个Web场中.
6.)所有网站都共享以下组件:

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(数据访问层)
• 数据库(购物车，订单，用户，库存等)
• 身份验证(WebForms和MVC中的Forms Auth).

7.)为了使当前环境正常工作，机器密钥已经在负载平衡的服务器之间进行了同步(并且已经使用了一段时间).
8.)由于非常的大量流量，因此需要高可用性和稳定性.

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.

所有这些条件使我无法使用WIF和与我们现有的成员身份验证服务一起使用的自定义STS.诸如OpenID和其他开源解决方案之类的东西似乎都倾向于跨公司的互操作性.不需要或想要的.理想的解决方案将是100％内部的，并允许用户登录网站"1"，做他们想做的事，然后再访问网站"2"(也托管在负载均衡器后面，甚至可能位于同一负载均衡器上). Web服务器作为用户使用网站"1")，并且已经登录.

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:之所以被排除是出于以下几个原因，主要是因为 组织正在寻找内部" SSO并与之集成 外部网站或与外部网站一起使用的ID系统不是 期望的.
• CAS:在大多数情况下，这似乎也是一个不错的选择. 最终，由于它使用的技术(Java， Apache，Maven等...)将需要额外的精力和金钱来 了解，实施，支持和扩展(主要是.NET商店).
• OAuth:似乎更适合于公开受保护的数据 通过网络服务.完全定制 ( http://www.codeproject.com/KB/aspnet/CrossDomainSSOModel.aspx):A 完全自定义的方法的实施时间可能太长 这种方法更需要关注安全性.
• DotNetOpenAuth:依赖于/基于OpenID.

• 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.

所以问题是:鉴于负载均衡器和网站上已经共享的用户帐户数据，WIF是否可以在我们现有的环境中工作?还是有更好的方法?

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.

只是要澄清我要实现的目标(或者考虑到我已经完成的研究，我想尝试实现的目标)是:

Just to clarify what I am looking to achieve (or think I am trying to achieve given the research I've done) is:

当前设置(JPEG托管在保管箱上)
所需的设置(JPEG托管在保管箱上)

推荐答案

ADFS v2.0仅针对AD进行身份验证.如果您当前的身份验证方法是其他身份验证方法(例如SQL Server)，则需要自定义STS.

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.

这些应用程序都是ASP.NET吗?

Are these applications all ASP.NET?

如果是这样，则都需要使用WIF启用所有声明.

If so, they all need to be claims enabled using WIF.

如果不是，例如Java，您必须使用其他解决方案来保护它们，例如OpenSSO/Ping联合并将该产品与ADFS联合.

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.

如果使用经典ASP，则可以通过多种方法允许ADFS处理身份验证，但是授权是一个问题.角色将在Claims对象内部，Classic ASP无法访问这些对象.您也可以为此使用C2WTS.

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.

您要查看身份验证或授权，还是同时查看两者? ADFS提供了声明对象内的角色，因此您的程序中现有的授权机制可能必须更改.

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.

您可以负载均衡ADFS网站.

You can load balance ADFS sites.

ADFS当然可以在您所有站点上启用SSO.如果将来需要考虑这一点，它还可能允许您与其他站点/组织联合并通过Azure ACS使用外部凭据(例如Facebook).

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.

它还允许您与SharePoint 2010，CRM Dynamics 2010和Office 365集成，所有这些都已启用声明.

It also allows you to integrate with SharePoint 2010, CRM Dynamics 2010 and Office 365 all of which are claims enabled.

这篇关于使用WIF在.NET Web场中为多个电子商务网站实现SSO?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！