¿Cómo se compara la "Identidad ASP.Net" con la "Fundación de Identidad de Windows"?
windows identity foundation windows 10 (3)
En primer lugar, WIF es compatible con WS-Fed no SAML (aunque utiliza tokens SAML). AFAIK, la identidad no es compatible con SAML.
La identidad es predominantemente basada en DB. Normalmente, WIF se utiliza junto con ADFS, que está basado en AD. ADFS soporta SAML.
WIF subcontrata la autenticación / autorización a un STS (como ADFS), por lo que la decisión de FBA es una STS no una WIF.
WIF es compatible con la federación para que pueda conectarse a otro STS, Azure Active Directory, etc.
Como usted dice, son dos conjuntos de implementaciones de Microsoft "en competencia".
Si está buscando una imagen más grande, soporte de AD y pruebas futuras, parece que WIF es la mejor opción.
Encontré este bonito artículo que muestra la evolución de los marcos de identidad de ASP.Net: http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity
Sin embargo, estoy interesado en cómo encaja el Windows Identity Framework (WIF) en la imagen con el nuevo ASP.Net Identity Framework. ¿Son otro conjunto de implementaciones de Microsoft que compiten?
Además, si un desarrollador está interesado en admitir la autenticación SAML (que admite WIF), la autenticación de Active Directory y la autenticación de formularios, ¿cuál elegiría?
Gracias nzpcmad por ayudarme a hacer las preguntas correctas.
Después de más investigaciones, si entiendo todo esto correctamente, la mayor ventaja de usar la nueva identidad de ASP.Net es que está construida sobre el modelo OWIN.
Microsoft está trabajando en un componente WS-Federation basado en OWIN llamado Microsoft.Owin.Security.WsFederation. Todavía está en versión beta, pero creo que en realidad se basa en WIF, ya que todas las clases de WIF se trasladaron al marco central a partir de .Net 4.5. Puede encontrar más información aquí: http://www.cloudidentity.com/blog/2014/02/20/ws-federation-in-microsoft-owin-componentsa-quick-start/ y aquí http://blogs.msdn.com/b/webdev/archive/2014/02/21/using-claims-in-your-web-app-is-easier-with-the-new-owin-security-components.aspx .
Entonces, no creo que la pregunta sea: ASP.Net Identity versus WIF. Creo que la pregunta es: OWIN versus no OWIN.
Así que pienso responder a mi pregunta: la opción más segura y flexible para el futuro es utilizar los componentes de seguridad de OWIN y, a través de una configuración simple u otros medios, permitir el cambio entre el componente de identidad de ASP.Net de OWIN y el componente de WS-Federation de OWIN.
La identidad de ASP.NET está utilizando WIF en el fondo. WIF no es solo WS-Fed, ahora es el núcleo de .NET framework cuando se trata de tratar con Principal / Identity. Básicamente, el espacio de nombres System.IdentityModel ahora forma parte de WIF y .NET 4.5.
El objetivo de la identidad de ASP.NET es proporcionar un mecanismo de autenticación listo para usar con persistencia y algunas otras características ingeniosas y, por lo tanto, reemplazar a los proveedores de membresía utilizados tradicionalmente que hicieron prácticamente lo mismo, de una manera muy fea (después de todo, se terminó 10 años).
Personalmente nunca uso ASP.NET Identity en el proyecto, sino que hago mi propia lógica de usuario cuando se trata de persistencia, envío de correos, etc., y trabajo directamente con las clases WIF más importantes, como SessionAuthenticationModule, ClaimsAuthenticationManager, ClaimsAuthorizationManager, etc. Mi capacidad para escribir mi propia abstracción personalizada basada en reclamaciones. WIF tiene que ver con CBAC (Control de acceso basado en reclamaciones).
Ahora, cuando se trata de OWIN o no-OWIN, yo diría: vaya por OWIN (o para ser más precisos, vaya por Katana). ASP.NET se reescribirá completamente con la nueva tecnología vNext, y Katana jugará un papel importante allí. Cuanto antes se acostumbre a trabajar con el middleware Katana, más fácil será la transición para usted.
Tenga en cuenta que todos los módulos (FormsAuthenticationModule, RoleManagerModule, SessionAuthenticationModule, WSFederationModule, ...) no son compatibles con OWIN / Katana, ya que el concepto de extensión ASP.NET a través de IHttpModule está siendo reemplazado por la filosofía Middleware.
Echa un vistazo a este repositorio "oculto" donde MVC, WebAPI, SignalR se fusionan en vNext MVC nuevo: