Primero diferenciemos el protocolo con el formato de token. Supongo que estás hablando del protocolo y no del formato de token. Pero por si acaso estas son las diferencias:
- SAML 2 formato de token. Este es simplemente el formato del token que su aplicación podrá soportar. Esto es compatible con WIF recién sacado de la caja.
- Protocolo SAML 2. Esta es la interacción HTTP que su aplicación deberá comprender para obtener un token en la aplicación. Esto no es compatible con WIF, pero hay una extensión que puede descargar (http://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=36088)
Por otro lado, tiene un escenario en el que hay múltiples proveedores de identidades. El libro que Wiktor sugirió (del cual soy coautor) explica este escenario con más detalle en el Federated Identity with Multiple Partners chapter. Te recomiendo que lo leas para entender los conceptos que hay detrás de la federación de identidades. Déjame darte la versión corta del artículo y algunos detalles de implementación. Hay dos maneras de resolver esto:
Implementándolo en el nivel de la aplicación. WIF le permitirá confiar en más de un token de proveedor de identidad (esto se hace con certificados X509). A continuación, deberá generar solicitudes de inicio de sesión para cada proveedor de identidad en función de una url (como https://idp1.yourapp.com o https://yourapp.com/idp1) o de que el usuario elija (al tener una página de inicio con dos enlaces, uno para cada proveedor de identidad). También deberá normalizar los reclamos que provengan de ese proveedor de identidad (tal vez uno de ellos le enviará un reclamo de "nombre" y el otro un reclamo "upn").
YourApp --> Identity Provider 1
\-> Identity Provider 2
Utilizando lo que se denomina "proveedor de federación". Este es otro servidor que emitirá tokens a su aplicación y tendrá las relaciones de confianza con su proveedor de identidad. En lugar de hacer que su aplicación confíe en los dos proveedores de identidad, solo confía en su proveedor de federación y el proveedor de servicios de alimentación confiará en los proveedores de identidad. Es una cadena de confianza.
YourApp --> Federation Provider --> Identity Provider 1
\-> Identity Provider 2
Esta arquitectura permite:
- crecer sus proveedores de identidad sin tocar su aplicación
- si más adelante tiene una segunda aplicación que acaba de copiar su puesta en práctica de la primera
- obtienes el inicio de sesión único gratis
- obtienes un motor de transformación de reclamos (si utiliza algo así como AD FS)
- si utiliza algo así como AD FS que presentamos lo SAML 2 protocolo construido en (en lugar de tener que aplicar a mano con la extensión se menciona a continuación)
Por supuesto, la desventaja es que usted ahora tiene algo más para mantener (el servidor ADFS).
Gracias, Wiktor Zychla por sus valiosos comentarios. Déjame echar un vistazo a esto. – dipa
@Wiktor Zychla este es genial link – Ravia