DotNotOpenAuth Provider white listing/blacklisting hosts

I am developing a provider us开发者_开发百科ing 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?

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 the IAuthenticationRequest.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.