OpenIdProvider.GetRequest() returns null

Question

As somewhat of a continuation of this question, I\'m having problems with dotnetopenauth.

I navigate to my relying party code and create the request, however when my pro

Answer 1

Your RP has very suspiciously odd code. While it is normal (in fact required) for the return_to and realm to both have the same Uri authority, the fact that the user-supplied identifier that you're passing in as the first parameter to OpenIdRelyingParty.CreateRequest has the same host and port as your relying party is very odd. Normally the identifier you pass in would be a URL hosted by the provider. Now, I don't know if port 3314 is your RP or your OP, but either way, one of these port numbers in your RP code looks wrong.

Secondly, discovery on the user identifier fails with a null reference exception (according to v2 of your RP logs). That would prevent the login request from ever reaching your Provider. The fact that your Provider is getting called but with a non-existent OpenID request suggests that http://localhost:3314/OpenId/ is actually your OP Endpoint (the URL of your OpenID Provider's action method that reads OpenID requests). That would be inappropriate. The URL you should pass to your OpenIdRelyingParty.CreateRequest method's first parameter should, again, be a user's OpenID URL -- not an OP Endpoint. Check out the OpenIdProviderMvc sample's User controller for an example of how to set up a user OpenID URL. Then use that URL as the first arg to CreateRequest and I think you'll be good.

Thirdly, once your Provider receives a non-null request, you can't always cast it to IAuthenticationRequest. Not all OpenID messages are authentication messages. Some are part of the underlying OpenID protocol. If you look at the OpenIdProviderMvc sample's OpenID controller, you should notice that there are conditional casts to deal with the different message types. You should have similar message handling in your controller.

Since you're going for the SSO scenario, the significant difference in your controller would presumably be:

1. your controller never responds with a redirect to a login page, but rather "magically" figures out who the user is.
2. your controller should check the IAuthenticationRequest.Realm property against a whitelist of the RPs included in your SSO web ring, and only provide positive assertions when the Realm qualifies. This mitigates the attack where once your server is set up, anyone could set up a site that quietly uses your OpenID Provider to identify a user of a random Internet web site if they belong to your org, which would violate their privacy.

Fourthly, the HTTP request that the OP is sending to your RP's "realm" URL is part of a process OpenID calls "RP discovery". It's there to mitigate "open redirector" attacks. You should adjust your RP's base URL to not redirect, but rather return an XRDS document when the RP discovery request comes in. You can still redirect for the normal browser case. You can see an example of how to do this in the OpenIdRelyingPartyMvc sample's HomeController.