1

我们的一个客户找我们开发一个应用程序，并且像往常一样，范围日益扩大。

最初，它是作为限制在其公司网络中的专用应用程序开始的。通过获取用户的 Windows 登录名并使用 SQLServer 数据库托管访问权限来建立用户身份验证。一切都很直截了当。

他们现在想要以下内容：
- 基于 Web 的
应用程序 - 在公司网络之外托管的应用程序
- 用户身份验证以相同的方式工作（不使用密码，只使​​用 Windows 登录）

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

他们非常渴望我们为他们做这件事，因为我们最初的方法正是他们想要的。即使此类托管网络应用程序不是我们的专长，他们仍然希望我们这样做。所以我现在联系专家；
- 有人对如何解决这个问题有任何建议吗？
- 是否有人对可能要避免的陷阱有任何警告？

4

6 回答 6

2

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

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

CardSpace 不起作用——它不像他们想要的那样保持沉默。OpenID 也不是入门者，它也不是沉默的。

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

于 2009-03-02T11:55:24.230 回答
0

也许 WCF 通信与基于证书的身份验证，即使用公司为他们提供有效证书的服务的外部用户。这将不需要用户名密码，而是让用户直接通过。

于 2009-03-02T11:48:52.860 回答
0

您已经看过SAML了吗？

于 2009-03-02T11:49:23.670 回答
0

查看Windows CardSpace，因为它确实与您的 Windows 登录集成并允许他们需要的 SSO 场景。

于 2009-03-02T11:52:25.410 回答
0

根据您的应用程序的构建方式，您可以在 web.config 中调整 machineKey 以允许通过单点登录 (SSO) 进行 AJAX 调用。这将涉及企业网络中的一个小型 asp.net 应用程序，仅用于分发身份验证令牌并重定向到您托管的应用程序。

如果这两个应用程序共享同一个 machineKey，那么 asp.net 身份验证系统将很高兴地允许用户进入您托管的应用程序。

这种方法存在问题：

  • 您在系统中引入了另一个依赖项（企业网络中的身份验证应用程序）。这将是一个简单的应用程序，但如果您无权访问，则在尝试诊断问题时会遇到问题。
  • 您需要将托管服务与身份验证应用程序放在同一域中（因此 HTTP cookie 中的身份验证票证会被传递。）
  • You'll also need an SSL certificate for your hosted service to secure the information. (Not really a downside per-se, you'd probably want to do this anyway.)
  • Because you and your client will have a shared machineKey, you will tie down an instance of your app to that particular client.
于 2009-03-02T13:11:01.100 回答
-1

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

于 2009-03-02T11:45:28.047 回答