UNIVERSIDAD DON BOSCO VICERRECTORÍA ACADÉMICA FACULTAD DE INGENIERÍA TRABAJO DE GRADUACIÓN DEFINICIÓN DE LOS COMPONENTES PARA EL DESARROLLO DE UNA SOLUCIÓN SSO EN ENTORNOS EMPRESARIALES PARA OPTAR AL GRADO DE MAESTRO EN ARQUITECTURA DE SOFTWARE ASESOR MAESTRO JOSÉ MARIO HERNÁNDEZ PRESENTADO POR ANTONIO VLADIMIR MARTEL AVELAR SAÚL ÁLVAREZ PACHECO ANTIGUO CUSCATLÁN, LA LIBERTAD, EL SALVADOR, CENTRO AMÉRICA AGOSTO 2019 SSO en entornos empresariales 2 Índice Introducción .................................................................................................................................... 4 Capítulo I - Planteamiento del problema ........................................................................................ 5 1.1 Descripción............................................................................................................................ 5 1.2 Antecedentes ......................................................................................................................... 5 1.3 Objetivos ............................................................................................................................... 6 1.4 Justificación ........................................................................................................................... 6 1.5 Delimitación .......................................................................................................................... 7 Capítulo II – Estado del arte ........................................................................................................... 9 2.1 Antecedentes ......................................................................................................................... 9 2.1.1 Tecnologías SSO actuales ............................................................................................................ 9 2.1.2 Soluciones por suscripción......................................................................................................... 11 2.1.3 Guía para selección de candidatos ............................................................................................. 20 2.2 Componentes de un SSO ..................................................................................................... 22 2.2.1 Autenticación ............................................................................................................................. 22 2.2.2 Comunicación ............................................................................................................................ 24 2.2.3 Seguridad ................................................................................................................................... 25 2.3 Servidores de identidad ....................................................................................................... 26 2.3.1 Active Directory Federation Services (ADFS) .......................................................................... 26 2.3.2 Open LDAP ............................................................................................................................... 28 2.3.3 Autenticación en servidor de correos POP3............................................................................... 29 2.3.4 Autenticación en Bases de Datos ............................................................................................... 33 2.4 Servidores WEB .................................................................................................................. 34 2.4.1 Apache HTTP Server ................................................................................................................. 35 2.4.2 Internet Information Services ..................................................................................................... 38 2.5 Comunicación entres servidores.......................................................................................... 41 2.5.1 Protocolos de comunicación ...................................................................................................... 41 2.5.2 Servicios Web SOAP/REST ...................................................................................................... 50 2.6 Seguridad en la comunicación de aplicaciones ................................................................... 55 2.6.1 Certificados de Seguridad .......................................................................................................... 55 2.6.2 Tokens ........................................................................................................................................ 56 2.7 SSO como un Middleware .................................................................................................. 57 Capítulo III – Metodología de investigación ................................................................................ 59 SSO en entornos empresariales 3 3.1 Tipo de investigación .......................................................................................................... 59 3.2 Unidades de análisis ............................................................................................................ 59 3.3 Variables.............................................................................................................................. 60 3.4 Procedimiento de investigación y desarrollo de instrumentos ............................................ 61 3.4.1 Procedimiento ............................................................................................................................ 62 Capítulo IV – Análisis y discusión de resultados ......................................................................... 63 4.1 Dominio del problema ......................................................................................................... 63 4.1.1 Resolución de la problemática ................................................................................................... 64 4.1.2 Propuesta de solución................................................................................................................. 64 4.2 Discusión de resultados ....................................................................................................... 65 4.3 Requerimientos.................................................................................................................... 68 Capítulo V – Diseño de propuesta ................................................................................................ 71 5.1 Diseño de arquitectura ......................................................................................................... 71 5.2 Modelado de datos .............................................................................................................. 73 5.3 Diseño inicio de sesión único .............................................................................................. 76 5.4 Diseño Portal Web. ............................................................................................................. 77 5.5 Procesos de integración ....................................................................................................... 78 Capítulo VI – Conclusiones .......................................................................................................... 80 6.1 Tecnologías de SSO actuales. ............................................................................................. 80 6.2 Recomendaciones ................................................................................................................ 81 6.3 Costos .................................................................................................................................. 82 6.3.1 Costos de desarrollo ................................................................................................................... 82 6.3.2 Costos de adquisición................................................................................................................. 84 Referencias bibliográficas ............................................................................................................. 86 Anexos .......................................................................................................................................... 92 SSO en entornos empresariales 4 Introducción La diversidad de aplicaciones a las que un usuario debe tener acceso, requiere de forma individual un proceso de autenticación que valide las credenciales de ingreso a dichos aplicativos. Esta es una tarea habitual en entornos empresariales donde cada usuario tiene sus credenciales de acceso, pero al considerar este escenario por cada uno de los aplicativos se torna en una tarea compleja por la cantidad de datos de acceso que los usuarios deben administrar y recordar, esto no es práctico para los usuarios dado que suelen ser diferentes por cada aplicación y existen políticas que se aplican independiente por aplicación, por ejemplo: longitud, formato, tiempo de caducidad, y de nuevo se exige a los usuarios actualizar sus registros para considerar estos nuevos datos de acceso. Es una realidad que, a los numerosos sistemas que se debe acceder por un proceso de autenticación, las aplicaciones que se ejecutan requieren en su forma básica y simple las credenciales de acceso de los usuarios. Dichas credenciales se deben recordar (por parte del usuario) y ser validadas correctamente por cada aplicación. Lo anterior es una forma tradicional de administración de usuarios, pero lleva a una situación desventajosa porque demanda al usuario a administrar sus credenciales por cada aplicación a la que accede. Además, existe una administración aislada de usuarios entre las aplicaciones, lo que lleva a duplicar mantenimientos del mismo. Hay otros escenarios, por ejemplo, cuando un usuario deja de laborar para la empresa o bien se debe de remover o brindar el acceso a diferentes aplicaciones. En este escenario, se debe inactivar/eliminar el usuario por cada aplicación. Se sugiere un modelo para una gestión de acceso unificado que facilite a los administradores de sistemas y a los usuarios finales a utilizar un único conjunto de credenciales para todos los sistemas a los que tiene acceso. El proceso de autenticación suele ser un componente independiente y no reutilizable en los entornos empresariales y sus portafolios de aplicaciones basadas en la web, por lo tanto se da paso a una exploración de soluciones de terceros para, de cierta forma, centralizar la autenticación y explorar los componentes con el propósito de diseñar la arquitectura de una solución de esta naturaleza. Lo anterior permite analizar las soluciones actuales, evaluar los costos y beneficios y de igual forma tener los conceptos y guía para realizar el desarrollo interno de un servicio de autenticación y no depender de terceros. El documento está organizado en 5 partes: la primera parte presenta el planteamiento del problema, antecedentes y alcance de la investigación; la segunda presenta la revisión de la literatura relevante; la tercera parte describe la investigación realizada, siendo esta de enfoque cuantitativo, alcance descriptivo y de tipo proyectiva; la cuarta parte presenta los resultados de la investigación; y la última parte describe un diseño de propuesta que define los componentes para el desarrollo de una solución SSO en entornos empresariales. SSO en entornos empresariales 5 Capítulo I - Planteamiento del problema 1.1 Descripción Dado que no se cuenta con la visibilidad de los compontes de una solución SSO, resulta que en los entornos empresariales no existe realmente una arquitectura clara de cómo desarrollar una solución de este tipo. Si bien ya hay soluciones de terceros para esta situación, pero demandan, en algunas de gran envergadura, altos costos para su implementación. Estas soluciones permiten al equipo de TI gestionar el acceso a cualquier aplicación del dominio, y en algunas soluciones no importa si son empleados, socios, clientes, que las aplicaciones estén en la nube o en un data center (detrás de un firewall), sean aplicaciones web o móviles, la gestión de usuarios se vuelve una tarea ágil gracias a una plataforma estandarizada, de igual forma TI se beneficia ya de que las interrupciones de usuarios (relacionadas al proceso de autenticación) suelen ser menos. SSO ayuda a que las tecnologías de información se vuelvan más seguras, hacer a los usuarios finales más productivos y a mantener el cumplimiento del negocio. De igual forma en este contexto de soluciones SSO existe una gran variedad de conceptos y elementos técnicos que la investigación aborda con el fin de definirlos y poder luego identificarlos de forma clara para elaborar un marco de trabajo que ayude a la implementación de una solución, como resultado de la presente investigación. Lo anterior permite que equipos de TI, en entornos empresariales, puedan tomar de base esta investigación y analizando los resultados, permitirles decidir si es mejor tercerizar el acceso unificado (soluciones ya en el mercado) o proceder con un desarrollo interno y dar valor agregado al incluir elementos que otras soluciones no tengan o necesiten modificarse según lo requiera el negocio. 1.2 Antecedentes Hay situaciones en que las empresas cuentan con una gran variedad de aplicaciones en diferentes tecnologías y varios servidores, por lo que es necesario tener un inventario de aplicaciones y llevar el control de quienes tienen acceso y el tipo (nivel) que cada uno de los usuarios tiene. En entornos empresariales, se tienen varias aplicaciones con administración independiente de usuarios y roles, lo que conlleva a estructuras de datos tales como bases de datos o servidores de autenticación que implementan (por ejemplo) un Active Directory por cada una de las aplicaciones. En algunos casos, se cuenta con una gestión centralizada si son conjuntos de aplicaciones adquiridos de forma global como un ERP, CRM, entre otros. SSO en entornos empresariales 6 La arquitectura de un sistema SSO se puede clasificar en dos tipos [1]: simple y compleja, y estos a la vez, dependiendo del ámbito de operación, proveen cierta configuración. En esta investigación el ámbito de acción del SSO es para aplicaciones web, por lo tanto, se analizará la configuración denominada Web Single Sign-On (WSSO). WSSO [2] opera sobre aplicaciones y recursos que se acceden mediante la web, su objetivo principal es de autenticar a los usuarios en las diferentes aplicaciones a las que accede, evitando que el usuario ingrese sus credenciales más de una vez. Los usuarios acceden a las aplicaciones web por medio de un navegador, el WSSO implementa el uso de cookies [3] que le permiten recordar la información en vista que el protocolo HTTP no maneja estados. En la construcción de un framework de SSO se deben considerar elementos de comunicación entre todos los componentes que componen la arquitectura, como pueden ser los proveedores de identidad, los proveedores de servicios, las aplicaciones de negocio, y la navegación del usuario. La comunicación, como todas, se debe realizar mediante la implementación de protocolos que garanticen la seguridad de la misma y contribuya a estandarizar el manejo de peticiones y respuestas. 1.3 Objetivos Objetivo General Proponer un modelo de arquitectura para la implementación de un SSO en aplicaciones web para entornos empresariales, tomando como referencia las tecnologías y soluciones actuales. Objetivos Específicos 1. Formular las características tecnológicas que implementan las soluciones de SSO. 2. Detallar la construcción de un marco de trabajo genérico (framework) para SSO. 3. Analizar la implementación de una solución SSO considerando el costo de adquirir un servicio o herramienta de un proveedor y el costo de realizar un desarrollo interno, tomando de base la arquitectura sugerida en la presente investigación. 1.4 Justificación En los ambientas empresariales se tienen un gran número de aplicaciones desarrolladas internamente o por contratación externa, estas pueden correr en un servidor de aplicaciones o varios y pueden ser de la misma tecnología o diferentes. Implementar una solución de SSO puede ser una decisión estrategia que genera varias ventajas, entre ellas la seguridad y es que las políticas de seguridad establecidas se emplean a todas las aplicaciones, se puede monitorear todas las peticiones, identificar accesos no válidos. Facilita a los usuarios el manejar un único conjunto de credenciales para el acceso a las aplicaciones y para el equipo de TI este componente SSO en entornos empresariales 7 de autenticación, siendo vital en entornos empresariales, trabaja su comunicación de forma segura implementando protocolos y cifrados en la red. Todo el proceso de inicio de sesión se delega a una entidad externa. La implementación de una solución SSO, en su esencia básica, autentica al usuario una única vez y le permite acceder a otras aplicaciones (que forman parte del acceso centralizado) sin necesidad de volver a autenticar. Permite al usuario saltar entre las diferentes aplicaciones sin necesidad de iniciar sesión nuevamente. De igual forma este componente se vuelve vital en la configuración de los sistemas y al verse afectado, el daño se expande a todos los que lo consumen. Si un hacker accede a un sistema, bajo esta configuración, entonces este puede acceder a todas las aplicaciones que integran la solución, o bien puede comprometer el servidor del SSO y simplemente no será posible acceder a ningún sistema. Existen soluciones de paga que exponen todos los beneficios antes mencionados y otras funcionalidades que les permite diferenciarse de las otras opciones de software SSO. De igual forma es posible acceder a la documentación de los marcos de trabajo que estas soluciones implementan, a los medios de comunicación como lo son los protocolos y certificados, a la configuración de un repositorio centralizado de usuarios (similar a como actualmente lo pueden hacer con bases de datos locales), a los servidores de aplicación y cómo manejar el inicio de sesión y uso de cookies u otros componentes que permitan persistencia en la navegación. Esta investigación explora los componentes de las soluciones actuales, ventajas y desventajas para permitir al usuario valorar, de entre las opciones, cual es mejor para su necesidad. En un segundo punto se propone una solución de arquitectura que integre todos los componentes y requisitos de forma ordenada tal que, puede ser utilizado para realizar un desarrollo interno y tener la visión completa de que es y cómo se construye un middleware, en este caso un SSO. Se debe considerar los costos de adquirir una solución comercial o bien realizar un desarrollo interno, ventajas que se acoplen a la necesidad del negocio donde se desea implementar, y lo más significativo es definir el diseño de arquitectura que todo desarrollo de software necesita para guiar el proceso de implementación. 1.5 Delimitación La presente investigación lleva por objetivo el diseño de una solución SSO para entornos empresariales donde utilizan diferentes tecnologías en sus aplicaciones web. El primer punto es revisar las soluciones actuales de SSO para observar y analizar las tecnologías y componentes involucrados que habilitan un modelo de gestión de acceso unificado, una solución SSO. En un segundo punto es tomar las características necesarias para el funcionamiento de una solución SSO, y así describir el dominio del problema, los requerimientos funcionales y no funcionales, especificación de la interfaz de usuario para el portal del SSO, interfaces para la comunicación entre los componentes: aplicaciones web y los servidores de autenticación. SSO en entornos empresariales 8 Se propone un diseño de arquitectura con los componentes y la orquestación entre ellos, detallados a nivel macro, se establecen los modelos de datos necesarios para definir el SSO y adaptar las aplicaciones para la integración a la nueva plataforma, diseño de interfaces (inicio de sesión único, portal web), procesos de integración para acoplar las aplicaciones al nuevo flujo de autenticación manejado por el SSO. Además, se proporciona al lector todo el contexto para que, de forma objetiva, analice el camino más conveniente a tomar para la implementación de un SSO, ya sea como una solución tercerizada o realizar un desarrollo interno, tomando de base la arquitectura propuesta. Se consideran los costos y beneficios de soluciones actuales, así como los aspectos que se deben mejorar y a la vez valorar si son suficientes para cubrir la necesidad del negocio. SSO en entornos empresariales 9 Capítulo II – Estado del arte 2.1 Antecedentes 2.1.1 Tecnologías SSO actuales Un sistema SSO es aquel al que las aplicaciones delegan el proceso de identificación de usuarios, y este a la vez responde a las aplicaciones para notificar si se permite o no el acceso una vez concluido el proceso. Una solución de tipo SSO permite a los usuarios autenticarse de manera segura con múltiples aplicaciones y sitios web al iniciar sesión solo una vez, con un solo conjunto de credenciales (nombre de usuario y contraseña). Con SSO, la aplicación o el sitio web al que el usuario intenta acceder depende de un tercero de confianza [4] para verificar que los usuarios son quienes dicen ser. De igual forma implementa el nivel de autorización a los usuarios usualmente mediante la aplicación y creación de políticas de acceso a recursos. Estas soluciones presentan beneficios considerados principalmente en tres categorías [5]: 1. Facilidad de uso: Los usuarios finales no tienen que recordar una gran cantidad de nombres de usuarios y contraseñas. Simplifica el acceso. 2. Implementación: Habilita una gestión centralizada de usuarios y autorizaciones, evitando que sean las propias aplicaciones las que implemente estos mecanismos y delegan al SSO su manejo. El proceso de aprovisionamiento de usuarios se agiliza en todas las aplicaciones involucradas. De igual forma, la activación o baja de usuarios se replica en las aplicaciones lo cual lo vuelve de cierta forma un proceso automatizado. Se integra como un middleware en el contexto de las aplicaciones, permitiendo la integración de diferentes fabricantes, sistemas y tecnologías. 3. Seguridad: Las políticas de contraseña aplican a todas las aplicaciones, fortaleciendo el uso de las mismas y evitando malas prácticas de contraseña o bien contraseñas débiles a estar presentes y comprometer los datos e información en las aplicaciones. Se debe considerar la sensibilidad de tener la validación de credenciales centralizada, y es que de igual forma compromete los procesos permitiendo que un intruso puede acceder a todas las aplicaciones que implementan la solución SSO. Es importante especificar realmente lo que es un sistema SSO y entender las diferencias con un almacén de contraseñas [4] o también llamado gestor de contraseñas, que en inglés se identifica como "password vault".  Password vault es un software que almacena usuarios y contraseñas para múltiples programas o sitios, en una ubicación segura y un formato encriptado. Los usuarios SSO en entornos empresariales 10 pueden acceder al password vault a través de un único nombre de usuario y contraseña. El password vault luego les proporciona la contraseña para el sitio web al que intentan acceder. Con el almacenamiento de contraseñas se puede tener el mismo conjunto de credenciales, pero debe ingresarlo cada vez que se navega a un sitio web o aplicación diferente.  Con SSO, después de iniciar sesión a través de la solución, se puede acceder a todas las aplicaciones y sitios web aprobados por la empresa sin tener que iniciar sesión nuevamente. En general, SSO se considera más seguro y elimina la necesidad del usuario a administrar varias contraseñas, se reduce la frecuencia con que se debe iniciar sesión y el volumen de credenciales almacenadas. La arquitectura de un sistema SSO se puede clasificar en dos tipos [1]:  Simple: En el que el sistema SSO es único y otorga acceso a los usuarios de un único dominio de seguridad.  Complejo o federado: Es una arquitectura propia de sistemas federados, en los que existe más de un sistema de autenticación (SSO), y entre los que existe algún mecanismo de interrelación o confianza. Generalmente este tipo de sistemas están compuestos por varios dominios de seguridad, habiendo un mecanismo SSO en cada uno de ellos. Existe una delimitación del concepto SSO para entornos web, denominado Web-SSO (WSSO), que de igual forma permite a los usuarios un inicio de sesión único para poder acceder a un grupo de aplicaciones web que requieren autenticación. Dependiendo del ámbito de operación, las soluciones proveen cierta configuración [2]: E-SSO: Enterprise Single Sign-On, sirve como una autenticación primaria que interactúa con aplicaciones secundarias, con el fin de completar los datos de inicio de sesión almacenados en los servidores de las aplicaciones. Es un sistema heterogéneo que gestiona la autenticación de usuario en entornos integrados al SSO. Es necesario que las aplicaciones secundarias tengan la capacidad de deshabilitar la pantalla de login. W-SSO: Web Single Sign-On, opera sobre aplicaciones y recursos que se acceden mediante la web y su objetivo principal es de autenticar a los usuarios en las diferentes aplicaciones a las que accede, evitando que el usuario ingrese sus credenciales más de una vez. Los usuarios que aún no han sido autenticados son redirigidos a un servidor de autenticación o servicio web que mediara el acceso. Kerberos [6]: Es un protocolo de autenticación de red, creado por el MIT. Los usuarios se registran en un servidor y estos obtienen un ticket (TGT, del término ticket-granting ticket), que es usado por las aplicaciones cliente para obtener acceso. La seguridad se basa en el uso de criptografía de clave secreta, que permite al usuario demostrar su identidad a un servidor (y viceversa) a través de una conexión de red insegura. SSO en entornos empresariales 11 Identidad federada: Corresponde a una solución de gestión de identidad, que permite usar las credenciales disponibles en un sistema de autenticación en otros, y esto a la vez de una misma organización u otras externas. Se basa en el “círculo de confianza” entre las diferentes partes y hace uso de estándares para el intercambio de información entre dominios. Una ventaja es que no se requiere dar acceso a sistemas o compartir componentes tecnológicos, seguridad y autenticación. OpenID: Sistemas de autenticación distribuidos y descentralizados, en la que cada aplicación debe autenticarse en un servidor OpenID mediante parámetros en la URL. Los sitios web que implementan OpenID no requieren una cuenta de usuario, sino el identificador creado en el servidor. Los recursos centralizados son gestionados por proveedores de identidad y de servicios [7], conocidos en inglés como Identiy Provider (IdP) y Service Provider (SP) respectivamente.  IdP: Se refiere a una estructura de datos que contiene las identidades de los usuarios y maneja toda la información necesaria para la autenticación. Es posible conectar los usuarios a los recursos tecnológicos que lo requieren, desde una ubicación centralizada.  SP: Es una entidad que proporciona servicios web. Ejemplos de SP incluyen servicios de aplicaciones, de almacenamiento y servicios de internet. Un SP confía en un proveedor de identidad de confianza (IdP) o servicio de token de seguridad (STS) para la autenticación y autorización. En el modelo WS-Federation, un proveedor de servicios se denomina "parte que confía" (Relying Party en inglés). Proveedor es una forma genérica de referirse tanto a los IdP como a los SP, para términos sencillos y en relación con la gestión de identidades, un IdP se puede describir como un proveedor de servicios para almacenar perfiles de identidad y ofrecer incentivos a otros SP con el objetivo de federar las identidades de los usuarios. Sin embargo, se debe tener en cuenta que los IdP también pueden proporcionar servicios más allá de los relacionados con el almacenamiento de los perfiles de identidad. 2.1.2 Soluciones por suscripción Existe una gran variedad de soluciones SSO, y analizarlas todas no es posible. La presente investigación toma como referencia dos puntos clave para definir las soluciones SSO a analizar. Como primera referencia se aprecia la opinión de un sitio de revisión de productos para compradores de tecnología empresarial, llamado IT Central Station [8]. A continuación, una pequeña reseña del sitio [9]: “Es un sitio de alta calidad y confianza en el que los comentarios son escritos por usuarios reales. Nuestro proceso de autenticación triple con perfiles de LinkedIn, vigilancia policial comunitaria y la supervisión humana aseguran revisiones, sobre los productos, sean 100% auténticas... Los compradores de tecnología ahora SSO en entornos empresariales 12 investigan productos a través de la web y crean una lista corta de proveedores incluso antes de que comiencen a hablar con ellos”. IT Central Station dispone un trabajo de investigación donde se comparan las mejores soluciones y proveedores de SSO. El reporte “SSO Buyer’s Guide and Reviews May 2019” [10], de descarga libre, es basado en más de 65 experiencias de usuario reales con los productos más populares. Una segunda referencia es la popularidad de las soluciones, y la discusión [11][12] que se genera en torno a estas respecto de cuál es mejor, las similitudes y diferencias que existen. Se concluye entonces analizar las siguientes soluciones por suscripción: Solución Número de vistas Número de veces comparado con otro producto Okta 1° 1° Auth0 2° 2° OneLogin 5° 3° Tabla 1: IT Central Station, posición según factor de calificación [10]. Okta [13] Es un servicio de gestión de identidades de nivel empresarial para aplicaciones basadas en la web, tanto en la nube como detrás de un firewall. Provee un sistema integrado que conecta de forma segura a cualquier persona, a través de cualquier dispositivo, a las tecnologías que necesiten. Con más de 6,000 integraciones predefinidas para proveedores de aplicaciones e infraestructura, los clientes de Okta pueden usar de manera fácil y segura. Más de 6,100 organizaciones, entre ellas 20th Century Fox, JetBlue, Nordstrom, National Geographic, Western Union, DocuSign, confían en Okta para ayudar a proteger las identidades de sus fuerzas de trabajo y empleados. Top de comparaciones [10]  Auth0 vs. Okta - Comparado el 30% del tiempo.  OneLogin vs. Okta - Comparado el 17% del tiempo.  Microsoft Azure Active Directory Premium vs. Okta - Comparado el 16% del tiempo. SSO en entornos empresariales 13 Características de Okta SSO: Inicio de sesión único.  Verifica la contraseña de un solo uso (OTP por sus siglas en inglés de One-Time Passsword).  Integración confiable para SSO en todas sus aplicaciones web y móviles, con un motor de federación completo y políticas de acceso flexible.  Integración a cualquier aplicación o API moderna: Se debe proporcionar una URL y configurar la integración con el asistente de Okta.  Soporte de integración con: SWA (Secure Web Authentication): Uso de credenciales para inicio de sesión. SAML 2.0: Uso del protocolo para iniciar sesión en las aplicaciones. OpenID Connect: Uso del protocolo para iniciar sesión en las aplicaciones.  Soporte para servir como una federación IdP o SP. Directorio seguro con integración  Un almacén de usuarios flexible y seguro, integración a AD / LDAP en múltiples dominios y restablecimiento de contraseñas de AD / LDAP de autoservicio.  Política de contraseñas con opciones de complejidad.  Política de contraseña basada en grupo.  Almacenamiento y transformación de atributos enriquecidos para soportar escenarios de autorización y SAML enriquecidos basados en atributos.  Integración de IDP de terceros con SAML de entrada y OpenID Connect de proveedores de identidad externos. Informes de seguridad en tiempo real  Visor de eventos e informes incorporados para descubrir y solucionar anomalías de seguridad y acceso. Autenticación adaptativa  Acceso seguro para todos los usuarios con autenticación de dos factores a través de Okta Verify OTP, incluido para todos los clientes de SSO.  Establece políticas inteligentes de acceso y autenticación basadas en el contexto (ubicación, dispositivos, red) de inicio de sesión.  Informes y auditorías simples: registros de autenticación detallados, como intentos de inicio de sesión, con informes predefinidos para auditorías y fácil integración con herramientas de seguridad. Machine Learning [14] SSO en entornos empresariales 14  Solución de autenticación basada en riesgo con capacidades de aprendizaje automático (machine learning): Anunciado en San Francisco el 2 de abril de 2019, las organizaciones ahora pueden automatizar las prácticas de seguridad e implementar técnicas de autenticación simplificadas. Cosas que se pueden mejorar según opiniones de profesionales, publicadas IT Central Station: “Todavía tuvimos que escribir varios programas / scripts internos para completar el proceso de aprovisionamiento del usuario. Okta no tiene la capacidad de aprovisionar cuentas de buzón para Exchange local o en un entorno híbrido O365. La función Group Push de Okta a AD no funcionó de manera confiable en nuestro entorno”. James Lambert, ingeniero de sistemas Sr. en una compañía de salud con 5,001-10,000 empleados “Las llamadas al servicio web RESTful y su respuesta parecen un poco lentas”. Jaskeerat Singh, consultor en una empresa de servicios tecnológicos con 201-500 empleados. Elementos de la arquitectura [15]: Escalabilidad: Capacidad para manejar automáticamente una cantidad creciente de trabajo y el potencial de ser ampliado para adaptarse a ese crecimiento. Confiabilidad: Capacidad para realizar sus funciones y operaciones previstas sin experimentar fallas. Seguridad: Procesos, herramientas y políticas para prevenir, detectar y responder a amenazas. “Al maximizar el aislamiento en una arquitectura multiusuario, Okta garantiza un 99,9% de tiempo de actividad y cero tiempos de inactividad planificados. De hecho, mantuvimos un tiempo de actividad del 100% en 2019 hasta la fecha, un tiempo de actividad del 99,9955% en 2018 y un tiempo de actividad del 99,9995% en 2017, incluso cuando aumentamos el 290% en autenticaciones por mes”. Héctor Aguilar - CTO @ Okta, Jon Todd - arquitecto jefe @ Okta. Como referencia, Okta describe las características de la arquitectura detrás de sus soluciones y comparte datos acerca de la carga de trabajo que recibe:  2.1Billones Identidades de aplicación gestionadas y aseguradas por Okta  550Millones solicitudes web por día  70Millones autenticaciones por día  Mitigación de riesgos  Implementación escalonada y Rollback  Independencia del proveedor de infraestructura  Ajuste de la carga de trabajo  Escalabilidad horizontal y vertical  Aislamiento geográfico SSO en entornos empresariales 15 Precios [16] Todos los productos tienen un precio por usuario por mes y se facturan anualmente. El precio indicado es para casos de uso típicos. $ 1,500 por contrato mínimo al año.  Single Sign-On: $2 por mes, por usuario.  SSO con autenticación adaptativa: $5 por mes, por usuario.  Descuentos por volumen están disponibles. OneLogin [17] En las empresas, la transformación digital se ve frenada por la naturaleza fragmentada de un entorno de TI híbrido. OneLogin rompe esa barrera, centralizando el acceso a las aplicaciones locales y en la nube. La plataforma de administración de acceso unificada (UAM por sus siglas en inglés de Unified Access Management) de OneLogin permite a los usuarios acceder de forma sencilla y segura a las aplicaciones y los datos que necesitan, en cualquier momento y en cualquier lugar. Con el portal de inicio de sesión único de OneLogin, los usuarios solo tienen que ingresar un conjunto de credenciales para acceder a sus aplicaciones web en la nube y detrás del firewall, a través de computadoras de escritorio, teléfonos inteligentes y tabletas. Aumenta enormemente la productividad al tiempo que mantiene los datos seguros. La seguridad de contraseña basada en políticas y la autenticación multifactor de OneLogin, aseguran que solo los usuarios autorizados tengan acceso a datos confidenciales. Puede implementar políticas de contraseña más exigentes, como la longitud requerida, la complejidad y las restricciones en la reutilización de la contraseña, así como el tiempo de espera de la sesión y la política de autoservicio para restablecer la contraseña para aumentar la protección sin impedir a sus usuarios. Más de 2,500 clientes empresariales [18] confían a nivel mundial en OneLogin para asegurar sus aplicaciones, organizaciones como Pacific Life, Yammer, Airbus son algunos de sus clientes que delegan la gestión de identidad y acceso a OneLogin. Top de comparaciones [10]  Okta vs. OneLogin - Comparado el 51% del tiempo  Auth0 vs. OneLogin - Comparado el 12% del tiempo  Microsoft Azure Active Directory Premium vs. OneLogin - Comparado el 6% del tiempo Características de OneLogin SSO: Portal SSO SSO en entornos empresariales 16  Con el portal de inicio de sesión único de OneLogin, los usuarios solo tienen que ingresar un conjunto de credenciales para acceder a sus aplicaciones web en la nube y detrás del firewall, a través de computadoras de escritorio, teléfonos inteligentes y tabletas. Esto aumenta enormemente la productividad al tiempo que mantiene los datos seguros. La seguridad de contraseña basada en políticas y la autenticación multifactor de OneLogin aseguran que solo los usuarios autorizados tengan acceso a datos confidenciales.  Políticas de contraseña más exigentes, como la longitud requerida, la complejidad y las restricciones en la reutilización de la contraseña, así como el tiempo de espera de la sesión y la política de autoservicio para restablecer la contraseña para aumentar la protección sin impedir a sus usuarios.  Fácil adición de aplicaciones personales, que no requieren la participación de TI.  Soporte de 21 lenguajes.  Habilita la técnica de almacén de contraseñas para aplicaciones no federadas. Inicios de sesión múltiples  El sistema de autenticación de inicio de sesión único permite crear cualquier número de inicios de sesión para el mismo tipo de aplicación. Si se tienen diferentes entornos de producción y de pruebas, la funcionalidad de inicio de sesión múltiple ahorra tiempo. Inicio de sesión social  La autenticación social permite a los usuarios finales iniciar sesión en OneLogin utilizando sus credenciales de proveedor de identidad social de servicios como Facebook, Google+, LinkedIn y Twitter. Esto proporciona una experiencia más ágil, ya que no se necesita crear una contraseña de OneLogin para acceder a las aplicaciones dentro del portal.  Inicio de sesión compartido para aplicaciones que no admiten varios usuarios al mismo tiempo. Enlaces de inicio de aplicaciones y enlaces profundos  Los usuarios no siempre tienen que acceder a las aplicaciones a través del portal SSO de OneLogin. Muchas veces, las aplicaciones se inician a través de enlaces en correos electrónicos, como notificaciones de intercambio de documentos o invitaciones a reuniones. Simplemente haga clic en el enlace y OneLogin le permite iniciar sesión automáticamente.  Pre-integrado con miles de aplicaciones web y nuevas aplicaciones se agregan cada día. Soporte de integración con  SAML 2.0: Uso del protocolo para iniciar sesión en las aplicaciones. Kits de herramientas SAML de código abierto para cinco plataformas de desarrollo web: PHP, Python, Ruby, Java, .Net.  OpenID Connect: Uso del protocolo para iniciar sesión en las aplicaciones. SSO en entornos empresariales 17 Documentación técnica para desarrolladores en el uso de estándares de comunicación, autenticación, llamadas a APIs, reportes. Autenticación adaptativa [19]  Aprovecha el aprendizaje automático (Machine Learning) para realizar evaluaciones de riesgo dinámicas que pueden detectar inicios de sesión de alto riesgo y desencadenar la autenticación multifactor.  Las puntuaciones de riesgo se calculan en función de la reputación de la red, la ubicación geográfica, la identificación del dispositivo y las anomalías de tiempo. Cosas que se pueden mejorar según opiniones de profesionales, publicadas IT Central Station  “Necesita aumentar la cantidad de conectores disponibles para conectarse a los diferentes puntos finales”. ManojKumar  “El tiempo de inactividad con OneLogin es algo que seguirá mejorando, pero está bien. El precio es bastante competitivo en comparación con otros productos”. ManojKumar  “Facilitar la personalización de la interfaz de usuario, debería ser más fácil configurar los ajustes de OneLogin en función de las necesidades del cliente”. ManojKumar - Gerente Regional de Operaciones en una empresa de servicios tecnológicos con 10,001+ empleados. Precios [20] Todos los productos tienen un precio por usuario por mes y requieren un número mínimo de usuarios. Plan de arranque  Single Sign-On con soporte estándar  $2 por mes, por usuario - 25 usuarios mínimos. Plan de empresa  SSO con seguridad basada en políticas, multifactor y gestión avanzada de usuarios  $4 por mes, por usuario - 10 usuarios mínimos. Plan ilimitado  Gestión total de la identidad para la empresa compleja  $8 por mes, por usuario - 5 usuarios mínimos. Complementos (100 usuarios mínimos)  Virtual LDAP: Integración con VPN, NAS  OneLogin Desktop: Extiende el SSO a macOS o máquinas Windows. SSO en entornos empresariales 18  Autenticación adaptativa: Utiliza el aprendizaje automático para la autenticación inteligente. Crea perfiles de usuario basados en ubicaciones de inicio de sesión típicas, horarios, direcciones IP, etc., y luego desafía los intentos de inicio de sesión anormales.  Extiende la gestión de identidad a las aplicaciones heredadas (legacy) Auth0 [21] Proporciona autenticación y autorización como un servicio. Cualquier aplicación (escrita en cualquier idioma o en cualquier pila) se puede conectar a Auth0 y definir los proveedores de identidad que se desea usar. En función de la tecnología de las aplicaciones, se elige uno de los SDK (o llamada a las API) y se conecta a la aplicación. Ahora, cada vez que un usuario intenta autenticarse, Auth0 verificará la identidad y enviará la información requerida a la aplicación. En la cartera de clientes de Auth0, se encuentran: Safari, Sprinkrl, JetPrivilege Características de Auth0 SSO:  Gratis para proyectos open-source sin ánimo de lucro.  Autorización máquina a máquina: Facilita la comunicación segura entre su API y los clientes externos no interactivos, así como las API internas con solo tocar un interruptor y protocolos basados en estándares.  Autenticación multifactor con guardián: Guardián iOS o Android para recibir notificaciones.  Detección de anomalías: Mantiene a los usuarios y servicios a salvo de filtraciones de contraseñas e intrusos. Protege y notifica a usuarios cuando se filtran las credenciales o cuando alguien está tratando de forzar la entrada en su cuenta.  Apoyo principal (premier): Amplio acuerdos de soporte 24x7x365.  Conectores para Active Directory y LDAP  Conexiones personalizadas a bases de datos a través de JavaScript que corre en un servidor Auth0. Soporte de integración con  OAuth 1, OAuth 2: Estándar de autorización que le permite a un usuario otorgar acceso limitado a sus recursos en un sitio, a otro sitio, sin tener que exponer sus credenciales  JSON Web Tokens: Estándar abierto que define una forma compacta y autónoma para transmitir de manera segura información entre las partes como un objeto JSON.  SAML 2.0: Formato de datos basado en XML de estándar abierto.  OpenID Connect: Capa de identidad que se encuentra sobre OAuth 2 y permite la verificación fácil de la identidad del usuario. SSO en entornos empresariales 19  WS-Federation: Estándar desarrollado por Microsoft, y usado extensivamente en sus aplicaciones. Auth0 proporciona integraciones de SSO para los siguientes servicios, se mencionan los principales:  Dropbox  Office 365  SalesForce  SharePoint  Slack  Microsoft Dynamics  Windows Active Directory RMS  Adobe Echosign  CloudBees Top de comparaciones [10]  Okta vs. Auth0 - Comparado el 71% del tiempo  OneLogin vs. Auth0 - Comparado el 10% del tiempo  SAP Customer Data Cloud vs. Auth0 - Comparado el 7% del tiempo Cosas que se pueden mejorar según opiniones de profesionales, publicadas IT Central Station: “Pueden hacer un mejor trabajo explicando lo que se supone que debe hacer a continuación para seguir correctamente un enfoque idiomático para usar la solución más allá de simplemente pasar un token de JWT a un servidor y hacer que el servidor verifique y luego firme para validar el token”. Michael M - Gerente de Servicios Tecnológicos Precios [22] Los precios son manejados en dos modos de suscripción, y estas a la vez bajo tres categorías dependiendo de las necesidades de la empresa. De igual forma los precios dependen del tipo y cantidad de usuarios que se desean adquirir. Los tipos de usuario pueden ser regulares o de empresa, y se diferencian según el tipo de conexión que se requiere para ellos. De igual forma hay otra clasificación de usuarios, y estos son basados en la autenticación que requieren. SSO en entornos empresariales 20 Se debe elegir usuarios con clasificación externa, aquellos externos a la compañía que deben ser autenticados en las aplicaciones o APIs desarrolladas. Usuarios con clasificación interna son empleados de la compañía que de igual forma deben ser autenticados en las aplicaciones o APIs desarrolladas. Categoría Suscripción mensual Suscripción anual (con esta suscripción se obtiene un mes gratis) Desarrollador  $13 – 1,000 usuarios activos regulares  $850 – 50,000 usuarios activos regulares  $143 – 1,000 usuarios activos regulares  $9,350 – 50,000 usuarios activos regulares PRO, usuarios externos  $59 - 100 usuarios activos regulares y 100 usuarios activos de empresa.  $1,625 - 10,000 usuarios regulares activos y 500 usuarios activos de empresa  $649 - 100 usuarios activos regulares y 100 usuarios activos de empresa.  $17,857 - 10,000 usuarios regulares activos y 500 usuarios activos de empresa PRO, usuarios externos con autenticación máquina a máquina (respectivos a configuración anterior)  5,000 tokens de acceso y configuración de usuarios seleccionados: $74  5,000 tokens de acceso y configuración de usuarios seleccionados: $1,640  5,000 tokens de acceso y configuración de usuarios seleccionados: $814  5,000 tokens de acceso y configuración de usuarios seleccionados: $18,040 PRO, usuarios internos  $200 – 100 empleados  $1,100 – 1,000 empleados  $2,200 – 100 empleados  $12,100 – 1,000 empleados EMPRESA N/A - Contactar al proveedor N/A - Contactar al proveedor Tabla 2: Precios por categoría y tipo de suscripción. Si la necesidad de usuarios sobrepasa lo detallado en la tabla anterior, se debe contactar con el proveedor. 2.1.3 Guía para selección de candidatos Las organizaciones analizan las características para seleccionar candidatos aceptables para proveedores de servicios SSO en entornos empresariales, y buscan que las soluciones sean de bajo costo, siempre y cuando cumplan con las especificaciones necesarias para cubrir los requisitos de un inicio de sesión unificado [23]. Se sugiere analizar las siguientes características: Fijación de precios SSO en entornos empresariales 21  Los precios normalmente en las organizaciones es la primera clave al momento de la toma de decisión para adquirir una solución o implementarla en las Empresas. Facilidad de uso  La complejidad debe ser lo más sencilla posible para poder ser administrado E implementado. Implementación  Se debe identificar que la solución pueda ser implementada dentro de la empresa que pueda ser acoplada en la estructura organización con la que se cuenta. Políticas de seguridad  Uno de los controles más verificados es la parte de la seguridad, refiriéndose a este como uno de los puntos más críticos en las aplicaciones. Autenticación SAML  Para poder manejar las autenticaciones y autorizaciones de mejor manera se tiene como referente el protocolo SAML. Protección con contraseña  Los diferentes controles de seguridad uno de ellos y el más crucial en muchos casos es la parte de las contraseñas, en líneas generales existen diferentes niveles de seguridad desde: Bajas, Medianas y altas.  Cada una de ellas comprende ciertas diferencias en cuanto la longitud y complejidad desde la inclusión de caracteres especiales, números, letras mayúsculas y minúsculas, además se deben manejar diferentes controles técnicos de protección de usuario.  Las configuraciones para estos controles de seguridad y niveles según se la política de seguridad de cada organización debe ser permitida. Autenticación Multifactor  Existen diferentes factores en las aplicaciones que requieren validaciones del usuario adicionales por ello uno de los requisitos necesarios es el manejo de una doble autenticación para ello las soluciones deben de proveer una validación de token u/o certificados de validación. Soporte SSO en entornos empresariales 22  La mayoría de las aplicaciones SSO deberá cumplir con un requisito importante para las organizaciones es poder adaptar las soluciones a sus políticas para ello la parte del mantenimiento debe estar siempre. 2.2 Componentes de un SSO 2.2.1 Autenticación Este componente en los SSO se encarga de verificar y validar las credenciales del usuario para brindar el acceso a las aplicaciones. Para comprender este componente veremos el proceso tradicional de los inicios de sesión y como se establece dentro del SSO. 1. Autenticación tradicional. Las autenticaciones tradiciones se refiere a que cada usuario debe de autentificarse en cada aplicación en la que desee acceder este proceso de manera individual para todas las aplicaciones se cuenta con un usuario y contraseña [24]. El proceso de autenticación tradicional:  Envía la información del usuario (usuario y contraseña).  Realiza la verificación con los datos almacenados (Active Directory, bases de datos, entre otros).  Se valida la petición del usuario y en caso sea exitoso se concede el acceso a las aplicaciones. Figura 1: Proceso tradicionales en la autenticación. Elaboración propia La autenticación tradicional establece que cada una de las aplicaciones necesita realizar el proceso de login y así obtener el acceso a las aplicaciones.  Login de aplicaciones: Cada vez que se desea ingresar a una aplicación, se debe realizar el proceso. SSO en entornos empresariales 23  La verificación: Esta acción se realiza internamente en la aplicación la cual recibe como parámetros las credenciales (usuario y contraseña)  Validación: Se realiza la verificación de los datos en un repositorio de datos (Active Directory, base de datos, otros) y cuando las credenciales del usuario son válidas, obtiene el acceso a la aplicación. 2. Autenticación SSO. Las soluciones SSO toma la responsabilidad de realizar la autenticación de las credenciales de usuarios, de este modo el SSO se encarga de velar la veracidad de las credenciales que sea pertenecientes y correctas de parte del usuario, cuando se realiza la verificación y validación y es autenticado se regresa un comprobante(Token) el cual se utiliza para enviarlo a la aplicación a la que se desea acceder cuando la aplicación lo recibe el y realiza la validación contra la entidad de autenticación (SSO). Además de validar el comprobante y su vigencia. Si es correcto, la aplicación da acceso al usuario, de este modo cuando desea ingresar a otra aplicación solamente se debe presentar el comprobante para realizar la autenticación nuevamente para la otra aplicación [25]. Figura 2: Proceso en la autenticación SSO. Elaboración propia La autenticación SSO, a diferencia del proceso tradicional, solamente se realiza una vez y da acceso a todas las aplicaciones. Detalle del proceso: 1. Ingreso de las credenciales (cuando no se ha iniciado sesión) se dirige a la solución SSO. 2. Se realiza la verificación y validación de la autenticación dentro del SSO. 3. Asigna el token el cual se envía al usuario para que pueda tener acceso a la aplicación. 4. Se redirige nuevamente a la aplicación, cuando esto se realiza ya se cuenta con el token por el lado del usuario. SSO en entornos empresariales 24 5. La aplicación realiza la validación del token contra el del SSO si es el asignado este ingresa a la aplicación de manera exitosa. Al realizar el proceso de autenticación y desea ingresar a otra aplicación. El SSO asigno un token al usuario y lo envía, El SSO verifica y validad el token para que la aplicación permita al usuario ingresar. Figura 3: Procesos de autenticación mediante Token. Elaboración propia Cuando el token es invalido o caduco su tiempo de validez se redirecciona al SSO para realizar la autenticación [26]. 2.2.2 Comunicación La comunicación en un sistema SSO debe ser segura, pues es un punto crítico y debe garantizar la integridad de las peticiones y respuestas que viajan en ella. Una arquitectura SSO maneja la comunicación dependiendo de los elementos que integre [27], como lo son el protocolo de comunicación, los proveedores de servicios y de identidades. Dependiendo de los elementos seleccionados, la comunicación utiliza conceptos como: token, certificados de seguridad, llaves secretas de cliente y servidor, cookies, y demás. Todo organizado entre los proveedores y las aplicaciones que consumen los servicios [28]. SSO en entornos empresariales 25 Figura 4: Comunicación entre los componentes de SSO [28]. 2.2.3 Seguridad Los componentes de seguridad en los SSO Son muy importantes en este tipo de soluciones ya que de cierto modo solo bastaría con un único usuario y contraseña para tener acceso de manera completa sobre las aplicaciones alojadas en la solución. Algunos de los atributos que preparan este componente de las soluciones SSO tenemos indispensables: Proveedor de Identidad (IDP), Proveedores de Servicios (SPs). Servicio de Token de Seguridad (STS) [29]. En el siguiente diagrama podemos comprender como se complementa cada uno de los componentes de seguridad antes mencionados para efectos de entendimiento a la comunicación entre sí de los componentes aquí mencionado tomaremos el diagrama siguiente. SSO en entornos empresariales 26 Figura 5: Seguridad en las aplicaciones SSO [29]. Se logra apreciar en la imagen anterior como se integran los componentes de seguridad antes mencionados los cuales se detallan cada uno por separado en el presente documentos en los siguientes apartados. 2.3 Servidores de identidad El espacio de administración de identidades es complejo, con varios componentes diferentes. La gestión de la identidad sustenta a la mayoría de las organizaciones, es el sistema nervioso central de la infraestructura de TI de una organización [30]. Le dice a los usuarios y recursos de TI quién puede hacer qué y sobre qué recursos. A medida que las organizaciones se hacen más grandes, el trabajo se vuelve más complejo y crítico. Los sistemas de control de identidad y acceso dentro de una organización abarcan varios recursos diferentes. Comienza con el servicio de directorio, que a menudo se conoce como el proveedor de identidad hasta los servicios de inicio de sesión único (SSO) y de autenticación multifactor (MFA) de las aplicaciones web. El IdP, sin embargo, es el cerebro de cualquier infraestructura de gestión de identidad. 2.3.1 Active Directory Federation Services (ADFS) Active Directory [31] (AD) es un producto de Microsoft que consta de varios servicios que se ejecutan en Windows Server para administrar los permisos y el acceso a los recursos en red. AD almacena los datos como objetos. Un objeto es un elemento único, como un usuario, grupo, aplicación o dispositivo, como una impresora. AD clasifica los objetos por nombre y SSO en entornos empresariales 27 atributos, por ejemplo, el nombre de un usuario puede incluir la cadena de nombre, junto con la información asociada con el usuario, como contraseñas y claves de Secure Shell (SSH). El servicio de federación de AD [32] (ADFS) es una solución de inicio de sesión único (SSO) creada por Microsoft. Como un componente de los sistemas operativos de Windows Server, proporciona a los usuarios acceso autenticado a aplicaciones que no son capaces de usar la autenticación de Windows integrada (IWA por sus siglas en inglés de Integrated Windows Authentication) a través de Active Directory (AD). Desarrollado para brindar flexibilidad, ADFS brinda a las organizaciones la capacidad de controlar las cuentas de sus empleados mientras simplifican la experiencia del usuario: los empleados solo necesitan recordar un único conjunto de credenciales para acceder a múltiples aplicaciones a través del SSO. ADFS administra la autenticación a través de un servicio de proxy alojado entre AD y la aplicación de destino. Utiliza una confianza federada, que vincula ADFS y la aplicación de destino para otorgar acceso a los usuarios. Esto permite a los usuarios iniciar sesión en la aplicación federada a través de SSO sin necesidad de autenticar su identidad directamente en la aplicación. Figura 6: Integración con AD [33]. El proceso de autenticación generalmente sigue estos cuatro pasos [32]: 1. El usuario navega a una URL proporcionada por el servicio ADFS. 2. El servicio ADFS luego autentica al usuario a través del servicio AD de la organización. 3. Al autenticarse, el servicio ADFS proporciona al usuario un reclamo de autenticación. 4. El navegador del usuario luego reenvía este reclamo a la aplicación de destino, que otorga o niega el acceso en función del servicio de confianza federada creado. ADFS nace de la necesidad de superar los desafíos de autenticación creados por AD [32] en un mundo en línea cada vez más conectado. AD e IWA han establecido limitaciones cuando se trata de la autenticación moderna, y no pueden autenticar a los usuarios que acceden a aplicaciones integradas de AD externamente. Este es un desafío en el lugar de trabajo moderno, SSO en entornos empresariales 28 donde los usuarios a menudo necesitan acceder a aplicaciones que no son de su propiedad o administradas por su organización de AD. ADFS resuelve el problema de los usuarios que necesitan acceder a las aplicaciones integradas de AD mientras trabajan de forma remota, ofreciendo una solución flexible mediante la cual pueden autenticarse utilizando sus credenciales de AD de organización estándar a través de una interfaz web. Permite a los usuarios de una organización acceder a las aplicaciones de otra organización más allá del ámbito de su dominio en AD. La configuración de los roles en ADFS se describen en el Anexo 1. 2.3.2 Open LDAP OpenLDAP es una implementación de código abierto del protocolo Lightweight Directory Access Protocol (LDAP) desarrollada por el proyecto OpenLDAP [34]. OpenLDAP comienza con el advenimiento de LDAP, creado en la década de 1990 por Tim Howes y sus colegas en la Universidad de Michigan [35]. LDAP se utilizó para crear rutas que podrían usarse para autenticar sistemas, aplicaciones basadas en servidores y bases de datos, entre muchos otros recursos de TI. LDAP pronto sería utilizado por los desarrolladores para crear OpenLDAP, una implementación de servidor de código abierto de LDAP. El protocolo, junto con Kerberos, también sirvió como uno de los núcleos de Active Directory, que se convertiría en el servicio de directorio comercial más popular. En 1998, se formó el proyecto OpenLDAP [36]. Comenzó a partir del software de la Universidad de Michigan y limpiaron los problemas conocidos en el código, expandieron la portabilidad de su plataforma y comenzaron una importante reingeniería. La reestructuración significativa del código ha dado como resultado estructuras internas notablemente flexibles que permiten la construcción de "back-ends" de bases de datos para acceder a los datos almacenados en diferentes tecnologías de almacenamiento de bajo nivel (Berkeley DB, SQL, LDAP, shell, meta, etc.). Otra reestructuración introdujo superposiciones (overlays el término en inglés) que brindan acceso a la lógica de las operaciones de directorio y permiten la introducción de nuevas capacidades sin modificar ninguno de los códigos principales de OpenLDAP. Todas estas extensiones se pueden cargar dinámicamente según sea necesario. La suite de OpenLDAP incluye [37]:  Slapd - demonio LDAP autónomo (servidor) (por sus siglas en inglés de stand-alone LDAP daemon).  bibliotecas implementando el protocolo LDAP.  Utilidades, herramientas y clientes de muestra. SSO en entornos empresariales 29 La arquitectura del servidor OpenLDAP tiene dos niveles, uno es el “frontend” que maneja el procesamiento del protocolo y las conexiones de redes. El segundo nivel es el backend que hace el trabajo real de almacenar o recuperar datos en respuesta a las solicitudes LDAP. Los backends se pueden compilar estáticamente en slapd, o cuando el soporte del módulo está habilitado, se pueden cargar varios backends y a la vez varias instancias de cada backend activas por vez. Generalmente una petición LDAP es recibida por el frontend, es decodifica y transferida a un backend para su procesamiento [38]. Cuando la petición es completada por el backend, se devuelve un resultado al frontend, quien luego transfiere el resultado al cliente LDAP. Una sobreposición (overlay) es un componente de software que puede ser insertado entre el frontend y el backend. Puede interceptar peticiones y lanzar otras acciones en ellas antes que el backend las reciba, de igual forma puede actuar sobre los resultados que llegan del backend antes que estos alcancen el frontend. Figura 7: Servidor OpenLDAP [39]. 2.3.3 Autenticación en servidor de correos POP3 La autenticación en los servidores de correos POP3 es manejada por los SMTP (Simple Mail Transfer Protocol) este protocoló provee la comunicación por medio de textos. La Autenticación del SMTP se lleva a cabo por medio del protocolo SMTP AUTH luego que se realiza la autenticación lo recibe el POP3 desde el servidor remoto al cliente local. Para almacenarlos y organizarlos de esta manera podemos acceder a los correos, aunque ya se encuentre de manera offline. Cuando ya se encuentran de manera local son removidos del servidor. El POP3 maneja los puertos 110 y 995 en donde el primero de estos no es cifrado y es SSO en entornos empresariales 30 el predeterminado en cambio el puerto 995 realiza la conexión de manera Cifrada. De esta forma al utilizar el SMTP como protocolo de transferencia utiliza el puerto 465 para el cifrado [40]. El método de acceso al servidor de correos se realiza por medio de TCP/IP de manera encriptada utilizando el puerto 995, Los comandos de POP3 están compuestos por un número limitado de caracteres de tres a cuatro incluyendo un parámetro o más. Las palabras claves diferencian mayúsculas y minúsculas las cuales consisten en ASCII y estos se separan por un único espacio a diferencia de las palabras claves los argumentos cuentan con una longitud de hasta 40 caracteres. Las sesiones de POP3 se manejan con tres estados diferentes: 1. Authorization: al establecer la conexión TCP y se ha recibido respuesta del servidor POP3. Un ejemplo de la respuesta del servidor POP3: S: +OK POP3 Server Ready Existen dos posibles mecanismos para la AUTHORIZATION por medio de un usuario y contraseña o el comando APOP, es necesario que al menos uno de estos mecanismos sea efectuado en el POP3, al establecer el acceso al agente de correos se adquiere un acceso exclusivo, esto para que los mensajes no sean eliminados o modificados antes que la sesión ingrese al estado de UPDATE, cuando este proceso se efectúa correctamente se ejecuta el indicador de estado positivo es entonces ingresa al estado de TRANSACTION [40]. En este estado no se cuenta con marcas de mensajes como eliminados, no se brinda acceso al agente de correo, cuando no se adquiere un bloqueo, por lo que es denegado el acceso y no es posible analizar, se genera un indicador negativo a la petición cuando el bloque es del servidor, este responde con la liberación del bloqueo previamente al rechazar el comando. Si logra generar el indicador con el estado negativo el servidor cierra la conexión, Si no se realice el cierre de la conexión, los clientes pueden generar un comando nuevo de AUTENTICACIÓN e iniciar nuevamente, de igual forma si no se desea el cliente puede generar el comando QUIT [41]. Al realizar la apertura del agente de correo en el servidor se asigna un número de mensaje a cada uno de los mensajes además de tomar el tamaño de los mensajes en los octetos. De este modo tendríamos el primer mensaje dentro de gestor de correos con la asignación “1” el segundo “2”, sucesivamente. De esta manera se agregan los números a los mensajes dentro del agente de correos, los comandos POP3 y las respuestas se representan los números de mensajes el tamaño es expresado en base 10 conocido como decimales. El estado de AUTHORIZATION maneja el QUIT de la siguiente manera: QUIT Arguments: none Restrictions: none Possible Responses: SSO en entornos empresariales 31 +OK Examples: C: QUIT S: +OK dewey POP3 server signing off 2. Transaction: cuando se realiza la identificación en el servidor POP3, bloqueado y abierto el buzón de correos de forma correcta. Se ha establecido el estado de TRANSACTION, en esta instancia el cliente puede emitir cualquiera de los comandos POP3. Luego de cada comando el servidor genera una repuesta, en definitiva, el cliente ejecuta el comando QUIT y la sesión POP3 cambia a UPDATE [40]. Los comandos validos en el estado de TRANSACTION: STAT Arguments: none Restrictions: may only be given in the TRANSACTION state El servidor POP3 genera la respuesta positiva con la información para el agente de correos, la información se genera en una lista llamada “lista de despliegue” en el agente de correos. Para los agentes de correos es requerido sea un formato determinado para las listas despegables. Las respuestas positivas se conforman por “+OK” continuo de un solo espacio, el número de mensajes. Seguido un Espacio y su tamaño en octetos, esta nota no es requerida en el tamaño del agente de correos, en la implementación mínima deben finalizar la línea en respuestas con un par de CRLF, Permiten al cliente realice el analices de los mensajes en el agente de correos. Los mensajes marcados como eliminados no aparecen en el total de los mensajes del agente de correos [40]. Possible Responses: +OK nn mm Examples: C: STAT S: +OK 2 320 LIST [msg] Arguments: a message-number (optional), which, if present, may NOT refer to a message marked as deleted Restrictions: may only be given in the TRANSACTION state SSO en entornos empresariales 32 Se establece un argumento y el servidor envía una respuesta positiva con una línea que contiene información para el mensaje, esta línea es llamada como lista escáner para cada mensaje. Cuando no se establece ningún argumento y el servidor envía una respuesta positiva la respuesta no contiene una línea de información si no multilínea. Después de la inicial +OK para cada uno de los mensajes por medio del agente de correos. El servidor POP3 responde con la lista de escáner para el mensaje. si no hay mensajes en el agente de correos, responde sin la lista de escaneo y genera una respuesta positiva con el octeto de determinación y un par de CRLF [40]. Se requiere que todos los servidores POP3 mantenga un formato establecido para los listados de escaneo. La lista de exploración consta del número de mensajes, con un único espacio y el tamaño del mensaje en los octetos. Así se establece el cálculo para el tamaño del mensaje porque todos los mensajes que se transmiten tienen mismo formato, el conteo del número de octetos para el mensaje dentro del host en el servidor puede ser diferente del número de octeto determinado en el mensaje por las convenciones locales para elegir el fin de la línea. Un ejemplo, si el host del servidor representa de manera interna el final de la línea como un solo carácter, el servidor POP3 solamente contara cada vez que aparezca el carácter en un mensaje como dos octetos. No se establece ningún requisito sobre lo que sigue en el tamaño del mensaje dentro de la lista de escaneo, se debe terminar la línea de respuesta con un par de CRLF en las implementaciones mínimas, las más avanzadas si puede contener más información, como se analiza desde el mensaje, (se describen en el Anexo 2) de la estructura del mensaje y los diferentes casos. 3. Update: El servidor POP3 libera todos los recursos adquiridos durante el estado anterior y cierra la conexión TCP. Cuando se ejecuta el comando de salida QUIT en el estado de TRANSACTION inicia la sesión UPDATE, además si se genera el comando QUIT desde la AUTHORIZATION se finaliza, pero no se ingresa al estado UPDATE [40]. Si se finaliza la sesión y no es por el lado del cliente no se genera el comando QUIT el servidor no ingresa al estado UPDATE y los mensajes se mantienen y no son eliminados del agente de correos. QUIT Arguments: none Restrictions: none El servidor POP3 identifica y elimina los mensajes que han sido marcados previamente como eliminados en la entrega de correos, genera la respuesta sobre el estado de la operación. Al generarse un error como la pérdida o escases de un recurso que se localizan a eliminar el mensaje, el agente de correos responde con la eliminación de algún número de mensajes o ninguno de los que han sido marcados como eliminados. SSO en entornos empresariales 33 Cuando finalmente se ejecuta los eventos en el estado UPDATE este ha eliminado correctamente los mensajes o no y se libera el bloqueo al acceso del agente de correos y se cierra la conexión TCP. 2.3.4 Autenticación en Bases de Datos La autenticación como tal se basa en el proceso para validar si la persona que está tratando de ingresar es la que debe ser. Las bases de datos es la serie de datos organizados y relacionados entre sí, los cuales son almacenados por medio de sistemas de información y almacenados de manera correcta para luego poder realizar la manipulación de estas [42]. Unas características que mencionar son:  Independencia lógica y física de los datos.  Redundancia mínima.  Acceso concurrente por parte de múltiples usuarios.  Integridad de los datos.  Consultas complejas optimizadas.  Seguridad de acceso y auditoría.  Respaldo y recuperación. La autenticación en base de datos es muy sencilla de comprender e implementar, inicialmente se debe comprender cuál es la estructura en la que se establece la autentificación en las bases de datos. Existen tres niveles de seguridad para poder realizar la autenticación en las bases de datos. El primer nivel de Acceso se establece en el servidor de este modo gestionar quienes pueden acceder al servidor, de igual forma se gestionan los roles que se está mandando desde la aplicación donde se encuentra Login. Segundo nivel es estando en el servidor de base de datos se debe asignar un usuario para tener acceso a las bases de datos que desea acceder, esto para cada una de las bases de datos que se desee ingresar el login de manera análoga [42]. El tercer nivel de acceso se establece cuando el acceso a la base de datos está abierto y este tiene acceso a sus objetos donde obtendrá la información sobre las credenciales de autenticación enviadas de esta forma se envía una respuesta de autorización o denegación. De este modo tiene acceso a las aplicaciones. SSO en entornos empresariales 34 Figura 8: Autenticación en base de datos. Elaboración propia La información no se envía como texto plano a través de la red de manera segura ya que se implementas diferentes medidas de seguridad en la data enviada uno de los controles como tal es el manejo de las contraseñas con un hash estas funciones criptográficas ayudan a que las contraseñas sean seguras además de nivel de complejidad de la estructura misma de la contraseña al ser de una longitud y combinaciones de números caracteres y letras los manejos de bloqueos por intentos fallidos y expiración de contraseñas de igual forma existen diferentes controles de seguridad. 2.4 Servidores WEB Los servidores web se conocen como servidor HTTP en donde se procesa una aplicación del lado del servidor ejecutando la conexión bidireccional, asíncronas con el cliente de este modo suministra una respuesta del lado del cliente a cualquier aplicación, las respuestas recibidas del lado del cliente son compiladas y ejecutadas en el navegador. Se estudiarán dos servidores web, uno de código abierto para plataformas Unix, Microsoft Windows, Macintosh conocido como Apache HTTP Server. Otro es un conjunto de servicios para la plataforma Microsoft, conocido como Internet Information Services (IIS), que es especialmente utilizado en servidores web. Existen otros servidores web en las mismas clasificaciones, pero todos contemplan un objetivo y es el manejo de servicios web por medio del protocolo HTTP. A nivel de popularidad según Web Technology Surveys establece que los servidores Apache HTTP Server e Internet Information Services son de los más utilizados [43]. SSO en entornos empresariales 35 Figura 9: Popularidad de los Servidores Web [43]. 2.4.1 Apache HTTP Server El servidor web Apache es uno de los más mencionados en la actualidad y se establece con mayor presencia en el mercado, es de código abierto y su nombre oficial es “Apache HTTP Server” el cual ha sido desarrollado por “Apache Software Foundation”. El servidor web acepta solicitudes del cliente (ej. navegadores) y envía las respuestas a la petición que se solicita (Ej. Página web). Maneja diferentes módulos que aseguran más funciones a su software como lo son MPM (el manejo de procesamientos múltiples) o MOD_SSL para poder habilitar la complejidad con SSL v3 y TLS [44]. Las características comunes que se incluye Apache son:  .htaccess  IPv6  FTP  HTTP/2  Perl, Lua, y PHP  Anulación del ancho de banda  WebDAV  Balanceo de carga  Re-escritura de URL  Rastreo de sesión  Geo ubicación basada en dirección IP Las configuraciones en apache se realizan por medio de directivas en archivos planos, se tiene como archivo principal de configuración el “httpd.conf” y contiene una directiva por cada línea. https://kinsta.com/es/aprender/que-es-http2/ SSO en entornos empresariales 36 La estructura de Apache se establece por módulos, se configuran a través de las directivas en cada uno de módulos. Los módulos que pertenecen a Apache se pueden clasificar en tres: Módulos Base, Módulos Multiproceso, Módulos Adicionales [44].  Módulos Base y Multiprocesos: La unión de estos módulos es posible porque los módulos Base son funciones básicas del servidor y el Multiproceso tiene como principal funcionamiento unir los puertos de la máquina, aceptando las peticiones y enviando atender las peticiones. Los módulos base y multiproceso (se describen en el Anexo 3).  Módulos Adicionales: Cualquier otro módulo que le añada una funcionalidad al servidor. Cuando se desea agregar una utilidad al servidor se añade un nuevo módulo de este modo limitamos la instalación de software. Además, las funcionalidades básicas y las configuraciones para los módulos se manejan en el fichero de httpd.conf. Los módulos adicionales (se describen en el Anexo 4). El funcionamiento interno de Apache HTTP Server se muestra en la siguiente imagen: Figura 10: Mecanismo de funcionalidad de Apache [76]. La arquitectura es simple conociendo el funcionamiento interno del servidor web (Apache). SSO en entornos empresariales 37 Figura 11: Arquitectura de servidor Web Apache HTTP Server. Elaboración propia Servicios: Apache HTTP Server administra las solicitudes / reglas y devuelve los documentos web. Las respuestas del lado del servidor Apache siempre son en formato HTML, de este modo se exponen las aplicaciones web y se configuran los módulos necesarios. Apache comprende las acciones desarrolladas en cada una de las aplicaciones en diferentes lenguajes y utiliza diferentes módulos para generar una respuesta HTML y ser mostrada al cliente (navegador). Cuando se realiza la solicitud del cliente se inicia con el nombre del dominio y su index por defecto, para generar toda la comunicación vía cliente servidor, Apache recibe la solicitud, verifica las configuraciones y la procesa. El flujo para acceder a un recurso es:  Si el recurso existe y es accesible, ya sea en el htdocs o directorio, asigna los permisos y se ejecuta el módulo del lenguaje especifico.  Envía una respuesta HTML plano, lo regresa al cliente (navegador) y finaliza con el código HTTP 200.  Si la solicitud es correcta pero el recurso no existe o hay un error interno de configuración de Apache, se genera un error del tipo HTTP 404 como respuesta HTML.  También puede ser que en el servidor este mal configurado y obtenemos errores del tipo HTTP 500. Seguridad: La seguridad de los servidores web debe ser siempre un punto importante en su implementación, los controles incluyen la instalación de los últimos parches de seguridad, restringir los accesos por direcciones IP, así como ocultar la versión e información relaciona a las configuraciones del servidor [45]. Además, Apache trabaja en una cuenta propia y grupos de usuarios que al utilizar el mod_security permite:  Filtración simplificada. http://migueleonardortiz.com.ar/curso-arquitectura-web/que-pasa-entre-un-navegador-y-un-servidor-web/530 SSO en entornos empresariales 38  Filtraciones basadas en las expresiones regulares (por las cadenas de textos).  Validaciones en la codificación de las URL.  Validar la codificación apegada al estándar de codificación de caracteres (Unicode).  Auditables.  Prevención sobre los ataques con cadenas de caracteres vacíos (NULL Byte).  Limitar la memoria en subida.  Enmascarar la identidad del servidor. El detalle de las configuraciones de seguridad mínima en Apache se describe en el Anexo 5. 2.4.2 Internet Information Services Internet Information Services (IIS) para Windows® Server es un servidor web flexible, seguro y manejable para hospedar cualquier “servicio” en la web. Desde la transmisión de medios a las aplicaciones web, la arquitectura abierta y escalable de IIS maneja las tareas más exigentes. La versión más reciente es IIS 10.0, para Windows 10 y Windows Server 2016. Desde la versión 7 de se proporciona una arquitectura de procesamiento de solicitudes que incluye [46]:  El Servicio de Activación de Procesos de Windows (WAS por sus siglas en inglés de Windows Process Activation Service), que permite que los sitios utilicen protocolos distintos de HTTP y HTTPS.  Un motor de servidor web que se puede personalizar agregando o eliminando módulos. Los módulos son características individuales que el servidor utiliza para procesar solicitudes. Existen módulos nativos que pueden ser agregados dependiendo de la necesidad: HTTP, seguridad, contenido, compresión (en las tuberías), caché, registro y diagnóstico, módulo de soporte gestionado. Además de los módulos nativos, IIS permite utilizar módulos de código administrado para ampliar la funcionalidad de IIS.  Tuberías integradas (Integrated Pipeline) de procesamiento de solicitudes de IIS y ASP.NET. IIS contiene varios componentes que realizan funciones importantes para las aplicaciones y servidor web. Cada componente tiene responsabilidades, como escuchar las solicitudes realizadas al servidor, administrar procesos y leer archivos de configuración. Estos componentes incluyen: Escuchas de protocolo, como HTTP.sys (Hypertext Transfer Protocol Stack): Escuchas de protocolo (protocol listeners) reciben solicitudes específicas de protocolo, las envían a IIS para su procesamiento y luego envían las respuestas a los solicitantes. Por ejemplo, cuando un navegador cliente solicita una página web de Internet, el oyente HTTP, SSO en entornos empresariales 39 HTTP.sys, recoge la solicitud y la envía a IIS para su procesamiento. Una vez que IIS procesa la solicitud, HTTP.sys devuelve una respuesta al navegador del cliente. De forma predeterminada, IIS proporciona HTTP.sys como el protocolo que escucha las solicitudes HTTP y HTTPS. HTTP.sys se introduce en IIS 6.0 como un escucha de protocolo específico de HTTP para solicitudes HTTP. HTTP.sys sigue siendo la escucha HTTP en IIS 7 y versiones posteriores, pero incluye soporte para SSL (por sus siglas en inglés de Secure Sockets Layer). HTTP.sys proporciona los siguientes beneficios:  Caché en modo kernel. Las solicitudes de respuestas almacenadas en caché se sirven sin cambiar al modo de usuario.  Cola de solicitud en modo kernel. Las solicitudes causan menos sobrecarga en el cambio de contexto porque el kernel envía las solicitudes directamente al proceso de trabajo correcto. Si no hay un proceso de trabajo disponible para aceptar una solicitud, la cola de solicitudes en modo kernel retiene la solicitud hasta que un proceso de trabajo la retire.  Solicitud de pre-procesamiento y filtrado de seguridad. Servicio de publicación World Wide Web (servicio WWW) El Servicio WWW lee la información de configuración de la metabase de IIS y usa esa información para configurar y actualizar el HTTP listener, HTTP.sys. Además, el servicio WWW inicia, detiene, recicla, monitorea y administra los procesos de trabajo que procesan las solicitudes HTTP. Supervisa el rendimiento y proporciona contadores de rendimiento para los sitios web y para el caché de IIS. Servicio de activación de procesos de Windows (WAS) Administra la configuración del grupo de aplicaciones y los procesos de trabajo en lugar del Servicio WWW. Esto le permite utilizar la misma configuración y modelo de proceso para los sitios HTTP y no HTTP. Los grupos de aplicaciones (application pool) separan las aplicaciones por límites de proceso para evitar que una aplicación afecte a otra aplicación en el servidor. WAS lee cierta información de archivos de configuración y pasa esa información a los adaptadores de escucha en el servidor. Los adaptadores de escucha son componentes que establecen la comunicación entre WAS y escuchas de protocolo, como HTTP.sys. Una vez que los adaptadores de escucha reciben información de configuración, configuran sus escuchas de protocolo relacionadas y preparan a las escuchas para escuchar las solicitudes. SSO en entornos empresariales 40 IIS 7 y versiones posteriores utilizan un sistema de configuración basado en XML para almacenar las configuraciones de IIS [47]. El sistema de configuración se introdujo con ASP.NET y se basa en un sistema jerárquico de sistema de administración que utiliza archivos *.config. Los archivos de configuración principales son:  ApplicationHost.config  Administration.config  Redirection.config Procesamiento de solicitud HTTP en IIS [46] 1. Cuando un navegador de cliente inicia una solicitud HTTP para un recurso en el servidor web, HTTP.sys intercepta la solicitud. 2. HTTP.sys se pone en contacto con WAS para obtener información del almacén de configuración. 3. WAS solicita información de configuración del almacén de configuración, applicationHost.config. 4. El servicio WWW recibe información de configuración, tales como el grupo de aplicaciones y la configuración del sitio. 5. El servicio WWW utiliza la información de configuración para configurar HTTP.sys. 6. WAS inicia un proceso de trabajo para el grupo de aplicaciones al que se realizó la solicitud. 7. El proceso de trabajo procesa la solicitud y devuelve una respuesta a HTTP.sys. 8. El cliente recibe una respuesta. Figura 12: Procesamiento de solicitudes [46]. SSO en entornos empresariales 41 El “proceso de trabajo” al que se hace referencia es una instancia del ejecutable W3WP.exe que se relaciona con un grupo de aplicaciones (application pool). En un proceso de trabajo, una solicitud HTTP pasa a través de varios pasos ordenados, llamados eventos. En cada evento, un módulo nativo procesa parte de la solicitud, como autenticar al usuario o agregar información al registro de eventos. Cuando la solicitud pasa a través de todos los eventos, la respuesta se devuelve a HTTP.sys. Algunos elementos de seguridad que se integra en el servidor IIS:  Aislamiento automático de sitios web [58]: IIS 7.0 ofrece un mayor aislamiento de la aplicación al proporcionar a los procesos de los trabajadores una identidad completamente única y una configuración de espacio aislado de forma predeterminada, lo que reduce aún más los riesgos de seguridad. IIS 7.0 incluye el aislamiento automático del grupo de aplicaciones y puede proteger miles de sitios web en un solo servidor. Esto permite que cada sitio web se ejecute en su propio espacio de memoria con una identidad única generada automáticamente, lo que ayuda a garantizar que las aplicaciones no se vean afectadas por otros fallos o violaciones de seguridad de las aplicaciones que se ejecutan en el mismo servidor. Esta capacidad permite a las organizaciones consolidar más sitios web en menos servidores, y aumenta la seguridad y confiabilidad para todos los sitios web que se ejecutan en un host compartido.  Autorización de URL [49]: IIS 7.0 almacena las reglas de autorización de URL en el archivo web.config de una aplicación, de modo que las reglas de autorización que protegen contra el acceso no autorizado siguen el contenido, incluso cuando el contenido se mueve a un servidor diferente o incluso a un nuevo dominio. IIS 7.0 también admite la autorización de URL de ASP.NET para todos los tipos de solicitudes de contenido web en la canalización integrada.  Solicitud de filtrado incorporada [49]: El filtrado de solicitudes de IIS 7.0 permite a los administradores implementar políticas de aceptación de URL tanto global como por URL. El filtrado de solicitudes ayuda a proteger el servidor al garantizar que solo se procesen las solicitudes válidas. Los administradores pueden aumentar la seguridad del servidor web al proporcionar múltiples opciones de filtrado que pueden evitar que se procesen las URL maliciosas o incorrectas. 2.5 Comunicación entres servidores 2.5.1 Protocolos de comunicación La presente investigación estudia los estándares dominantes de web abierta para identidad en línea [50]. Los más destacados para la integración de soluciones SSO, son: SAML, OAuth 2.0 y OpenID Connect. SSO en entornos empresariales 42 Previo a la descripción formal de estos protocolos, se detallan puntos clave que se deben considerar para la correcta interpretación de estos [50]:  OAuth 2.0 es un marco de autorización, no un protocolo de autenticación. OAuth 2.0 se puede usar para muchas tareas interesantes, una de las cuales es la autenticación de personas.  OAuth 2.0 es un estándar ligeramente reciente que fue desarrollado por Google y Twitter para habilitar los inicios de sesión de Internet optimizados. OAuth 2.0 utiliza una metodología similar a SAML para compartir información de inicio de sesión. SAML proporciona más control a las empresas para mantener sus inicios de sesión SSO más seguros, mientras que OAuth 2.0 es mejor en dispositivos móviles y usa JSON.  OpenID Connect es un "perfil" de OAuth 2.0 diseñado específicamente para la liberación y autenticación de atributos.  Facebook y Google son dos proveedores de OAuth 2.0 que se puede utilizar para iniciar sesión en otros sitios de internet, como por ejemplo acceder a Spotify. SAML Security Assertion Markup Language (SAML por sus siglas en inglés) es un estándar abierto [51] que permite la comunicación segura de identidades entre organizaciones mediante las funciones de autenticación y autorización. Las transacciones SAML utilizan XML para estandarizar las comunicaciones entre el proveedor de identidad (IdP) y los proveedores de servicios (SP). SAML es el enlace entre la autenticación de la identidad de un usuario y la autorización para usar un servicio. OASIS aprobó SAML 2.0 en 2005, y el estándar cambió significativamente de la versión 1.1, tanto que las versiones son incompatibles. SAML habilita el SSO, un término que significa que los usuarios inician sesión una vez, y esas mismas credenciales son reutilizadas para el inicio de sesión en otros proveedores de servicios. El trabajo de SAML es transferir la identidad del usuario de un lugar (el proveedor de identidad) a otro (el proveedor de servicios). Esto lo hace a través de un intercambio de documentos XML que so firmados digitalmente para comprobar que el mensaje proviene de una fuente de confianza. Se describe la secuencia de eventos para el inicio de autenticación único que detalla cómo trabaja el protocolo SAML [52] [75]: 1. El usuario solicita acceso a un recurso protegido. 2. El SP verifica si ya está autenticado dentro del sistema. Si es así, salta al paso 7; si no lo está, el SP inicia el proceso de autenticación. 3. La aplicación identifica el origen del usuario (por subdominio de la aplicación, dirección IP del usuario o similar) y redirige al usuario al IdP apropiado, solicitando la autenticación. Esta es la solicitud de autenticación (SAML 2.0 AuthnRequest). SSO en entornos empresariales 43 4. Después de la posible identificación del usuario, el flujo de SSO reanuda. 5. El IdP construye la respuesta de autenticación en forma de un documento XML (una afirmación, que se conoce como SAML Assertion, por el término en inglés) que contiene el nombre de usuario o la dirección de correo electrónico del usuario, lo firma con un certificado X.509 y publica esta información en el proveedor de servicios. 6. El proveedor de servicios, que ya conoce al IdP y tiene una huella digital de certificado, recupera la respuesta de autenticación y la valida utilizando la huella digital del certificado. 7. Se establece la identidad del usuario y se le proporciona acceso a la aplicación. Figura 13: Flujo SSO empezado por SP [53]. Hay tres tipos diferentes de afirmaciones SAML (Assertion) [51] 1. Autenticación: Demuestran la identificación del usuario y proporcionan el tiempo en que el usuario inició sesión y qué método de autenticación utilizaron. 2. Atributo: La aserción de atribución pasa los atributos SAML al proveedor de servicios; los atributos SAML son datos específicos que proporcionan información sobre el usuario. 3. Decisión de autorización: dice si el usuario está autorizado para usar el servicio o si el proveedor de identidad denegó su solicitud debido a una falla de contraseña o falta de derechos sobre el servicio. Beneficios de la autenticación SAML [54] Estandarización: SAML es un formato estándar que permite una interoperabilidad perfecta entre sistemas, independientemente de la implementación. Elimina los problemas comunes asociados con la implementación y la arquitectura del proveedor y la plataforma específica. Mayor seguridad: La seguridad es un aspecto clave del desarrollo de software, y para entornos empresariales, es extremadamente importante. SAML proporciona un único punto de autenticación, que ocurre en un IdP seguro. Luego, SAML transfiere la identidad a los SSO en entornos empresariales 44 proveedores de servicios. Esta forma de autenticación garantiza que las credenciales no abandonen el límite del cortafuego. Documentación: El protocolo SAML está ampliamente documentado en los productos SSO comerciales para facilitar la integración. Algunas soluciones como OneLogin proveen incluso cajas de herramientas (toolkit como término en inglés) para cinco plataformas de desarrollo web [53]. A continuación, se detalla un ejemplo de SAML AuthNRequest. Se detalla la aplicación que sirve como IdP y el certificado de seguridad para ser validado, entre otro. Figura 14: Representación de SAML. Elaboración propia OAuth 2.0 Es un protocolo estándar de la industria para la autorización [55]. OAuth 2.0 reemplaza el trabajo realizado en el protocolo original de OAuth creado en 2006 que fue desarrollado, en parte, para compensar las deficiencias de SAML en las plataformas móviles, y está basado en JSON en lugar de XML. OAuth 2.0 se enfoca en la simplicidad de desarrollo del cliente y permite a las aplicaciones obtener acceso limitado a cuentas de usuario en un servicio HTTP, como Facebook, Twitter, GitHub, otros. La autenticación del usuario se delega al servicio que aloja la cuenta del mismo y autoriza a las aplicaciones de terceros el acceso a dicha cuenta de usuario. Proporciona flujos de autorización para aplicaciones web, escritorio y móviles. SSO en entornos empresariales 45 OAuth define cuatro roles [56] [57] Rol propietario del recurso: La entidad que puede otorgar acceso a un recurso protegido. Normalmente este es el usuario final. El acceso de la aplicación a la cuenta del usuario se limita al "alcance" de la autorización otorgada (acceso de lectura o escritura). Rol cliente: El cliente es la aplicación que desea acceder a la cuenta del usuario. Antes de que pueda hacerlo, debe ser autorizado por el usuario, y dicha autorización debe ser validada por la API. Rol servidor de recursos / API: El servidor que aloja los recursos protegidos. Esta es la API a la que desea acceder. Rol servidor de autorización / API: El servidor que autentica al propietario del recurso y que emite los tokens de acceso después de obtener la autorización correspondiente. La API de igual forma permite refrescar y revocar un conjunto de tokens. Este servidor funciona como un proveedor de identidades IdP. A continuación, se ilustran como los roles interactúan entre sí [56], en lo que llamamos a este punto un flujo abstracto o genérico. Es cómo generalmente interactúan entre sí. Figura 15: Flujo abstracto [56]. Una "concesión" (o “grant” por el término en inglés) de OAuth 2.0 es la autorización dada (u "otorgada") al cliente por el usuario [58]. Ejemplos de concesiones (“grants”) son "código de SSO en entornos empresariales 46 autorización" y "credenciales de cliente". Cada concesión de OAuth tiene un flujo correspondiente. La especificación del marco de autorización OAuth 2.0 define cuatro flujos para obtener un token de acceso. Estos flujos se denominan tipos de concesión. El flujo a utilizar depende principalmente del tipo de aplicación que se está desarrollando [59].  Código de autorización: Utilizado por las aplicaciones web que se ejecutan en un servidor. Esto también es utilizado por las aplicaciones móviles, utilizando la técnica de clave de prueba (Proof Key por su término en inglés) para el intercambio de código (PKCE por sus siglas en inglés de Proof Key for Code Exchange).  Implícito: Utilizado por aplicaciones centradas en JavaScript (aplicaciones de una sola página) que se ejecutan en el navegador del usuario.  Credenciales de contraseña del propietario del recurso: Utilizadas por aplicaciones de confianza.  Credenciales del cliente: Se utiliza para la comunicación máquina a máquina. Puntos finales (endpoints por el término en inglés) utilizados en el protocolo [59]: Punto final de autorización (Authorization endpoint, por el término en inglés): Se utiliza para interactuar con el propietario del recurso y obtener la autorización para acceder al recurso protegido. Utiliza los siguientes parámetros de solicitud:  response_type: Le dice al servidor que tipo de concesión utilizar, y la respuesta es basada en este parámetro. Los valores pueden ser “code” o “token”.  client_id: El ID de la aplicación que solicita autorización.  redirect_uri: URL a la que se redirige en una respuesta exitosa.  scope: Una lista de permisos, delimitada por espacios, que la aplicación requiere.  state: Utilizado con fines de seguridad. Este punto final (endpoint) es utilizado por la concesión “código de autorización”, que emite un AuthorizationCode. De igual forma es utilizado por la concesión “Implícita”, que emite un token de acceso (AccessToken, por el término en inglés). La diferencia en los tipos de respuesta es que un AuthorizationCode es una cadena opaca (opaque strings: cuando no se usa una API personalizada), que debe intercambiarse con un token de acceso en el punto final del token. Por su parte, un AccessToken es una cadena opaca (o un JWT en la implementación Auth0, es decir utiliza una API personalizada) que denota quién ha autorizado qué permisos (ámbitos) a qué aplicación. Punto final de token (Token endpoint, por el término en inglés): Obti