2012-08-02 3 views
6

Wir erstellen eine Anwendung, die ACS verwendet. Unser Einsatzszenario sieht wie folgt aus:Azure ACS - Relaying Party Anwendung - ReturnURL mit Parametern?

  1. Der Benutzer erhält eine URL wie diese https://our.application.com/?requestId=123456 per E-Mail und klickt auf sie
  2. Der Benutzer zum LiveID Login-Bildschirm Nach dem Einloggen in
  3. umgeleitet wird, ACS leitet die Benutzer zu uns, sondern https://our.application.com/

Leider scheint es, dass die „Return URL“ in der „Relaying-Party“ auf dem „Access Control Service Portal“ ist nur eine feste Zeichenfolge setzen. Gibt es eine Möglichkeit, die ursprüngliche Anfrage an sie weiterzugeben? Wenn nicht, was würden Sie als Workaround vorschlagen?

Antwort

3

Ich glaube, die Antwort ist nein, und ich würde vorschlagen, einen Cookie zu verwenden, um den Parameter zu speichern.

+0

Danke für den Vorschlag :-) –

+0

Eigentlich können Sie es ohne das Cookie-Zeug tun - siehe die anderen Antworten. –

4

Die Antwort ist eigentlich ja, aber nicht ohne ein wenig Arbeit. In Schritt 3 wird Ihre Rückgabe-URL durch die Adresse überschrieben, die Sie in Ihrem ACS RP auf der Standard-ACS-Anmeldeseite konfiguriert haben. Dies ist die Seite, die ACS standardmäßig für Sie hostet, wobei Sie Ihren Identitätsanbieter auswählen. (Sie sehen es möglicherweise nicht immer im Browser; es wird automatisch umgeleitet, wenn Sie nur einen IDP konfiguriert haben.)

Sie können ACS anweisen, eine benutzerdefinierte Anmeldeseite zu verwenden, die Sie selbst hosten, damit diese ursprüngliche URL gespeichert wird. Sie können die Standard-ACS-Anmeldeseite vom ACS-Portal herunterladen, um etwas abzuarbeiten.

Der schwierige Teil kommt von der Tatsache, dass verschiedene Identitätsprovider, die verschiedene Protokolle verwenden, verschiedene Mechanismen verwenden, um diese ursprüngliche URL zu speichern.

Einige weitere Diskussion und Codebeispiele dazu sind hier zu finden, und Sie können weitere Lösungen für dieses Problem an anderer Stelle im Web finden:

How do I get the return URL working properly again after downloading a login page from Azure ACS?

+1

OK, ich habe das versucht, aber es scheint, dass LiveID den & cx-Parameter nicht mag. Ich bekam immer wieder "Die Anfrage wurde nicht richtig formatiert". Error. Endlich mit der Cookie-Lösung fertig. Wenn Sie jedoch wissen, was die Ursache sein könnte - ich würde es gerne wissen :-) Ihr Vorschlag hat mir auf andere Weise geholfen - ich wollte in einigen Fällen nur einen IdentityProvider als Option präsentieren sie alle aufzulisten. –

+0

Meine erste Schätzung ist ein URL-Codierungsproblem. Wenn Sie mir ein Beispiel schicken würden, könnte ich Ihnen das sicher sagen :) –

0

Wenn Sie zur Verfügung stellen möchten eine „returnUrl“ über ACS + Microsoft-Konto können Sie die ACS-Login-Seiten über die IdentitiyProviders.js abfragen und einen „Kontext“ übergeben, zum Beispiel: https://MyACS.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=MyRealm&reply_to=&context=foooobar&request_id=&version=1.0&callback=&wfresh=0

Als Ergebnis werden Sie die Login-URL für Microsoft-Konto mit dem wctx Parameter erhalten: https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=...&wp=MBI_FED_SSL&wctx=cHI9d3NmZWRlcmF0aW9uJnJtPXVybiUzYW9uZW9mZml4eCUzYWRldiUzYWRlZmF1bHQmY3g9Zm9vb29iYXI1 < - foobar.

Nach dem Login-Vorgang wird das konfigurierte ReturnUrl mit dem Parameter wctx aufgerufen (in meinem Beispiel erhalten Sie "foobar").

Verwandte Themen