我们的客户已经联系我们开发应用程序,并且像往常一样,范围日益扩大。
最初,它最初是作为专用应用程序限制在其公司网络中。通过获取用户的Windows登录并使用SQLServer数据库来托管访问权限来建立用户身份验证。一切都很直接。
他们现在想要以下内容:
- 基于Web的应用程序
- 在公司网络之外托管的申请
- 用户身份验证以相同的方式工作(不使用密码,只使用Windows登录)
为了进一步复杂化,他们希望应用程序的各种功能可以被另一个触发HTTP请求的应用程序使用。
- 用户登录公司网络
- 用户启动公司申请
- 用户处理客户详细信息
- 用户点击按钮
- 企业应用程序向我们的托管Web应用程序发出HTTP请求
- HTTP请求包括必要的身份验证和客户详细信息
- 用户认证“自动”完成(无人参与)
- 安全传输客户数据
他们非常希望我们为他们这样做,因为我们最初的方法非常符合他们的要求。他们仍然希望我们这样做,即使这样的托管网络应用程序不是我们的特殊性。所以我现在接近专家;
- 有没有人对如何解决这个问题有任何建议?
- 有没有人对可能存在的陷阱有任何警告?
答案 0 :(得分:2)
基本上他们谈的是联合访问。您将在其网络中托管一个身份验证点,该身份验证点会将一个令牌转发给您的应用程序,该应用程序会对其进行解析并允许(或停止访问)。这是非常标准的,MS在Geneva Framework中为此提供了良好的基础。这也适用于Web服务调用,前提是他们可以更改其应用程序以将WSFed用作协议,并与安全令牌服务进行通信,该服务以静默方式发出身份验证令牌。在大多数情况下,您将使用SAML。它还具有额外的奖励,即身份验证细节永远不会超出其公司网络。
基于证书的身份验证的建议很有意思,但在推出PKI基础结构时需要做更多的工作。这可能是昂贵的。
CardSpace不起作用 - 它似乎并不像他们想要的那样沉默。 OpenID也是一个非首发,它也没有沉默。如果您正在查看Azure的额外点 - Azure的身份验证位也使用SAML / WSFed,并且其中包含日内瓦。因此,如果您迁移到云,那么您的每个客户都只需要在其网络中配置登录页面 - 您只需要信任该页面向您发出身份验证令牌并根据您的规则解析它们。
答案 1 :(得分:0)
可能WCF与基于证书的身份验证通信,即对使用该服务的外部用户,公司为他们提供有效证书。这不需要用户名密码,而是让用户直接通过。
答案 2 :(得分:0)
您是否已查看SAML?
答案 3 :(得分:0)
查看Windows CardSpace,因为它确实与您的Windows登录集成,并允许他们需要的SSO方案。
答案 4 :(得分:0)
根据应用程序的构造方式,您可以在web.config中使用machineKey,以允许使用单点登录(SSO)进行AJAX调用。 这将涉及企业网络中的一个小型asp.net应用程序,只是为了提供身份验证令牌并重定向到您的托管应用程序。
如果这两个应用共享相同的machineKey,那么asp.net身份验证系统将很乐意允许用户进入您的托管应用。
这种方法存在问题:
答案 5 :(得分:-1)
我会使用私有的OpenID提供程序/服务器。