single-sign-on - sso - token adfs
¿Cuál es la diferencia entre ADFS, WIF, WS Federation, SAML y STS? (3)
Estas son numerosas tecnologías y palabras de moda utilizadas para el inicio de sesión único con servicios de Microsoft.
¿Alguien puede explicar ADFS, WIF, WS Federation, SAML y STS (servicio de token de seguridad), incluyendo dónde y cuándo se usa cada uno?
Desde un punto de vista general:
Supongamos una aplicación basada en el navegador ASP.NET que requiere autenticación y autorización.
La aplicación puede hacerla suya o puede externalizarla.
WIF es una biblioteca .NET que permite a ASP.NET implementar esta tercerización.
Habla con un STS ( ADFS es una instancia de un STS) que se autentica frente a un repositorio de identidad y proporciona información de autorización en forma de notificaciones. Un STS proporciona un conjunto de reclamos confiables y firmados.
El protocolo utilizado entre WIF y ADFS es WS-Federation .
Si el STS estaba basado en Java (por ejemplo, Ping Identity o OpenAM), WIF utilizaría el protocolo SAML para la comunicación. ADFS también es compatible con SAML para habilitar la federación.
(Federación, por ejemplo, permite a un usuario de una empresa A orientada a Java acceder a la aplicación ASP.NET en una empresa B orientada a .NET autenticándose en el repositorio de identidad de A. La empresa A y la empresa B confían entre sí en un sentido de federación).
Esta publicación está destinada a clarificar los tokens SAML, compatibles con ADFS 2.0 y el protocolo SAML, no soportados hasta ADFS 3.0, la versión de ADFS en Windows Server 2012 R2
1) El protocolo SAML no es compatible antes de ADFS 3.0
2). Las aplicaciones WIF basadas en .net 4.5 requieren el uso del protocolo WS-Fed y actualmente no son compatibles con el protocolo SAML.
3) Los tokens SAML están basados en XML. Los tokens SAML son compatibles con ADFS 2.0 y versiones anteriores. ADFS 1.0. 1.1. y 2.0 solo admiten los tokens SAML, no el protocolo
4) Si está utilizando WIF, se requiere WS-Fed (protocolo), por lo que podría hacer lo siguiente:
Protocolo SAML <---> ADFS <----> WS-FED <----> WIF (.net 4.5)
De Wiki:
• ADFS 1.0 - Windows Server 2003 R2 (descarga adicional)
• ADFS 1.1 - Windows Server 2008 y Windows Server 2008 R2.
• ADFS 2.0 - Windows Server 2008 y Windows Server 2008 R2 (descarga desde Microsoft.com)
• ADFS 2.1 - Windows Server 2012.
• ADFS 3.0 - Windows Server 2012 R2.
ADFS (Servicios de federación de Active Directory): servicio de token de seguridad (STS) comercializado por Microsoft y creado con Windows Identity Foundation (WIF). Se basa en AD para la autenticación. Se puede usar en escenarios activos (servicios web SOAP) o pasivos (sitios web) y admite tokens SAML, WS-Federation, WS-Trust y SAML-Protocol. Se puede usar como un Proveedor de identidad (contra AD) o como un Proveedor de la Federación.
http://technet.microsoft.com/en-us/library/adfs2(v=ws.10).aspx
WIF (Windows Identity Foundation): la biblioteca .NET utilizada para conducir la autenticación basada en notificaciones en aplicaciones .NET y partes que confían. También se puede usar como un cliente WS-Trust y para crear un STS personalizado.
WS-Federation: protocolo utilizado por las partes que confían y un STS para negociar un token de seguridad. Una aplicación solicita un token de seguridad desde un STS utilizando WS Federation, y el STS devuelve (la mayoría de las veces) un token de seguridad SAML a la aplicación utilizando el protocolo WS Federation. Esto es generalmente a través de HTTP (GET y POST y redirecciones). Contraste esto con WS-Trust, que está completamente basado en el servicio web.
Fichas SAML (Lenguaje de marcado de aserción de seguridad): este es simplemente el formato XML utilizado para los tokens de seguridad, que generalmente capturan información de usuario (notificaciones) y otros datos relacionados con la seguridad (firmas, emisor de tokens, etc.). El token es utilizado por la aplicación para autenticar usuarios y controlar el comportamiento de la aplicación (por ejemplo, autorización). Los tokens de seguridad SAML están firmados por integridad y, opcionalmente, cifrados, por lo que solo RP y STS pueden ver sus contenidos. En los sitios web ASP.NET que usan WIF, el token se cifra de manera predeterminada y se fragmenta en cookies, pero esto se puede modificar.
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
STS (Servicio de token de seguridad): como se describió anteriormente, el STS es el intermediario que se ubica entre una aplicación de parte confiante y el usuario. Un STS es un emisor de tokens de seguridad. "Emisor" es a menudo un sinónimo de STS. Los STS se configuran en dos roles: como proveedores de identidad (IdP) cuando autentican usuarios o como proveedores de federación (FP) cuando se sientan en el medio de una cadena de confianza y actúan como "partes confiantes" para otros IdP. Los IdP necesitan una forma de autenticar a los usuarios. Algunos (como ADFS) usan Active Directory, otros usan bases de datos personalizadas como membresía de SQL Server (no ADFS). Si el usuario se autentica correctamente, el STS emitirá un token de seguridad.
http://msdn.microsoft.com/en-us/library/ff650503.aspx
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html#_Toc212615442
Espero que esto ayude. Hay muchos conceptos y piezas para entender en la autenticación basada en reclamos. Para obtener una comprensión completa, debe consultar una guía de identidad basada en notificaciones y control de acceso .