2012-08-02 26 views
6

Estamos creando una aplicación que usa ACS. Nuestro escenario de uso es el siguiente:Azure ACS - Aplicación de parte de retransmisión - ReturnURL con parámetros?

  1. El usuario obtiene una URL como éste https://our.application.com/?requestId=123456 través de correo electrónico y hace clic en él
  2. El usuario se le redirecciona a la pantalla LiveID entrada
  3. Después de iniciar la sesión, ACS remite la usuario para nosotros, sino para https://our.application.com/

por desgracia, parece que el "URL de devolución" del menú "Partido retransmisión" en el "Portal de Servicio de control de Acceso" es sólo una cuerda fija. ¿Hay alguna forma de propagar la solicitud original? Si no, ¿qué sugieres como solución alternativa?

Respuesta

3

Creo que la respuesta es no, y sugeriría usar una cookie para almacenar el parámetro.

+0

Gracias por la sugerencia :-) –

+0

En realidad, puede hacerlo sin las cookies - ver las otras respuestas. –

4

La respuesta es sí, pero no sin un poco de trabajo. En el paso 3, la URL de retorno está siendo reemplazada por la que ha configurado en su ACS RP mediante la página de inicio de sesión de ACS predeterminada. Esta es la página, que ACS aloja para usted de forma predeterminada, donde elige su proveedor de identidad. (Es posible que no siempre lo vea en el navegador; se redireccionará automáticamente si solo tiene configurado un IDP.)

Puede indicarle a ACS que use una página de inicio de sesión personalizada que usted mismo aloja para que se guarde esta URL original. Puede descargar la página de inicio de sesión de ACS predeterminada del portal de ACS como algo con lo que puede trabajar.

La parte engañosa proviene del hecho de que los diferentes proveedores de identidades que usan diferentes protocolos utilizan diferentes mecanismos para guardar esta URL original.

Algunas mayor discusión y ejemplos de código sobre esto se puede encontrar aquí, y que podrían encontrar otras soluciones a este problema en otros lugares en la web:

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

+1

Bien, probé esto, pero parece que a LiveID no le gusta el parámetro & cx. Seguí recibiendo el mensaje "La solicitud no está formateada correctamente". error. Terminó con la solución de Cookie después de todo. Sin embargo, si sabe cuál podría ser la causa de esto, me gustaría saberlo :-) Su sugerencia me ayudó de alguna otra manera; en algunos casos, quería presentar un único IdentitiyProvider como una opción de enumerar todos ellos. –

+0

Mi primera suposición es un problema de codificación URL. Si me enviaras un ejemplo, podría decírtelo con seguridad :) –

0

Si desea proporcionar un "ReturnURL" a través cuenta ACS + Microsoft puede consultar las páginas de inicio de sesión de ACS a través de los IdentitiyProviders.js y aprobar un "contexto", por ejemplo: 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

Como resultado obtendrá la sesión-URL para una cuenta Microsoft con el parámetro wctx: https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=...&wp=MBI_FED_SSL&wctx=cHI9d3NmZWRlcmF0aW9uJnJtPXVybiUzYW9uZW9mZml4eCUzYWRldiUzYWRlZmF1bHQmY3g9Zm9vb29iYXI1 < - foobar.

Después del proceso de inicio de sesión, su returnUrl configurado se invoca con el parámetro wctx (en mi ejemplo obtendrá "foobar").

Cuestiones relacionadas