Escenario de delegación, federación y autenticación de ejemplo en SharePoint
En este artículo se proporcionan escenarios de ejemplo para la delegación y federación de identidades.
Escenarios de ejemplo
Las siguientes compañías ficticias y las necesidades de negocio mencionadas se usan en los escenarios de ejemplo que se describen en este artículo:
Contoso Hybrid es una empresa proveedora de motores de automóviles a nivel internacional especializada en la fabricación de motores eléctricos e híbridos basados en pilas de combustible para fabricantes de automóviles dentro y fuera de los Estados Unidos. En un esfuerzo estratégico por cumplir con las demandas de pedidos de piezas de sus clientes, se encargó al departamento de TI de Contoso el desarrollo y la implementación de una aplicación segura de pedido de piezas accesible mediante Internet a través del nombre de host, contoso.com. Esta aplicación también debe proporcionar varios niveles de acceso para varios usuarios internos (empleados de Contoso) y externos (empleados de los fabricantes de automóviles). Para minimizar los costos asociados con el mantenimiento de la aplicación de pedido de piezas, el departamento de TI también debe evitar la necesidad de que la aplicación use y mantenga un almacén de cuentas adicional para que los usuarios internos y externos tengan acceso a la aplicación.
Fabrikam Motors es un fabricante sueco de automóviles compactos y pequeños con un consumo eficiente de combustible que se conoce en todo el mundo por el bajo precio de sus automóviles híbridos. Aunque las ventas de Fabrikam aumentan constantemente año tras año, se ha producido un aumento significativo en las tasas de error de los motores híbridos durante el primer año en los automóviles vendidos a los clientes. Para que Fabrikam Motors mantenga su alto nivel de servicio, debe implementar una forma más eficaz para pedir piezas del motor híbrido a Contoso Hybrid.
A continuación se presentan conceptos relacionados:
Federación de identidades. Explica el establecimiento de la federación entre Contoso Hybrid y Fabrikam Motors para que los usuarios de Fabrikam usen un inicio de sesión único al obtener acceso a los recursos de Contoso Hybrid.
Delegación de identidades. Explica la posibilidad de obtener acceso a los recursos de un servicio web de Contoso Hybrid que requiere un token ActAs; es decir, el servicio requiere la identidad del llamador inmediato (normalmente, la identidad del servicio) y del usuario original que inició la solicitud (normalmente, la identidad del usuario interactivo).
Delegación de identidades
Este escenario describe una aplicación que necesita obtener acceso a recursos back-end que requieren la cadena de delegación de identidad para realizar comprobaciones de control de acceso. Normalmente, una cadena de delegación de identidad simple consta de información sobre el llamador inicial y la identidad del llamador inmediato.
Con el modelo de delegación kerberos en la plataforma Windows actual, los recursos back-end solo tienen acceso a la identidad del autor de la llamada inmediata y no a la del autor de la llamada inicial. Este modelo se conoce normalmente como el modelo de subsistema de confianza. Windows Identity Foundation (WIF) mantiene la identidad del autor de la llamada inicial y del llamador inmediato en la cadena de delegación mediante la propiedad Delegate().
En la figura 1 se muestra un escenario de delegación de identidad típico en el que un empleado de Fabrikam obtiene acceso a los recursos expuestos en una aplicación de Contoso.com. Figura 1. Notificaciones: autenticación de federación
Los usuarios ficticios que participan en este escenario son:
Francisco: empleado de Fabrikam que desea obtener acceso a los recursos de Contoso.
Daniel: desarrollador de aplicaciones de Contoso que implementa los cambios necesarios en la aplicación.
Antonio: el administrador de TI de Contoso.
Los componentes implicados en este escenario son:
web1: una aplicación web con vínculos a los recursos back-end que requieren la identidad delegada del llamador inicial. Esta aplicación se crea con ASP.NET.
Un servicio web que obtiene acceso a un equipo que ejecuta Microsoft SQL Server y que requiere la identidad delegada del llamador inicial y del llamador inmediato. Este servicio se crea con Windows Communication Foundation (WCF).
sts1: un servicio de token de seguridad (STS) que ocupa el rol de proveedor de federación y emite las notificaciones que la aplicación (web1) espera. Mantiene una relación de confianza con Fabrikam.com y también con la aplicación.
sts2: un STS que ocupa el rol de proveedor de identidad para Fabrikam.com y que proporciona un extremo que el empleado de Fabrikam usa para autenticarse. Mantiene una relación de confianza con Contoso.com, de modo que los empleados de Fabrikam pueden acceder a los recursos en Contoso.com.
Tenga en cuenta que el término "token ActAs" hace referencia a un token que emite un STS y que contiene la identidad del usuario. La propiedad Delegate() contiene la identidad del STS. Como se muestra en la figura 1, el flujo de este escenario es:
La aplicación Contoso está configurada para obtener un token actas que contiene tanto la identidad del empleado de Fabrikam como la identidad del llamador inmediato en la propiedad Delegate(). Daniel implementa estos cambios en la aplicación.
La aplicación de Contoso se configura para pasar el token ActAs al servicio back-end. Daniel implementa estos cambios en la aplicación.
El servicio web de Contoso se configura para validar el token ActAs llamando a sts1. Antonio permite que sts1 procese las solicitudes de delegación.
Francisco, un usuario de Fabrikam, obtiene acceso a la aplicación de Contoso y se le otorga acceso a los recursos back-end.
Autenticación federada
La autenticación federada permite a un servicio de token de seguridad (STS) en un dominio de confianza proporcionar información de autenticación a un STS en otro dominio de confianza cuando hay una relación de confianza entre los dos dominios. En la figura 2, se muestra un ejemplo de esto.
Figura 2. Notificaciones: escenario de federación
Un cliente en el dominio de confianza Fabrikam envía una solicitud a una aplicación de usuario de confianza en el dominio de confianza Contoso.
El usuario de confianza redirige el cliente a un STS en el dominio de confianza Contoso. Este STS no tiene conocimiento del cliente.
El STS de Contoso redirige el cliente a un STS en el dominio de confianza Fabrikam, con el que el dominio de confianza Contoso tiene una relación de confianza.
El STS de Fabrikam comprueba la identidad del cliente y emite un token de seguridad para el STS de Contoso.
El STS de Contoso usa el token de Fabrikam para crear su propio token, que envía al usuario de confianza.
El usuario de confianza extrae las notificaciones del cliente desde el token de seguridad y toma una decisión de autenticación.
En este escenario se describe una experiencia de inicio de sesión para un empleado asociado cuando intenta obtener acceso a los recursos del dominio de otro compañero. Solo debe iniciar sesión una vez. Hay tres actores principales en un escenario de federación: un proveedor de identidades, un proveedor federado y un usuario de confianza. WIF ofrece API para crear los tres jugadores. En la figura se muestra un escenario de federación típico donde un empleado de Fabrikam desea obtener acceso a los recursos de Contoso.com sin necesidad de volver a iniciar sesión, es decir, usando el inicio de sesión único. Figura 3. Notificaciones: escenario de delegación de identidades
Los usuarios ficticios que participan en este escenario son:
Francisco: empleado de Fabrikam que desea obtener acceso a los recursos de Contoso.
Daniel: desarrollador de aplicaciones de Contoso que implementa los cambios necesarios en la aplicación.
Antonio: el administrador de TI de Contoso.
Los componentes implicados en este escenario son:
web1: una aplicación web de pedidos de piezas que se crea con ASP.NET y controla el acceso a las piezas relevantes.
sts1: un STS que cumple el rol de proveedor de federación en Contoso.com y emite notificaciones que espera la aplicación (web1). Ha establecido confianza con Fabrikam.com y está configurado para permitir el acceso a los empleados de Fabrikam.
sts2: un STS que cumple el rol de proveedor de identidades en Fabrikam.com y proporciona un extremo en el que se autentican los empleados de Fabrikam. Ha establecido confianza con Contoso.com, por lo que los empleados de Fabrikam pueden obtener acceso a los recursos de Contoso.com.
Como se muestra en la figura 3, el flujo de este escenario es:
El administrador de Contoso Antonio configura la relación de confianza entre la aplicación (usuario de confianza) y sts1.
El administrador de Contoso Antonio configura la relación de confianza con sts2 como proveedor de identidades.
El administrador de Fabrikam Francisco configura la relación de confianza con sts1 como proveedor de federación y, a continuación, obtiene acceso a la aplicación.