5

我们在 IIS 7.5 公共服务器上使用表单身份验证运行 Saas ASP.NET 3.5 Web 应用程序，为数千名用户提供受保护的内容。我们还有一些运行 ASP.NET MVC 2 的子应用程序。

用户名和密码存储在我们的数据库中，每个用户都附加了角色和组，并定义了权限和访问权限。

现在，我们还被要求促进通过 Active Directory 进行简单的 SSO 登录，这样用户就不必输入用户名和密码两次即可登录。这些用户将来自不同的网络和域。

从我们的服务器到 LDAP 服务不应发生任何用户“同步”。我们不确定是否需要与 LDAP 进行任何通信，因为所有用户都将在我们的系统中创建并在那里维护。我们的大多数用户都将使用表单身份验证。

从这里开始，我们不确定哪条路是最好的选择。对于我们的场景，“最佳实践”的继续方式是什么？

4

2 回答 2

5

简单的答案是 SAML。它被认为是“最佳实践”，许多大型 SAAS 提供商都支持它。

SAML 协议定义了多个系统之间的单点登录流程。它使用证书在系统之间建立信任。您的应用程序接受来自其他系统的包含属性（用户 ID、姓名、电子邮件地址等）的断言。您的应用会将用户映射到您的用户商店。

在 .NET 世界中，有多种选择。您可以找到一个实现 SAML 的库（ComponentSpace 有一个）并将其挂接到 ASP.NET 身份验证中。您可以使用 Windows 识别框架 (WIF) 创建自己的。这是大量 WIF 视频http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/。你可以试试 IdentityServer http://thinktecture.github.io/

根据您的应用程序必须有多安全，您可以选择一个简单的选项，即使用简化的方法从受信任的网络传递用户 ID。我见过允许通过 URL 参数或表单字段发送用户 ID 的应用程序。当然，这是非常不安全的，而且您要承担更大的风险，因为两个网络之间的信任不是通过密码强制执行的。您可以通过检查引用字符串或 IP 地址（例如，如果您可以隔离公司网络的 IP 范围）来缓解它。但是您仍然对欺骗持开放态度，因为任何用户都可以通过简单地替换 HTTP 请求中的用户 ID 来冒充他人。

它可能无法完全回答您的问题，但希望为您指明正确的方向。

于 2013-04-15T19:02:23.890 回答
1

我建议研究 ADFS 2.0，它在声明映射方面非常强大，并且可以与 AD 一起使用：http: //msdn.microsoft.com/en-us/magazine/ee335705.aspx

您要做的是应用程序的令牌消耗部分，该部分将接收并解析在身份验证循环后返回到您的 Web 服务器的最终声明。

于 2013-04-15T19:05:26.887 回答