Conceptos e información general sobre la identidad basada en notificaciones

Última modificación: jueves, 18 de marzo de 2010

Hace referencia a: SharePoint Foundation 2010

Modelo de identidad basada en notificaciones

Al crear aplicaciones para notificaciones, el usuario presenta una identidad en la aplicación como un conjunto de notificaciones. Una notificación puede ser el nombre del usuario, otra podría ser una dirección de correo electrónico. La idea es que un sistema de identidad externa se configura 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.

Bajo este modelo, es más fácil de lograr el inicio de sesión único y la aplicación deja de ser 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

Bajo este modelo, la aplicación toma decisiones relacionadas con identidad en función de las notificaciones proporcionadas por el usuario. Esto puede ser cualquier cosa, 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 y temas se presentan la terminología y los conceptos que le ayudarán a comprender la arquitectura de la identidad basada en notificaciones.

Identidad

La identidad es un conjunto de atributos que describen a un usuario, o a alguna otra entidad, en un sistema que se desea proteger.

Notificación

Considere una notificación como una porción de información de identidad (por ejemplo, nombre, dirección de correo electrónico, edad o pertenencia al rol de ventas). Cuantas más notificaciones reciba la aplicación, más información tendrá sobre el usuario. Se denominan "notificaciones" en lugar de "atributos", como se usa normalmente al describir los directorios de empresa, debido al método de entrega. En este modelo, la aplicación no busca atributos de usuario en un directorio, sino que el usuario proporciona las notificaciones a la aplicación y la aplicación las examina. Cada notificación proviene de un emisor y se debe confiar en la notificación tanto como se confía en el emisor. Por ejemplo, se confía más en una notificación realizada por el controlador de dominio de la compañía que en una notificación realizada por el usuario.

Token de seguridad

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 del sobre SOAP. En una aplicación web basada en el explorador, las notificaciones se reciben mediante un 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 y aquí es donde entran en juego los tokens de seguridad. 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ó simplemente las notificaciones y las envió. En situaciones de seguridad baja donde no se desea o necesita criptografía, puede usar tokens no firmados, pero ese escenario no se describe en este tema.

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 de cifrado y presentan la aplicación con un conjunto de notificaciones que podrá leer.

Servicio de token de seguridad (STS)

Un STS es la infraestructura que crea, firma y emite tokens de seguridad de acuerdo con los protocolos interoperables descritos en la sección sobre especificaciones de este tema. Se emplea una gran cantidad de trabajo en la implementación de estos protocolos, pero WIF lleva a cabo todo este trabajo automáticamente, posibilitando a alguien que no es experto en protocolos la tarea de poner en funcionamiento un STS con muy poco esfuerzo.

WIF facilita la creación de un STS propio. Está en sus manos averiguar cómo implementar la lógica, o las reglas, que lo exigen (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 tema emite tokens de seguridad que contienen notificaciones. Esta autoridad emisora es una aplicación web o 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 notificación, 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 pidiéndole que autentique a los usuarios en su nombre.

Usuario 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 un usuario de confianza son la "aplicación para notificaciones" y la "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 consume 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 de 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 el uso de WS-MetadataExchange y la directiva propiamente dicha se estructura de acuerdo con la especificación de WS-Policy. El STS expone los extremos que implementan la especificación de 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 conseguir el inicio de sesión único en todas las aplicaciones, independientemente de 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, a continuación, crea un token de SAML y responde con un fragmento de código de 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 punto, es habitual que el usuario de confianza empaquete las notificaciones en una cookie para que no sea necesario redirigir al usuario en cada solicitud.