Identidad y conceptos basados en notificaciones en SharePoint
Modelo de identidad basada en notificaciones
Al crear aplicaciones para notificaciones, el usuario presenta una identidad en la aplicación como conjunto de notificaciones. Una notificación podría ser el nombre del usuario y otra podría ser una dirección de correo electrónico. La idea es que se configura un sistema de identidad externo para proporcionar a la aplicación toda la información que necesita sobre el usuario con cada solicitud, junto con la comprobación criptográfica de que los datos de identidad recibidos por la aplicación provienen de una fuente de confianza.
En este modelo, el inicio de sesión único es mucho más fácil de lograr, y la aplicación ya no es responsable de las siguientes acciones:
Autenticación de usuarios
Almacenamiento de cuentas de usuario y contraseñas
Llamada a directorios de empresa para buscar detalles de identidad del usuario
Integración con sistemas de identidad de otras plataformas o compañías
En este modelo, la aplicación toma decisiones relacionadas con la identidad en función de las notificaciones proporcionadas por el usuario. Esto puede comprender desde la personalización sencilla de la aplicación con el nombre del usuario hasta la autorización del usuario para que obtenga acceso a recursos y características de alto nivel en la aplicación.
En las siguientes secciones, se presentan la terminología y los conceptos que le ayudarán a comprender la arquitectura de la identidad basada en notificaciones.
Identidad: conjunto de atributos que describen una entidad
La identidad es un conjunto de atributos que describen a un usuario, o alguna otra entidad, en un sistema que se desea proteger.
Notificación: información de identidad
Piense en una notificación como un fragmento de información de identidad (por ejemplo, nombre, dirección de correo electrónico, edad o pertenencia al rol Ventas). Cuantos más notificaciones reciba la aplicación, más sabrá sobre el usuario. Se denominan "notificaciones" en lugar de "atributos", como se suele usar en la descripción de directorios empresariales, debido al método de entrega. En este modelo, la aplicación no busca atributos de usuario en un directorio. En su lugar, el usuario entrega notificaciones a la aplicación y la aplicación las examina. Cada notificación la realiza un emisor y solo confía en la notificación tanto como en el emisor. Por ejemplo, confía en una notificación realizada por el controlador de dominio de su empresa más de lo que confía en una notificación realizada por el usuario.
Token de seguridad: conjunto serializado de notificaciones
El usuario proporciona un conjunto de notificaciones a la aplicación con una solicitud. En un servicio web, estas notificaciones se ejecutan en el encabezado de seguridad de la envoltura SOAP. En una aplicación web basada en el explorador, las notificaciones se reciben mediante el método HTTP POST desde el explorador del usuario y es posible que más adelante se almacenen en una cookie en la memoria caché si se desea obtener una sesión. Independientemente de cómo se reciban estas notificaciones, deben serializarse. Un token de seguridad es un conjunto serializado de notificaciones firmado digitalmente por la autoridad emisora. La firma es importante, ya que garantiza que el usuario no inventó las notificaciones y las envió. En situaciones con un nivel de seguridad bajo, en donde no se desea o no se necesita usar criptografía, puede usar tokens no firmados, pero ese escenario no se describe en este artículo.
Una de las características principales de Windows Identity Foundation (WIF) es la capacidad de crear y leer tokens de seguridad. WIF y Microsoft .NET Framework controlan todo el trabajo criptográfico y presentan la aplicación con un conjunto de notificaciones que podrá leer.
Servicio de token de seguridad (STS)
Un servicio de token de seguridad (STS) es la infraestructura que crea, firma y emite tokens de seguridad de acuerdo con los protocolos interoperables descritos en la sección "Especificaciones" de este artículo. Se necesita mucho trabajo para implementar estos protocolos, pero WIF lo hace automáticamente y, de esta manera, permite que un usuario que no es experto en protocolos pueda poner en funcionamiento un STS con muy poco esfuerzo.
WIF le permite crear su propio STS con facilidad. Está en sus manos averiguar cómo implementar la lógica, o las reglas, que lo aplican (lo que a menudo se denomina directiva de seguridad).
Autoridad emisora
Existen muchos tipos diferentes de autoridades emisoras, desde controladores de dominio que emiten vales Kerberos hasta entidades de certificación que emiten certificados X.509. El tipo específico de autoridad descrito en este artículo emite tokens de seguridad que contienen notificaciones. Esta autoridad emisora es una aplicación web o un servicio web que emite tokens de seguridad. Debe ser capaz de emitir las notificaciones adecuadas de acuerdo con el usuario de confianza de destino y el usuario que realiza la solicitud, y puede ser responsable de la interacción con los almacenes del usuario para buscar las notificaciones y autenticar a los usuarios.
Independientemente de la autoridad emisora que elija, esta desempeñará un papel fundamental en la solución de identidad. Al no tener en cuenta la autenticación en la aplicación debido a que confía en las notificaciones, le está concediendo la responsabilidad a esa autoridad y le está pidiéndole que autentique a los usuarios en su nombre.
Usuarios de confianza
Al crear una aplicación que confía en las notificaciones, está creando una aplicación de usuario de confianza. Algunos sinónimos de usuario de confianza son "aplicación para notificaciones" y "aplicación basada en notificaciones". Tanto las aplicaciones web como los servicios web pueden ser usuarios de confianza.
Una aplicación de usuario de confianza usa tokens emitidos por un STS y extrae las notificaciones de los tokens para usarlas para tareas relacionadas con la identidad. El STS admite dos tipos de aplicaciones de usuario de confianza: aplicaciones web ASP.NET y servicios web de Windows Communication Foundation (WCF).
Especificaciones
Para que todo esto sea interoperable, se usan varias especificaciones WS-* en el escenario anterior. Se recupera la directiva mediante WS-MetadataExchange y la directiva propiamente dicha se estructura de acuerdo con la especificación WS-Policy. El STS expone los extremos que implementan la especificación WS-Trust, que describe cómo solicitar y recibir tokens de seguridad. Actualmente, la mayoría de los STS emiten tokens con formato de lenguaje de marcado de aserción de seguridad (SAML). SAML es un vocabulario XML reconocido por la industria que puede usarse para representar las notificaciones de un modo interoperable. O bien, en una situación de varias plataformas, esto le permite comunicarse con un STS en una plataforma completamente diferente y lograr un inicio de sesión único en todas las aplicaciones, sin importar la plataforma.
Aplicaciones basadas en el explorador
Los clientes inteligentes no son los únicos que pueden usar el modelo de identidad basada en notificaciones. Las aplicaciones basadas en el explorador (también denominadas clientes pasivos) también pueden usarlo. En el siguiente escenario, se describe de qué manera funciona.
En primer lugar, el usuario hace que un explorador apunte a una aplicación web para notificaciones (la aplicación de usuario de confianza). La aplicación web redirige el explorador al STS para que se pueda autenticar al usuario. El STS se hospeda en una aplicación web simple que lee la solicitud entrante, autentica al usuario mediante mecanismos HTTP estándar y, luego, crea un token de SAML y responde con un fragmento de código ECMAScript (JavaScript, JScript) que provoca que el explorador inicie un método HTTP POST que devuelva el token de SAML al usuario de confianza. El cuerpo de este POST contiene las notificaciones que solicitó el usuario de confianza. En este momento, es habitual que el usuario de confianza empaquete las notificaciones en una cookie para que no sea necesario redirigir al usuario en cada solicitud.
Notificaciones del servicio de token de Windows (c2WTS)
Notificaciones del servicio de token de Windows (c2WTS) es una característica de Windows Identity Foundation (WIF). c2WTS extrae notificaciones de nombre principal de usuario (UPN) de los tokens de seguridad que no son de Windows, como los tokens X.509 y SAML, y genera tokens de seguridad de Windows de nivel de suplantación. Esto permite que una aplicación de usuario de confianza suplante al usuario. Esto podría ser necesario para tener acceso a recursos back-end, como servidores de Microsoft SQL Server, que son externos al equipo que ejecuta la aplicación de usuario de confianza.
c2WTS es un servicio de Windows que se instala como parte de WIF. Por motivos de seguridad, c2WTS solamente funciona mediante suscripción. Debe iniciarse de forma manual y se ejecuta como la cuenta del sistema local. Un administrador también debe configurar manualmente c2WTS con una lista de llamadores permitidos. De forma predeterminada, la lista está vacía.
Si la aplicación de usuario de confianza se ejecuta como la cuenta del sistema local, no es necesario usar c2WTS. Pero, si la aplicación de usuario de confianza se ejecuta como la cuenta de servicio de red o es una aplicación ASP.NET, por ejemplo, puede que sea necesario usar c2WTS para tener acceso a los recursos en otro equipo.
Supongamos que tiene una granja de servidores web que consta de un servidor que ejecuta una aplicación ASP.NET, que tiene acceso a una base de datos SQL en un servidor back-end. Quiere que esta aplicación tenga en cuenta las notificaciones. Sin embargo, la aplicación no puede acceder a la base de datos SQL mediante la notificación que recibe de un STS. En su lugar, usa c2WTS para convertir la notificación de UPN en un token de seguridad de Windows. Esto le permite acceder a la base de datos SQL.
Nota:
Para permitir que una aplicación tenga acceso a los recursos en otro servidor, un administrador de dominio debe configurar el servicio de directorio de Active Directory para habilitar la delegación restringida. Para obtener información sobre cómo habilitar la delegación restringida, vea How to: Use protocol transition and constrained eelegation in ASP.NET 2.0.