2012-08-02 10 views
6

Budujemy aplikację korzystającą z ACS. Nasz scenariusz użycia wygląda następująco:Azure ACS - Aplikacja strony przekaźnikowej - ReturnURL z parametrami?

  1. Użytkownik dostaje URL jak ten https://our.application.com/?requestId=123456 poprzez e-mail i kliknięcia na nim
  2. Użytkownik zostanie przekierowany do ekranu LiveID logowania
  3. Po zalogowaniu ACS przekazuje dalej użytkownik do nas, ale do https://our.application.com/

Niestety, wygląda na to, że ustawienie "Zwrotny URL" w "Stronie przekaźnikowej" w "Portalu kontroli dostępu" to tylko stały ciąg znaków. Czy istnieje sposób na przekazanie pierwotnego wniosku? Jeśli nie, co zasugerowałbyś jako obejście tego problemu?

Odpowiedz

3

Uważam, że odpowiedź brzmi "nie", a proponuję użyć pliku cookie do zapisania parametru.

+0

Dzięki za sugestię :-) –

+0

Właściwie możesz to zrobić bez plików cookie - zobacz inne odpowiedzi. –

4

Odpowiedź brzmi: tak, ale nie bez odrobiny pracy. W kroku 3 Twój URL powrotu jest zastępowany przez ten, który skonfigurowałeś w ACS RP przez domyślną stronę logowania ACS. To jest strona, którą domyślnie ACS obsługuje dla Ciebie, gdzie wybierasz dostawcę tożsamości. (Możesz nie zawsze wyświetlać go w przeglądarce - przekieruje się automatycznie, jeśli masz skonfigurowane tylko jedno IDP.)

Możesz potwierdzić, że ACS używa niestandardowej strony logowania, na której się hostujesz, aby ten oryginalny URL został zapisany. Możesz pobrać domyślną stronę logowania ACS z portalu ACS jako coś do pracy.

Trudna część pochodzi z faktu, że różni dostawcy tożsamości używający różnych protokołów używają różnych mechanizmów do zapisywania tego oryginalnego adresu URL.

niektórych dalszych dyskusji i kodów próbek na ten temat można znaleźć tutaj, a może znaleźć dalsze rozwiązania tego problemu Indziej w internecie:

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

+1

OK, próbowałem tego, ale wygląda na to, że LiveID nie lubi parametru & cx. Ciągle otrzymuję komunikat "Żądanie nie jest poprawnie sformatowane". błąd. W końcu znalazłem rozwiązanie Cookie. Jeśli jednak wiesz, co może być tego przyczyną - chciałbym to wiedzieć :-) Twoja sugestia pomogła mi w inny sposób - chciałem w niektórych przypadkach przedstawić tylko jedną IdentitiyProvider jako opcję zamiast listy wszystkich. –

+0

Moje pierwsze przypuszczenie to problem z kodowaniem adresu URL. Jeśli miałbyś wysłać mi przykład, mógłbym ci powiedzieć na pewno :) –

0

Jeśli chcesz, aby zapewnić „ReturnURL” poprzez konto ACS + Microsoft można wyszukać strony logowania ACS, za pośrednictwem IdentitiyProviders.js i przekazać „kontekst”, np: 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

w rezultacie otrzymasz login-URL konto Microsoft z parametrem wctx: https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=...&wp=MBI_FED_SSL&wctx=cHI9d3NmZWRlcmF0aW9uJnJtPXVybiUzYW9uZW9mZml4eCUzYWRldiUzYWRlZmF1bHQmY3g9Zm9vb29iYXI1 < - foobar.

Po zakończeniu procesu logowania skonfigurowany returnUrl jest wywoływany za pomocą parametru wctx (w moim przykładzie otrzymasz "foobar").

Powiązane problemy