Dentro de Microsoft.comUso de los Servicios de federación de Active Directory (ADFS)

Jim Guthrie

En Microsoft proporcionamos una extranet para dar a nuestros socios acceso a importantes recursos internos. La arquitectura de la extranet necesita que cada participante ajeno a la organización tenga una cuenta de dominio única para este espacio. Esta cuenta la crean y administran empleados de Microsoft, en lugar de los

socios, por razones obvias. Sin embargo, aunque es funcional, la experiencia para el usuario puede ser poco satisfactoria y la carga en Microsoft para administrar todos esos usuarios de asociados consume muchos recursos.

Aquí se muestra cómo funciona la extranet en estos momentos. Cuando un cliente o un socio inician la sesión en una aplicación, se solicita que introduzcan sus credenciales. Durante la misma sesión, si ese usuario decide obtener acceso a un recurso diferente se le pedirán de nuevo sus credenciales. Esto continúa mientras salte de un recurso al siguiente. Si el usuario ha iniciado sesión en una única aplicación que usa varios recursos, como una base de datos financiera, tendrá que autenticarse en cada uno de los recursos de forma independiente. Esto puede ser un procedimiento incómodo y molesto para los usuarios.

Afortunadamente, mediante los Servicios de federación de Active Directory® (ADFS), podemos resolver el problema de la múltiple autenticación muy fácilmente, y usted también. ADFS es un componente R2 de Windows Server® 2003 que facilita una confianza entre dos o más organizaciones para permitir compartir múltiples recursos a la vez que se mantiene la capacidad de cada organización de administrar su propio conjunto de usuarios. En esta columna muestro cómo Microsoft pretende usar ADFS para resolver el problema de la extranet de múltiples recursos, que le proporcionará la información que usted necesita para implementar una solución semejante. Sin embargo, antes de entrar en detalles, eche un vistazo a la Figura 1 para familiarizarse con la terminología básica de ADFS.

Figure 1 Terminología ADFS

Definición

de término

Federación

Un par de territorios o dominios que han establecido una confianza de federación de Active Directory.

Recurso de Servicio de Federación (FS-R)

Dirige las peticiones de autenticación entrantes al FS-A y a los recursos deseados.

Cuentas de servicio de federación (FS-A)

Proporcionan un token de cuenta para ser autenticado en FS-R.

Proxy del servicio de federación (FS-P)

Proporciona un nivel de separación entre los servidores FS y el tráfico entrante de Internet

.

Solicitud

Una instrucción que genera un servidor (por ejemplo, nombre, identidad, clave, grupo, privilegio o capacidad) acerca de un cliente.

Detección del territorio

Cada FS-A tiene un dominio o un territorio, en el que se guardan las credenciales de inicio de sesión. La detección del territorio determina qué FS-A se usa para la sesión de ADFS.

Una Solución ADFS

Cuando un usuario intenta obtener acceso a una aplicación de notificaciones ADFS, el explorador se envía al servicio de Federación de recursos (FS-R) para la detección del territorio. Aquí el usuario seleccionará el conjunto de credenciales que usará durante la sesión. En función del territorio que haya elegido el cliente, será redireccionada a continuación al servidor de Cuentas del Servicio de federación (FS-A). Es en este servidor donde recibirá una cuenta de token válida (en una cookie) que está basada en las credenciales que ella introdujo en forma de Windows Live™ ID (anteriormente una cuenta de Passport), Autenticación integrada de Windows o autenticación SSL (véase la Figura 2). En este modelo, es cada organización la que deberá mantener su propio servidor de federación de cuenta. En el caso de los servidores de socios de Microsoft, esto quita la carga sobre Microsoft.com para administrar cada cuenta en el entorno. Por supuesto, si usted implementa ese nivel de responsabilidad deberá seleccionar cuidadosamente las organizaciones con las que se asocie y asegurarse de que administren activamente su información de cuenta.

Figura 2** Flujo ADFS **(Hacer clic en la imagen para ampliarla)

La siguiente parada en la ruta es volver al servidor FS-R para intercambiar el token de la cuenta por un token de recurso. En nuestra configuración, este token contiene una lista completa de los permisos que han sido concedidos al usuario a través del proceso de mapeo de notificaciones que se lleva a cabo en el FS-R. Una vez que se ha recibido el token, ese usuario obtiene la posibilidad de inicio de sesión único (SSO) sobre las aplicaciones de notificaciones ADFS mientras la sesión esté abierta o hasta 24 horas de forma predeterminada (esta ventana es configurable). El resultado es que usted ha habilitado SSO a estas aplicaciones de notificaciones ADFS, lo que deriva en una experiencia más segura y eficiente para el cliente. Para obtener un tutorial completo del proceso de autenticación de ADFS, consulte el artículo de Matt Steele en la edición de julio de 2006 de TechNet Magazine titulado "Simplificando el inicio de sesión único con ADFS".

Para mantener la seguridad de los recursos corporativos de Microsoft, hemos aislado el lado de Internet de la extranet del lado corporativo, lo que significa que cada servidor es potencialmente de doble-pertenencia. Se permite una confianza de un solo sentido a los usuarios corporativos internos y se usan los servidores para proporcionar la protección necesaria. Tenemos también un dominio independiente para el espacio de la extranet donde ofrecemos a usuarios externos el acceso a los recursos que necesitan.

El equilibrio de carga y los cambios en los archivos de la directiva ADFS fueron dos áreas importantes de problemas durante la implementación. El equilibrio de la carga fue un desafío tanto a nivel global como local. Inicialmente en producción usaremos el equilibrio de carga global de nuestros socios de red de entrega de contenido (CDN) Akamai o Savvis para los clústeres de servidor web cliente en dos regiones. Esto asegurará la disponibilidad del sistema para usuarios finales incluso en el improbable evento de que se desconecten un par de servidores regionales. Esto se consigue con la automatización de la conmutación por error basada en servicios de control de estado ofrecidos por los CDN. Además, tenemos la capacidad de agregar fácilmente más clústeres en el futuro. Como un ahorro de costos, nuestras implementaciones de preproducción han elegido no usar el servicio CDN.

En el nivel regional hemos emparejado los servidores para la conmutación por error a través de clústeres de equilibrio de carga de red (NLB). No usamos ninguna característica especial de equilibrio de carga, de modo que esto podría haber sido conseguido fácilmente mediante hardware. Sin embargo, de nuevo utilizamos NLB para obtener ahorro en los costos. Esta configuración ofrecerá suficiente estabilidad para asegurar un tiempo de actividad del 99,9 por ciento en todos los entornos compatibles.

Otro desafío que afrontamos fue el de comprobar que el archivo de la directiva de ADFS, la espina dorsal de ADFS, fuese distribuida correctamente a través de nuestro entorno y que los cambios realizados en el mismo también sean replicados. Para lograr esto, usamos otra característica integrada de Windows Server 2003 R2 (Replicación de sistema de archivos distribuidos (DFS-R)), un nuevo motor de replicación multi master basado en estado. En cada uno de los servidores back-end hemos habilitado una pertenencia a grupos DFS-R con una replicación de malla completa de 24 horas. Ahora, ocurra donde ocurra el cambio en el archivo de la directiva, se distribuirá a todos los servidores. Mientras controlemos quién puede modificar el archivo, tendremos un servicio estable de alta disponibilidad.

Hemos tratado de asegurar que todos los cambios se realicen a través del complemento de ADFS. Sin embargo, en la práctica vimos que ocasionalmente debemos actualizar este archivo manualmente. Al actualizar manualmente es importante recordar que ADFS mantiene un seguimiento de la versión de este archivo. Por lo tanto, usted debe incrementar el archivo para que sus cambios se reflejen en el entorno:

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion> 

También tiene que recordar que, como todo XML, el archivo de directivas XML distingue entre mayúsculas y minúsculas. A través del archivo de directivas XML hay muchas referencias a las aplicaciones u otros servidores de ADFS y en todos los casos se deben copiar al pie de la letra de servidor a servidor. Tenga en cuenta los siguientes ejemplos comunes donde el primero, RevocationCheckFlags, se introdujo manualmente y el segundo es una URL de aplicación de confianza modificada desde la interfaz de usuario:

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

Para un nivel de seguridad adicional usamos otro componente de ADFS, el Proxy de servicio de Federación (FS-P), que asegura que en los FS-R se quite un nivel del acceso directo de solicitudes entrantes de Internet. Una manera singular mediante la que hemos implementado proxies en Microsoft.com es a través del uso de un solo conjunto de proxies para hospedar varios entornos ADFS en nuestra área de preproducción. Curiosamente, durante la evolución inicial de la tecnología, descubrimos que necesitábamos hacer una simple modificación en una clave de registro para que esto sucediera. La clave se encuentra en HKLM\Software\Micro­soft\WebSSO. Cambiando simplemente el valor del directorio inicial en esta clave podrá usar el proxy para varios entornos. El valor predeterminado fue:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

Para intercambiar los entornos, la clave cambiaría de la siguiente manera:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

La creación de un archivo por lotes puede simplificar la administración de este proceso. Desafortunadamente la versión actual del complemento MMC para ADFS no admite intercambio de entornos, ya que hay una relación de uno a uno entre el proxy y el recurso o el servidor de cuentas. Esta es la única manera de maximizar la utilización de los servidores proxy. El resultado final es que supone un gran ahorro de costos ya que limita el número de servidores físicos necesarios por muchos entornos diferentes que usted elija hospedar.

Desde el punto de vista de la arquitectura nosotros ejecutamos nuestro entorno de preproducción con equipos virtuales (otra medida de ahorro de costos). Esto elimina la necesidad de comprar y albergar seis servidores adicionales. Hasta la fecha, no hemos tenido problemas de rendimiento. Sin embargo, para satisfacer la creciente demanda en el entorno de producción hemos elegido usar equipos físicos de mayor rendimiento.

No sólo para Active Directory

Microsoft.com no sólo usa cuentas de Active Directory para la autenticación, sino también hemos integrado correctamente cuentas de Windows Live ID. Hemos visto que usando Windows Live ID (WLID) 4.5, podemos usar una cuenta individual Windows Live ID para delegar el acceso a recursos de Microsoft utilizando una transformación de notificaciones personalizadas. Esto es una gran victoria para lograr la autenticación SSO ya que ya no necesitaremos una cuenta de dominio específica.

Desafíos pendientes

El mayor desafío al que nos enfrentamos en este momento es la administración de ADFS para compartir certificados de firma de token. Usamos certificados estándar que normalmente siguen siendo válidos durante un año sin necesidad de renovación. En el momento de la renovación cada uno de los servidores apropiados tendrá que ser actualizado en concordancia, lo que tendrá un efecto considerable en los FS-R. Aunque es fácil de manejar con 15 ó 20 federaciones, la escala en la que nos gustaría pensar es, por lo menos, de cientos o miles. Esto requeriría de personal a jornada completa para la administración de certificados SSL para un solo entorno. Tenemos varios equipos buscando los mejores métodos para automatizar esta solución pero no se ha decidido una línea de acción.

Otro desafío pendiente es que no todas las aplicaciones incluyen notificaciones ADFS de serie. Será necesaria cierta programación para que los sitios aprovechen la oportunidad de ADFS. Trabajamos junto con el equipo de Microsoft® Office SharePoint® Services para asegurar que la siguiente generación de SharePoint sea compatible con nuestras necesidades de implementación para ADFS.

Conclusión

Hay varios factores que considerar a la hora de tomar la decisión de migrar a un modelo ADFS. Uno es el número de recursos a los que obtendrán acceso los clientes. El proceso de configuración de una confianza federada entre organizaciones puede ser una tarea trivial, pero escribir, revisar y ejecutar directivas de acceso aceptables lleva tiempo y esfuerzo. Por tanto si usted tiene sólo un recurso al que sus clientes obtengan acceso, tendrá que decidir si el esfuerzo merece la pena. Sin embargo, a medida que crece el número de recursos aumentan también las prestaciones.

Si desea más información, consulte Introducción a ADFS y Servicios de federación de Active Directory (ADFS): Una ruta hacia la identidad federada y la administración de acceso.

Jim Guthrietrabaja para Microsoft en el equipo de Operaciones de Microsoft.com donde, además de desafrrollar su trabajo con ADFS, es Ingeniero de sistemas en el equipo de soporte de la plataforma Enterprise Portal.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.