2016-01-28 12 views
10

Ich habe einen Service Provider eingerichtet unter https://biz.dev.originsystems.co.za. Ich habe ein IdP eingerichtet unter http://stage.originsystems.co.za.SimpleSAMLphp Statusinformationen gehen verloren

Beim Testen der Authentifizierung mit dem Tool unter https://biz.dev.originsystems.co.za/simplesaml/module.php/core/authenticate.php funktioniert alles einwandfrei. Es kommt mit den erforderlichen Attributen zurück zur Dev-Seite und alles ist glücklich und fröhlich.

Wenn ich jedoch versuche, den IdP in Code auf https://biz.dev.originsystems.co.za zu schlagen, werde ich zur Stage-Anmeldeseite umgeleitet, aber nach der Anmeldung erhalte ich den Fehler "State information lost". Ich bekomme die folgenden Debug-Informationen:

Ich habe alle die Fehlersuche die Seite hat mich gebeten, zu tun, aber die Situation bleibt bestehen.

Ich habe die Dev-Tools im Browser geöffnet und beobachtete die Cookie-Informationen. Die Cookies für biz.dev.originsystems.co.za enthalten ein SimpleAMLAuthToken, also funktionieren die Cookies. Der Code, den ich mit der IdP zu schlagen ist:

$as = new SimpleSAML_Auth_Simple("stage-sso-sp"); 
$as->requireAuth(); 
$attributes = $as->getAttributes(); 
print_r($attributes); 

UPDATE:

Hier einige weitere Informationen ...

ich, wenn das Problem bestimmen wollte, war, wie ich einrichten die IdP, also begann ich SSO Circle für den IdP zu verwenden. Die Statusinformationen gehen auch nach der Authentifizierung in SSO Circle verloren. Ich denke, das bedeutet, dass das Problem irgendwo bei meinem Service Provider-Setup für SimpleSAML liegt. Hier ist, was passiert ...

Als ich zum SimpleSAML Test-Authentifizierungsquellen Seite gehen an https://biz.stage.originsystems.co.za/simplesaml Ich habe folgende Cookie-Werte ...

Name          Value 
SimpleSAMLAuthToken      _a53569c0701dd02832532df14cf10cd0b2d9fcd6b6 
biz.stage.originsystems.co.za    10fc356e0bfbf707af5fa5854c378755 
ccof          RGN002 
xbrF          84aadc624fc51c0c9340d45645c08643 

Alles außer dem SimpleSAMLAuthToken unserer Anwendung ist und sollte nicht Auswirkungen auf SimpleSAML. Sobald ich zu SSO Circle umgeleitet und authentifiziert bin, gehe ich zu meiner SimpleSAML-Seite zurück und der Auth Token hat jetzt einen Wert von _39679e07cb1911e08b2bff3580a9929faddd07e9b6 und alle relevanten Informationen werden korrekt zurückgegeben. Die Protokolldatei zeigt die folgende Aktivität.

Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Received SAML2 Response from 'http://idp.ssocircle.com'. 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] No certificate in message when validating against fingerprint. 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Found 1 certificates in SAML2_Assertion 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Has 1 candidate keys for validation. 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Validation with key #0 succeeded. 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Filter config for http://idp.ssocircle.com->https://biz.stage.originsystems.co.za/simplesaml/module.php/saml/sp/metadata.php/default-sp: array ( 0 => sspmod_core_Auth_Process_LanguageAdaptor::__set_state(array( 'langattr' => 'preferredLanguage',  'priority' => 90, )),) 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Deleting state: '_742b094314383407864f56bccc6afd7de3dcb3211e' 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Session: doLogin("default-sp") 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Session: Valid session found with 'default-sp'. 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Session: Valid session found with 'default-sp'. 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Template: Reading [/OriginSystems/application/Updraft/web/external/System/SSO/simplesaml/dictionaries/status] 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Template: Reading [/OriginSystems/application/Updraft/web/external/System/SSO/simplesaml/dictionaries/attributes] 
Feb 02 12:58:22 simplesamlphp DEBUG [7c4534ae0a] Template: Reading [/OriginSystems/application/Updraft/web/external/System/SSO/simplesaml/modules/core/dictionaries/frontpage] 

Wenn ich https://biz.stage.originsystems.co.za?ccof=RGN002 gehen, ich bin umgeleitet, wie ich SSO Kreis sein erwarten, wo ich dann authentifizieren. Zu diesem Zeitpunkt hat mein Autth Token einen Wert von _39679e07cb1911e08b2bff3580a9929faddd07e9b6. Sobald ich authentifiziert bin, werde ich auf eine SimpleSAML-Fehlerseite "State Information Lost" verwiesen und das Auth Token ist immer noch _39679e07cb1911e08b2bff3580a9929faddd07e9b6.

Das Protokoll liest ...

Feb 02 13:08:31 simplesamlphp DEBUG [8abc64dd04] Loading state: '_498e7d4d75bb7716e5e8cf905e0da5ef1c40cf1b3f' 
Feb 02 13:08:31 simplesamlphp ERROR [8abc64dd04] SimpleSAML_Error_NoState: NOSTATE 
Feb 02 13:08:31 simplesamlphp ERROR [8abc64dd04] Backtrace: 
Feb 02 13:08:31 simplesamlphp ERROR [8abc64dd04] 2 /OriginSystems/application/Updraft/web/external/System/SSO/simplesaml/lib/SimpleSAML/Auth/State.php:225 (SimpleSAML_Auth_State::loadState) 
Feb 02 13:08:31 simplesamlphp ERROR [8abc64dd04] 1 /OriginSystems/application/Updraft/web/external/System/SSO/simplesaml/modules/saml/www/sp/saml2-acs.php:63 (require) 
Feb 02 13:08:31 simplesamlphp ERROR [8abc64dd04] 0 /OriginSystems/application/Updraft/web/external/System/SSO/simplesaml/www/module.php:134 (N/A) 
Feb 02 13:08:31 simplesamlphp ERROR [8abc64dd04] Error report with id dfbb52b0 generated. 
Feb 02 13:08:31 simplesamlphp DEBUG [8abc64dd04] Template: Reading [/OriginSystems/application/Updraft/web/external/System/SSO/simplesaml/dictionaries/errors] 
Feb 02 13:08:31 simplesamlphp DEBUG [8abc64dd04] Template: Reading [/OriginSystems/application/Updraft/web/external/System/SSO/simplesaml/modules/core/dictionaries/no_state] 

Es sieht für mich, als ob die Auth-Token _498e7d4d75bb7716e5e8cf905e0da5ef1c40cf1b3f sein soll, ist aber aus irgendeinem Grunde nicht. Da SimpleSAML dieses Token nicht finden kann, löscht es niemals das alte und erstellt ein neues Token. Vielleicht irre ich mich deswegen. Ich bin vollkommen bereit, korrigiert zu werden. Mein Problem ist, dass ich nicht weiß, was das verursacht. Ich habe den cookie.name in der Konfigurationsdatei auf "biz.stage.originsystems.co.za" gesetzt, und das scheint für das SimpleSAML-Kontrollfeld zu funktionieren, aber es funktioniert nicht, wenn der SP von der tatsächlichen Anwendung verwendet wird. Kann mir hier jemand in die richtige Richtung zeigen? Ich bin verloren.

+2

Die generierte ID/Token, die Sie bekommen, ist irgendwie Problem, die drei wichtigsten Gründe, die diese Fehler erzeugen können, sind, 1. Ändern des Domain-Namen, zB Sie sind auf example.com hopping auf www.example.com, die verursachen Session für No-State-Fehler, 2. Springen von HTTP zu HTTPS oder HTTPS zu HTTP, 3. Die Sitzung wird nicht korrekt gespeichert. Für weitere Informationen lesen Sie bitte [hier] (https://simplesamlphp.org/docs/development/simplesamlphp-nostate # section_3) –

+0

Multi-Denker: Das ist eine ausgezeichnete Antwort. Sie sollten es als Antwort posten, damit Sie das Kopfgeld verdienen können. Wenn es für Sie nicht funktioniert, Andrew, würden Sie die Metadaten für Ihre SP- und IDP-Konfiguration posten? –

+0

Ohne auf die Metadaten zu schauen, ist es schwierig, eine spezifische Antwort zu geben, aber ich möchte darauf hinweisen, dass Firefox ein Add-on namens Saml Tracer hat (https://addons.mozilla.org/en-US/firefox/addon/). saml-tracer /), die ich beim Debuggen von SSO-Problemen immer benutzt habe. Könnte Ihnen helfen, herauszufinden, welche Werte hin und her gesendet werden, ohne auf Debug-Anweisungen angewiesen zu sein. – mounty

Antwort

0

müssen Sie zwei völlig unabhängige Umgebungen definieren, um diese beiden Umgebungen (die zwei völlig unterschiedliche Identitätsanbieter aufweisen) zu beschreiben, wie Sie es beschreiben (was offensichtlich nicht funktioniert, wenn Sie nicht beide hinzugefügt haben von ihnen in die SSO-Konfiguration - was wahrscheinlich nicht das gewünschte Ergebnis ist); Überprüfen Sie einfach den Hostnamen des Servers und definieren Sie die Variablen entsprechend - dies kann entweder "on-the-fly" oder möglicherweise durch zwei verschiedene Konfigurationsdateien geschehen (es ist tatsächlich üblich, Konfigurationsdateien am Ende einer Implementierung zu übertragen). Für mich klingt das weit mehr nach einem Bereitstellungsproblem (es fehlt die richtige Konfigurationsdatei für die Live-Site) als nach einem SSO-Problem.