查看 OpenID 协议，似乎依赖方需要向身份提供者发送请求。在我们的情况下，这并不完全理想，因为身份提供者位于防火墙后面——我们的服务器将无法发出请求。但是，访问我们网站的用户（客户端，例如 javascript 或重定向）将能够。所以我的问题是：OpenID 是否支持防火墙后面的身份提供者？如果没有，是否有一种安全的方法来实现这一点？
编辑：
客户端在其防火墙后面有一个 Web 服务器。他们有员工访问我们的网站，因此能够访问我们的网站和位于其防火墙后面的网络服务器——但是，我们的服务器无法访问。身份提供者驻留在他们的网络服务器上，位于防火墙后面——我们的应用程序（依赖方）需要能够使用此内部员工身份提供者进行员工身份验证。
【问题讨论】：
标签： asp.net openid dotnetopenauth
OpenID 依赖方必须能够验证用户获得的断言是否真正来自 OpenID 提供者。否则，您的 RP 很容易受到简单攻击。
传统的签名验证需要 RP 服务器直接联系 OP 服务器。由于在您的情况下这是不可能的，您唯一的选择是硬编码 RP 和 OP 之间的共享关联秘密。您为该关联创建一个关联句柄和一个加密的强机密，并将其告知 RP 和 OP，并且它永不过期。然后，您的 RP 发送的每个身份验证请求都必须要求 OP 使用该特定关联句柄。
当然，永不过期的关联本身也存在安全风险。您可以（部分）通过确保它是 HMAC-SHA256 关联而不仅仅是 HMAC-SHA1 来缓解这种情况。
最后，用户标识符发现通常需要从 RP 到 OP 的直接 HTTP 连接，但这可以通过使用标识符委托（在指向防火墙后面的 OP 的非防火墙服务器上设置标识符）轻松避免。或者，您的硬编码发现结果解决方案（包括 OP 端点）也适用于专门的解决方案。您必须小心阻止由此带来的所有安全风险（例如确保标识符确实来自您硬编码的 URL 集，否则人们可以从其他 OP 端点欺骗身份。
由于您使用的是 DotNetOpenAuth，因此您可以创建自己的 IDirectWebRequestHandler 类并将其设置在您的 OpenIdRelyingParty.Channel.WebRequestHandler 属性上。此处理程序将有机会拦截到 [server-behind-firewall] 的传出 HTTP 请求，并通过简单地合成您自己的 HTTP 响应来“重定向”请求，该响应是防火墙后面的服务器将产生的 XRDS，如果您只能达到目标。每个 OP 应该只有两个 XRDS 文档（一个是 OP 标识符，另一个是 OP 断言的所有 claim_id）。这应该让您的发现在身份验证之前和之后都正常工作。
【讨论】：
我不清楚你的问题。
如果客户端能够访问防火墙后面的提供程序，那么服务器也应该——它使用与客户端相同的方法连接到相同的端口。
如果无法从外部访问提供程序，那么它就毫无用处，就像任何其他无法访问的服务器一样。
如果是您的依赖方无法与服务器建立传出连接，则无能为力——必须至少有一个从 RP 到 OP 的直接请求。
总而言之：是的，依赖方必须能够连接到提供者。
【讨论】：
比在 RP 和 OP 之间硬编码共享关联密钥更简洁的替代方法，尝试使用 azure 或本地 ADFS 以及指向您的 OpenID 的 STS
【讨论】：
发现有一种方法可以使用以下示例代码创建客户端 RP：code.google.com/p/openid-selector。我修改了代码以适应我们的情况，它似乎工作。这里需要注意的是，您不使用自动发现，而是需要对端点进行硬编码（这在我的情况下是完全可以接受的）。
【讨论】：