DotNetOpenID - 防火墙背后的身份提供商？

Question

查看OpenID协议，似乎依赖方需要向身份提供商发送请求。在我们的情况下，这并不完全理想，因为身份提供者在防火墙后面 - 我们的服务器将无法发出请求。但是，访问我们网站的用户（客户端，例如javascript或重定向）将能够。所以我的问题是：OpenID是否支持防火墙后面的身份提供商？如果没有，是否有一种安全的方法来实现这一目标？

编辑：

客户端的防火墙后面有一个Web服务器。他们有员工访问我们的网站，因此能够访问我们的网站和他们位于防火墙后面的网络服务器 - 但是，我们的服务器无法访问。身份提供商位于其防火墙后面的网络服务器上 - 我们的应用程序（依赖方）需要能够使用此内部员工身份提供程序进行员工身份验证。

Answer 1

OpenID依赖方必须能够验证用户获得的断言是否真正来自OpenID提供商。否则你的RP对简单的攻击很开放。

传统的签名验证要求RP服务器直接联系OP服务器。由于在您的情况下这是不可能的，因此您唯一的选择是在RP和OP之间硬编码共享关联秘密。您为该关联组成一个关联句柄和一个加密密集的秘密，并告诉RP和OP有关它并且它永远不会过期。然后，您的RP发送的每个auth请求都必须要求OP使用该特定的关联句柄 当然，永不过期的协会会带来自身的安全风险。您可以通过确定它是HMAC-SHA256关联而不仅仅是HMAC-SHA1来缓解（部分）。

最后，用户标识符发现通常需要从RP到OP的直接HTTP连接，但这可以通过使用标识符委派（在非防火墙服务器上设置指向防火墙后面的OP的标识符）轻松避免。或者，对于专门的解决方案，您的硬编码发现结果（包括OP端点）的解决方案也很好。您必须小心阻止这会带来的所有安全风险（例如确保标识符确实来自您硬编码的URL集，否则人们可能会欺骗其他OP端点的身份。< / p>

由于您正在使用DotNetOpenAuth，您可以创建自己的IDirectWebRequestHandler类并在OpenIdRelyingParty.Channel.WebRequestHandler属性上设置它。这个处理程序将有机会拦截对[server-behind-firewall]的传出HTTP请求，并通过简单地合成您自己的HTTP响应来重定向请求，如果您只能这样，那么防火墙后面的服务器将产生的XRDS达到目标。每个OP应该只有两个XRDS文档（一个是OP标识符，另一个是OP声明的所有claim_id）。这应该在身份验证正常工作之前和之后获得您的发现。

Answer 2

我的问题不明确。

如果客户端能够访问防火墙后面的提供程序，则服务器也应该 - 使用与客户端相同的方法连接到同一端口。

如果无法从外部访问提供程序，那么它就像其他任何无法访问的服务器一样无用。

如果您的依赖方无法与服务器建立传出连接，则无法进行任何操作 - 必须至少有一条从RP到OP的直接请求。

总结：是的，依赖方必须能够连接到提供商。

Answer 3

RP和OP之间更清晰的替代方案而不是硬编码共享关联秘密，尝试使用ADFS天蓝色或本地，STS指向您的OpenID

Answer 4

发现您可以使用此方法创建客户端RP作为示例代码：code.google.com/p/openid-selector。我修改了代码以适应我们的情况，它似乎工作。需要注意的是，您不使用自动发现，而是需要对端点进行硬编码（在我的情况下这是完全可以接受的）。