DotNotOpenAuth 提供商白名单/黑名单主机
我正在根据示例使用 DotNetOpenAuth 开发一个提供程序。我正在尝试将依赖方列入白名单/黑名单。它似乎忽略了列入黑名单的主机并允许依赖方进入。我已验证 UntrustedWebRequestHandler 正在从配置文件加载列入黑名单的主机。这是我的配置部分。
<dotNetOpenAuth>
<messaging>
<untrustedWebRequest>
<blacklistHosts>
<add name="localhost" />
</blacklistHosts>
</untrustedWebRequest>
</messaging>
</dotNetOpenAuth>
我还注意到 OpenIdWebRingSsoProvider 手动实现白名单，而不是依赖于 UntrustedWebRequestHandler。当作为依赖方运行时，UntrustedWebRequestHandler 是否仅处理白名单和黑名单？如果不是，我做错了什么？
I am developing a provider using DotNetOpenAuth based on the samples. I'm experimenting with whitelisting/blacklisting relying parties. It seems to be ignoring the blacklisted hosts and allowing the relying party in. I have verified that the UntrustedWebRequestHandler is loading the black listed host from the config file. Here's my config section.
<dotNetOpenAuth>
<messaging>
<untrustedWebRequest>
<blacklistHosts>
<add name="localhost" />
</blacklistHosts>
</untrustedWebRequest>
</messaging>
</dotNetOpenAuth>
I also noticed that the OpenIdWebRingSsoProvider implements white lists manually rather than depending on the UntrustedWebRequestHandler. Does the UntrustedWebRequestHandler only handle white listing and black listing when operating as a relying party? If not, what am I doing wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Web 配置的 untrustedWebRequest 部分仅根据请求的主机或 IP 地址限制出站 HTTP 请求。这就是为什么在 OpenID 提供商上设置它不会（必然）阻止依赖方，因为提供商并不严格必须向依赖方发送请求。此 .config 部分主要是为了保护您免受恶意 Internet 服务器的侵害，这些服务器故意尝试对您的服务器进行 DoS 攻击。例如，如果您正在编写 RP，由于用户可以直接输入 OpenID，因此他们可以输入仅接受 HTTP 请求的主机，并让它们悬在那里而不响应或关闭连接。如果这些足够了，您的服务器将耗尽资源。如果您发现一些服务器对您这样做，您可以在此处将它们列入黑名单。
如果您确实想控制连接到哪些服务（依赖方或提供商），则不应使用上述方法。正如您在 OpenIdWebRingSsoProvider 示例中看到的，您应该使用
IAuthenticationRequest.Realm（如果您是提供商）或IAuthenticationRequest.Provider.Uri（如果您是依赖方）。当然，还有其他过滤方法。如果您的组织中有一个大型 SSO Web 环，您可能希望过滤远程服务上的某些可发现的证书，而不是在整个环中硬编码 URL。The untrustedWebRequest section of your web config only limits outbound HTTP requests based on the host or IP address of the request. That's why setting it on an OpenID Provider does not (necessarily) block Relying Parties, since Providers don't strictly have to ever send a request to the Relying Party. This .config section is primarily to protect you from evil Internet servers that deliberately try to DoS attack your server. For example, if you're writing an RP, since OpenIDs can be entered directly by the user, they could enter a host that just accepts HTTP requests and lets them dangle there without responding or closing the connection. Enough of those and your server will run out of resources. If you found a few servers doing that to you, you could blacklist them here.
If you actually want to control which services to connect to (relying parties or providers) you should not use the above method. As you saw in the OpenIdWebRingSsoProvider sample, you should filter those yourself using the
IAuthenticationRequest.Realm(if you're a Provider) or theIAuthenticationRequest.Provider.Uri(if you're a Relying Party). There are other ways to filter, of course. If you have a large SSO web ring in your org, you may want to filter on some discoverable certificate on the remote service rather than hard-coding URLs throughout your ring.