DotNetOpenID - Identity Provider behind a firewall?

Question

Hello,

Looking at the OpenID protocol, it appears that the relying party needs to send a request to the identity provider. In our situation, this is not exactly ideal since the identity provider is behind a firewall-- our server will not be able to make the request. However, the user accessing our website (client-side, e.g. javascript or redirects) would be able to. So my question is this: does OpenID support an identity provider behind the firewall? If not, is there a secure way of accomplishing this?

EDIT:

The client has a web server behind their firewall. They have employees that visit our website and thus are able to visit our site and their webserver which resides behind their firewall-- our server, however, would not be able to. The Identity Provider resides on their webserver, behind their firewall-- our application (Relying Party) needs to be able to use this internal employee Identity Provider for their employee authentication.

Thanks! Josh

Answer 1

Your question isn't clear to me.

If a client is able to access the provider that is behind firewall, the server should also be -- it connects to the same port, using the same method as a client.

If the provider isn't accessible from the outside, then it's useless, like any other inaccessible server.

If it's your relying party can't make outgoing connections to the server, then nothing can be done -- there must be at least one direct request from the RP to the OP.

In summary: yes, the relying party must be able to connect to the provider.

Answer 2

Found out that there is a way you can create a client-side RP using this as sample code: code.google.com/p/openid-selector . I modified the code to fit our situation and it seems to work. The caveat here is that you do not use auto-discovery and instead are required to hard-code the endpoint (which is perfectly acceptable in my situation).

Josh

Answer 3

OpenID relying parties must be able to verify that the assertion the user obtained is genuinely from the OpenID Provider. Otherwise your RP is wide open to simple attacks.

Traditionally signature verification requires that the RP server contact the OP server directly. Since this is impossible in your case, your only alternative is to hard-code a shared association secret between RP and OP. You make up an association handle and a cryptographically strong secret for that association, and tell the RP and OP about it and that it never expires. Then every auth request your RP sends must ask the OP to use that particular association handle.
Of course an association that never expires carries security risks of its own. You can mitigate that (partially) by being sure it's an HMAC-SHA256 association rather than just HMAC-SHA1.

Finally, user identifier discovery typically requires a direct HTTP connection from RP to OP, but this can be easily avoided by using identifier delegation (set up identifiers on a non-firewalled server that point to the OP behind a firewall). Alternatively your solution of hard-coding discovery results including the OP Endpoint is just fine too for a specialized solution. You've got to be careful to block all the security risks that this opens up though (like making sure the identifier really is from the set of URLs that you're hard-coding, otherwise people can spoof identities from other OP endpoints.

Since you're using DotNetOpenAuth what you can do is create your own IDirectWebRequestHandler class and set that on your OpenIdRelyingParty.Channel.WebRequestHandler property. This handler will have the opportunity to intercept outgoing HTTP requests to [server-behind-firewall] and "redirect" the request by simply synthesizing an HTTP response of your own that is the XRDS that the server behind the firewall would produce if you could only reach it. There should only be two XRDS documents per OP (one is the OP Identifier and the other would be all the claimed_id's that the OP asserts). That should get your discovery both before and after authentication working correctly.