1

我的组织有几个面向 Web 的 ASP.NET Web 窗体应用程序。他们目前使用启用了模拟的 Windows 身份验证。Web 应用程序在内部托管，但通过不同的域公开，例如 www.abc.com 和 www.xyz.org。

一个新的要求是，将为这些应用程序的所有用户提供一个登录页面，以便通过它登录。

提出的一些解决方案是：

  • 实现由 Active Directory (DotNetOpenAuth) 支持的 OpenId Provider，修改现有应用程序以成为此 OP 的依赖方。
  • 通过 MS Forefront 威胁管理网关实施 SSO。

我没有这两个方面的经验。提议的解决方案是否可行？各自的优缺点是什么？还有其他可能更合适的解决方案吗？

4

1 回答 1

3

OpenId Provider 是一个相当不错的主意。这将是一条更简单的路线，并且网络上有一些很好的细节。

您可能还想查看 Active Directory 联合身份验证服务。

http://msdn.microsoft.com/en-us/library/bb897402.aspx

转向托管解决方案的企业寻求实施联合服务的情况并不少见，这是微软在设置和创建 Azure 时所期望的——对企业友好。

他们在这里整理了一份综合指南，虽然与您的问题没有直接关系，但确实包含有关联合服务背后技术的大量详细信息。

http://msdn.microsoft.com/en-us/library/windowsazure/hh127796.aspx

有关更多想法和信息，特别是利弊，请查看这些文章，它们会更深入地回答它：

http://technet.microsoft.com/en-us/magazine/ff721824.aspx

http://windowsitpro.com/active-directory/ease-cloud-security-concerns-federated-identity

http://www.csoonline.com/article/221034/the-truth-about-federated-identity-management

一些 DotNetOpenAuth 想法：

http://www.codeproject.com/Articles/325228/Choosing-technologies-for-NET-project

http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/7a1c4e0c-346c-4008-9e5c-87ba1273b2aa/

最后，我们亲自为我的团队解决方案之一选择了 OpenAuth。一旦我们花时间真正理解 RFC（这并不容易，但值得花时间去做），实现就相当轻松了。网络上还有大量资源可以用来掌握实现的窍门。

于 2013-04-16T02:39:41.927 回答