Search code examples
.netasp.net-mvc-3c#-4.0openiddotnetopenauth

DotNetOpenAuth request without user discovery


I got an issue with an OpenId login with ASP.Net (MVC) and the DotNetOpenAuth library. The OpenId provider that I have to connect to delivers the same (static) response for OP-discovery and user-discovery requests. Because of this, the DotNetOpenAuth library always tells me, that authentification failed. The provider told me to disable the user-discovery request.

Can anyone help me how to do this with DotNetOpenAuth? I haven't found any solution yet.

This is how I connect to the OpenId provider:

var providerUrl= ConfigurationManager.AppSettings["OpenIdUrl"];
IAuthenticationRequest request = openId.CreateRequest(Identifier.Parse(providerUrl)); 
return request.RedirectingResponse.AsActionResult();

Solution

  • Thanks for researching the cause of the failure and communicating with the OP already. That should make things much quicker. The OP operator has an incorrectly configured OP. From the OpenID 2.0 spec section 11.2, we read:

    If the Claimed Identifier is included in the assertion, it MUST have been discovered by the Relying Party and the information in the assertion MUST be present in the discovered information. The Claimed Identifier MUST NOT be an OP Identifier.

    From the last sentence, we get that the "static" XRDS that is returned from the user identifier must not be an OP Identifier, yet it is, and from elsewhere in the spec we learn that OP Identifiers take precedence over user identifiers (which is why being an OP Identifier is forbidden here). The OP should fix the XRDS document they return from user identifiers to omit the OP Identifier service endpoint.

    Please forward the above to any faulty OP and ask them to correct their error.


    The following is not supported, nor advised, as it causes your relying party to stray from the OpenID 2.0 spec, violating a "MUST NOT" clause, and it may introduce security holes in your application:

    There is a way to configure a DotNetOpenAuth relying party to work even for these faulty OPs, the aforementioned disclaimer applies to this method. Add this snippet to your web.config file:

    <dotNetOpenAuth>
        <openid>
            <relyingParty>
                <security allowDualPurposeIdentifiers="true" />
            </relyingParty>
        </openid>
    </dotNetOpenAuth>
    

    If you used NuGet to install DotNetOpenAuth in your web application, that should be sufficient. But if you get errors about any of these tags not being recognized, you may need to merge this at the top of your web.config file:

    <configuration>
        <configSections>
            <section name="dotNetOpenAuth" type="DotNetOpenAuth.Configuration.DotNetOpenAuthSection" requirePermission="false" allowLocation="true"/>
        </configSections>
    </configuration>