DotNEAuth: Die Nachrichtensignatur war falsch

Question

Ich bekomme eine "Nachrichtensignatur war eine falsche" Ausnahme, wenn ich versuche, mich mit Myopenid und Yahoo zu authentifizieren.

Ich verwende so ziemlich den ASP.NET -MVC -Beispielcode, der mit DotNEAuth 3.4.2 geliefert wurde

public ActionResult Authenticate(string openid)
{
    var openIdRelyingParty = new OpenIdRelyingParty();
    var authenticationResponse = openIdRelyingParty.GetResponse();

    if (authenticationResponse == null)
    {
        // Stage 2: User submitting identifier
        Identifier identifier;

        if (Identifier.TryParse(openid, out identifier))
        {
            var realm = new Realm(Request.Url.Root() + "openid");
            var authenticationRequest = openIdRelyingParty.CreateRequest(openid, realm);
            authenticationRequest.RedirectToProvider();
        }
        else
        {
            return RedirectToAction("login", "home");
        }
    }
    else
    {
        // Stage 3: OpenID provider sending assertion response
        switch (authenticationResponse.Status)
        {
            case AuthenticationStatus.Authenticated:
            {
                // TODO
            }
            case AuthenticationStatus.Failed:
            {
                throw authenticationResponse.Exception;
            }
        }
    }

    return new EmptyResult();
}

Arbeiten Sie gut mit Google, AOL und anderen. Yahoo und Myopenid fallen jedoch mit der folgenden Ausnahme in den Fall des AuthenticationStatus.

DotNetOpenAuth.Messaging.Bindings.InvalidSignatureException: Message signature was incorrect.
   at DotNetOpenAuth.OpenId.ChannelElements.SigningBindingElement.ProcessIncomingMessage(IProtocolMessage message) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\OpenId\ChannelElements\SigningBindingElement.cs:line 139
   at DotNetOpenAuth.Messaging.Channel.ProcessIncomingMessage(IProtocolMessage message) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\Messaging\Channel.cs:line 992
   at DotNetOpenAuth.OpenId.ChannelElements.OpenIdChannel.ProcessIncomingMessage(IProtocolMessage message) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\OpenId\ChannelElements\OpenIdChannel.cs:line 172
   at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestInfo httpRequest) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\Messaging\Channel.cs:line 386
   at DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.GetResponse(HttpRequestInfo httpRequestInfo) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\OpenId\RelyingParty\OpenIdRelyingParty.cs:line 540

Es scheint, dass andere das gleiche Problem haben: http://trac.dotnetopenauth.net:8000/ticket/172

Hat jemand eine Problemumgehung?

Answer 1

Es stellte sich heraus, dass dies ein Problem bei der Verwendung von DotnetOpenAuth in einer Webfarmumgebung war.

Wenn Sie Ihre OpenIdRelying -Party erstellen, stellen Sie sicher, dass Sie Null im Konstruktor übergeben.

Dadurch wird Ihre Website in den OpenID -staatenlosen oder "dummen" Modus versetzt. Es ist etwas langsamer für Benutzer, sich anzumelden (falls Sie es überhaupt bemerken), aber Sie vermeiden es, einen Irening -PartyApplicationStore zu schreiben, damit DotNetopenauth über Ihren Bauernhof arbeiten kann.

var openIdRelyingParty = new OpenIdRelyingParty(null);

Answer 2

All diese Diskussion dreht sich um die folgende Frage:

Wie stellt RELELING Party (RP) sicher, dass die Anfrage, die das Authentifizierungs -Token enthält, vom OP (OpenID -Anbieter) stammt, an den er die Anfrage des Benutzers weitergeleitet hat?

Die folgenden Schritte erklären, wie es passiert

1. Die Benutzeranfrage kommt zur Antwortpartei (RP), unsere Website in unserem Fall
2. Die Anwendungsspeicher speichert eine eindeutige Signatur, die diesem Benutzer in einem lokalen Signature Store (LSS) entspricht, und einbettet diese Signatur dann in die Nachricht ein und leitet diese Nachricht an OpenID Provider (OP) weiter.
3. Der Benutzer trifft seine Anmeldeinformationen ein und die OP authentifiziert seine Nachricht und leitet diese Nachricht, die die Signatur noch in ihr eingebettet ist, zurück zu RP.
4. RP vergleichen

Wenn das LSS (irgendwie) verschwindet, bevor die Nachricht von OP zurückkommt, gibt es nichts für RP, um die Signatur mit dem Benutzer zu vergleichen, und erbringt den Benutzer nicht und wirft Fehler aus: Die Meldungssignatur war falsch.

Wie kann LSS verschwinden:

1. ASP.NET aktualisiert den Anwendungspool
2. IIS wird neu gestartet
3. In der Webfarm wird die Nachricht von Anwendungen bedient, die auf verschiedenen Server gehostet werden

Zwei Lösungen für dieses Problem:

1. RP -Lauf ist im dummen Modus

   a. Es speichert und signiert nicht lokal und verwendet daher keinen Signaturvergleich, um sicherzustellen

   b. Sobald RP die Authentifizierungsnachricht vom O -OP erhalten hat, senden Sie die Nachricht die Nachricht zurück an OP und bitten Sie ihn zu überprüfen, ob er derjenige ist, der diesen Benutzer authentifiziert hat und der Urheber der Nachricht ist. Wenn OP antwortet ja, bin ich der Urheber dieser Nachricht und habe diese Nachricht erstellt, dann wird der Benutzer durch RP authentifiziert

2. Implementieren Sie Ihren eigenen Persistenzgeschäft, der nicht verschwindet, keine Rolle, was ASP.NET mit dem Prozess macht, ähnlich wie die Verwendung von SQL zum Speichern des Sitzungsstatus.

Answer 3

Wir haben dieses Problem durch Implementierung behoben IRelyingPartyApplicationStore (IOpenIdApplicationStore in neueren Versionen von DotNetopenauth) und Hinzufügen des Store -Klassennamens dem .config

<dotNetOpenAuth>
  <openid ...>
    <relyingParty>
      ...
      <store type="some.name.space.MyRelyingPartyApplicationStore, some.assembly"/>
    </relyingParty>
  </openid>
  ...
</dotNetOpenAuth>

Die Schnittstelle ist eine Zusammensetzung von zwei anderen Schnittstellen mit fünf Mitgliedern zusammen.

/// <summary>
/// A hybrid of the store interfaces that an OpenID Provider must implement, and
/// an OpenID Relying Party may implement to operate in stateful (smart) mode.
/// </summary>
public interface IOpenIdApplicationStore : ICryptoKeyStore, INonceStore
{
}

Wir haben den Dumb -Modus als schnelle Lösung verwendet, um ein Laufen zu erhalten, aber am Ende möchten Sie wahrscheinlich so etwas.