DotNetOpenAuth: Die Nachrichtensignatur war falsch

Question

Ich erhalte eine Ausnahme "Nachrichtensignatur war falsch", wenn ich versuche, mich mit MyOpenID und Yahoo zu authentifizieren.

Ich verwende so ziemlich das Beispielcode ASP.NET MVC, die 3.4.2

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 gut mit Google, AOL und andere mit DotNetOpenAuth kam. Allerdings fallen Yahoo und myOpenID in den AuthenticationStatus.Failed Fall mit folgenden Ausnahme:

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 

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

Hat jemand eine Abhilfe?

Answer 1

Es stellte sich heraus, dass dies ein Problem mit DotNetOpenAuth in einer Webfarm-Umgebung war.

Wenn Sie Ihre OpenIdRelyingParty erstellen, vergewissern Sie sich, dass Sie null im Konstruktor übergeben.

Dies versetzt Ihre Website in den statusfreien oder "dummen" Modus der OpenID. Es ist etwas langsamer für Benutzer, um sich anzumelden (wenn Sie es bemerken), aber Sie vermeiden, dass Sie einen IRelyingPartyApplicationStore schreiben müssen, damit DotNetOpenAuth in Ihrer Farm funktionieren kann;

var openIdRelyingParty = new OpenIdRelyingParty(null); 

Answer 2

Wir setzten dieses Problem durch IRelyingPartyApplicationStore (IOpenIdApplicationStore in neueren Versionen von DotNetOpenAuth) Implementierung und das Hinzufügen der Speicher Klassennamen der .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 Mitglieder alle zusammen.

Wir haben den dummen Modus als schnelle Lösung benutzt, um aufzustehen, aber am Ende werden Sie wahrscheinlich so etwas wollen.

Answer 3

All Diskussion dreht sich um folgende Frage:

Wie Unter Berufung Partei (RP) sicherstellen, dass die Anforderung, die Authentifizierungs-Token enthält, aus dem OP kommt (OpenID-Provider), an dem er die weitergeleitet Benutzerwunsch an?

Folgende Schritte erklären, wie es

1. User Request passiert mit dem Beantworten Partei kommt (RP), unsere Website in unserem Fall
2. Anwendung speichert eine eindeutige Signatur an diesen Benutzer in einer lokalen Signatur entspricht Speichern (LSS) und bettet diese Signatur dann in die Nachricht ein und leitet diese Nachricht an den OpenId-Provider (OP) weiter.
3. Der Benutzer gibt seine Anmeldeinformationen ein und das OP authentifiziert seine Nachricht und leitet diese Nachricht weiter, in der die Signatur noch eingebettet ist. zurück zu RP
4. RP vergleichen Sie die Signatur, die in der Nachricht an die Signatur eingebettet ist, die in LSS ist und wenn sie dem Benutzer

Wenn die LSS verschwindet (irgendwie) RP authentifizieren übereinstimmen, bevor die Nachricht von OP kommt zurück gibt es Nichts für RP, um die Signatur zu vergleichen, daher kann der Benutzer nicht authentifiziert werden und es wird ein Fehler ausgegeben: Die Signatur der Nachricht war falsch.

Wie kann LSS Vanish:

1. ASP.net erfrischt den Anwendungspool
2. IIS
3. In Web-Farm neu gestartet wird die Nachricht durch Anwendung gehostet auf anderen Server bedient wird

Zwei Lösungen für dieses Problem:

1. RP-Lauf im Dummy-Modus

   a. Sie speichert die Signatur nicht lokal und verwendet daher keinen Signaturvergleich, um sicherzustellen, dass die Nachricht vom OP kommt, an das der Benutzer zur Authentifizierung weitergeleitet wurde.

   b. Sobald RP die Authentifizierungsnachricht vom OP erhalten hat, sendet er die Nachricht zurück an OP und bittet ihn zu überprüfen, ob er derjenige ist, der diesen Benutzer authentifiziert hat und der Absender der Nachricht ist. Wenn OP antwortet Ja, ich bin der Urheber dieser Nachricht und ich habe diese Nachricht erstellt, dann wird der Benutzer authentifiziert von RP

2. Implementieren Sie Ihren eigenen Persistenz-Speicher, der nicht verschwindet, egal, was ASP.net mit dem Prozess tut, Ähnlich wie SQL zum Speichern des Sitzungsstatus.