我们的一位客户联系我们开发一个应用程序,和往常一样,范围日益扩大。

最初,它是作为一个仅限于公司网络内的专用应用程序开始的。用户身份验证是通过获取用户的 Windows 登录名并使用 SQLServer 数据库来托管访问权限来建立的。一切都很简单。

他们现在想要以下内容:
- 基于网络的应用程序
- 在公司网络外部托管的应用程序
- 用户身份验证以相同的方式工作(不使用密码,仅使用 Windows 登录)

更复杂的是,他们希望应用程序的各种功能可供另一个仅触发 HTTP 请求的应用程序使用。
- 用户登录公司网络
- 用户启动企业应用程序
- 用户处理客户详细信息
- 用户单击按钮
- 企业应用程序向我们托管的 Web 应用程序发出 HTTP 请求
- HTTP 请求包括必要的身份验证和客户详细信息
- 用户身份验证“自动”完成(无需人工参与)
- 客户数据安全传输

他们非常希望我们为他们做这件事,因为我们最初的方法正是他们想要的。尽管此类托管网络应用程序不是我们的专长,但他们仍然希望我们这样做。所以我现在向专家求助;
- 有人对如何解决这个问题有什么建议吗?
- 有人对可能要避免的陷阱有任何警告吗?

有帮助吗?

解决方案

基本上他们谈论的是联合访问。您将在其网络内托管一个身份验证点,该身份验证点又将令牌转发到您的应用程序,该应用程序解析它并允许(或停止访问)。这是相当标准的,MS 为此提供了良好的基础 日内瓦框架. 。这也适用于 Web 服务调用,前提是他们可以更改其应用程序以使用 WSFed 作为协议并与安全令牌服务对话,安全令牌服务会默默地发出身份验证令牌。在大多数情况下,您将为此使用 SAML。它还具有额外的好处,即身份验证详细信息永远不会超出其公司网络。

基于证书的身份验证的建议很有趣,但在推出 PKI 基础设施方面需要做更多工作。这可能代价高昂。

CardSpace 不起作用——它并不像他们想要的那样安静。OpenID 也不是一个启动者,它也不是沉默的。

如果您正在查看 Azure,则需要额外加分 - Azure 的身份验证位也在底层使用 SAML/WSFed,并且其中包含一些Geneva。因此,如果您迁移到云,那么您的每个客户只需在其网络中配置一个登录页面 - 您所要做的就是信任该页面向您颁发身份验证令牌并根据您的规则解析它们。

其他提示

也许 WCF 通信与基于证书的身份验证,即对于使用该服务的外部用户,公司向他们提供有效的证书。这样就不需要用户名密码,而是直接引导用户通过。

你已经看过了吗 SAML?

查看 Windows 卡空间 因为它确实与您的 Windows 登录集成并允许它们所需的 SSO 场景。

根据应用程序的构建方式,您可以修改 web.config 中的 machineKey 以允许通过单点登录 (SSO) 进行 AJAX 调用。这将涉及公司网络内的一个小型 asp.net 应用程序,只是为了发出身份验证令牌并重定向到您的托管应用程序。

如果两个应用程序共享相同的 machineKey,那么 ASP.NET 身份验证系统将很乐意允许用户进入您的托管应用程序。

这种方法存在一些问题:

  • 您在系统中引入了另一个依赖项(公司网络内的身份验证应用程序)。这将是一个简单的应用程序,但如果您没有访问权限,则在尝试诊断问题时将遇到问题。
  • 您需要将托管服务与身份验证应用程序位于同一域中(以便传递 HTTP cookie 中的身份验证票证。)
  • 您还需要托管服务的 SSL 证书来保护信息。(本身并不是一个缺点,无论如何你可能都想这样做。)
  • 因为您和您的客户端将拥有共享的 machineKey,所以您将把应用程序的实例绑定到该特定客户端。

我会为此使用私有 OpenID 提供商/服务器。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top