Shibboleth es un sistema de inicio de sesión único para redes informáticas e Internet . Permite a las personas iniciar sesión con una sola identidad en varios sistemas administrados por federaciones de diferentes organizaciones o instituciones. Las federaciones son a menudo universidades u organizaciones de servicios públicos.
La iniciativa de middleware Shibboleth Internet2 creó una arquitectura y una implementación de código abierto para la gestión de identidades y la infraestructura de autenticación y autorización (o control de acceso ) basada en identidad federada basada en Security Assertion Markup Language (SAML). La identidad federada permite compartir información sobre los usuarios de un dominio de seguridad con las demás organizaciones de una federación. Esto permite el inicio de sesión único entre dominios y elimina la necesidad de que los proveedores de contenido mantengan los nombres de usuario y las contraseñas. Proveedores de identidad (IdP) proporcionan información del usuario, mientras que los proveedores de servicios (SP) consumen esta información y brindan acceso a contenido seguro.
Historia
El proyecto Shibboleth surgió de Internet2. Hoy, el proyecto está gestionado por el Consorcio Shibboleth. Dos de los componentes de software más populares administrados por Shibboleth Consortium son Shibboleth Identity Provider y Shibboleth Service Provider, los cuales son implementaciones de SAML .
El proyecto recibió el nombre de una frase de contraseña de identificación utilizada en la Biblia ( Jueces 12: 4-6 ) porque los efraimitas no podían pronunciar "sh".
El proyecto Shibboleth se inició en 2000 para facilitar el intercambio de recursos entre organizaciones con infraestructuras de autenticación y autorización incompatibles. El trabajo de arquitectura se realizó durante más de un año antes de cualquier desarrollo de software. Después del desarrollo y las pruebas, Shibboleth IdP 1.0 fue lanzado en julio de 2003. [1] Esto fue seguido por el lanzamiento de Shibboleth IdP 1.3 en agosto de 2005.
La versión 2.0 del software Shibboleth fue una actualización importante lanzada en marzo de 2008. [2] Incluía componentes IdP y SP, pero, lo que es más importante, Shibboleth 2.0 era compatible con SAML 2.0.
Los protocolos Shibboleth y SAML se desarrollaron durante el mismo período de tiempo. Desde el principio, Shibboleth se basó en SAML, pero, donde se encontró que faltaba SAML, Shibboleth improvisó y los desarrolladores de Shibboleth implementaron funciones que compensaban las funciones faltantes en SAML 1.1 . Algunas de estas características se incorporaron posteriormente a SAML 2.0 y, en ese sentido, Shibboleth contribuyó a la evolución del protocolo SAML.
Quizás la característica aportada más importante fue el protocolo heredado Shibboleth AuthnRequest. Dado que el protocolo SAML 1.1 era inherentemente un protocolo IdP-first, Shibboleth inventó un protocolo simple de solicitud de autenticación basado en HTTP que convirtió SAML 1.1 en un protocolo SP-first. Este protocolo se implementó por primera vez en Shibboleth IdP 1.0 y luego se perfeccionó en Shibboleth IdP 1.3.
Sobre la base de ese trabajo inicial, Liberty Alliance introdujo un protocolo AuthnRequest completamente ampliado en Liberty Identity Federation Framework. Finalmente, Liberty ID-FF 1.2 se contribuyó a OASIS, que formó la base para el estándar OASIS SAML 2.0. [ importancia? ]
Arquitectura
Shibboleth es una tecnología basada en web que implementa el artefacto HTTP / POST y los perfiles de inserción de atributos de SAML , incluidos los componentes del proveedor de identidad (IdP) y del proveedor de servicios (SP). Shibboleth 1.3 tiene su propia descripción técnica, [3] documento de arquitectura, [4] y documento de conformidad [5] que se basan en las especificaciones de SAML 1.1.
Shibbolet 1.3
En el caso de uso canónico:
- Un usuario accede primero a un recurso alojado en un servidor web (el proveedor de servicios) que tiene habilitada la protección de contenido de Shibboleth.
- El SP elabora una solicitud de autenticación patentada que se pasa a través del navegador utilizando parámetros de consulta de URL para proporcionar el ID de entidad SAML del solicitante, la ubicación de consumo de la aserción y, opcionalmente, la página final a la que devolver el usuario.
- El usuario es redirigido a su IdP local o al servicio WAYF (Where Are You From), donde selecciona su IdP local para una mayor redirección.
- El usuario se autentica en un mecanismo de control de acceso externo a Shibboleth.
- Shibboleth genera una aserción de autenticación SAML 1.1 con un "identificador" temporal contenido en ella. Este identificador permite que el IdP reconozca una solicitud sobre un usuario de navegador en particular como correspondiente al principal que se autenticó anteriormente.
- El usuario es enviado al servicio de consumidor de aserción del SP. El SP consume la aserción y emite una AttributeQuery al servicio de atributos del IdP para los atributos sobre ese usuario, que pueden incluir o no la identidad del usuario.
- El IdP envía una aserción de atributo que contiene información confiable sobre el usuario al SP.
- El SP toma una decisión de control de acceso en función de los atributos o proporciona información a las aplicaciones para que tomen decisiones por sí mismos.
Shibboleth admite una serie de variaciones en este caso base, incluidos los flujos de estilo portal en los que el IdP acuña una afirmación no solicitada para entregar en el acceso inicial al SP, y el inicio de sesión diferido, que permite que una aplicación active la protección de contenido a través de un método de su elección según sea necesario.
Shibboleth 1.3 y versiones anteriores no proporcionan un mecanismo de autenticación integrado , pero se puede utilizar cualquier mecanismo de autenticación basado en la Web para proporcionar datos de usuario para que los utilice Shibboleth. Los sistemas comunes para este propósito incluyen CAS o Pubcookie . También se pueden utilizar las funciones de autenticación e inicio de sesión único del contenedor Java en el que se ejecuta IdP (Tomcat, por ejemplo).
Shibboleth 2.0
Shibboleth 2.0 se basa en los estándares SAML 2.0 . El IdP en Shibboleth 2.0 tiene que realizar un procesamiento adicional para admitir solicitudes de autenticación pasiva y forzada en SAML 2.0. El SP puede solicitar un método específico de autenticación del IdP. Shibboleth 2.0 admite capacidad de cifrado adicional.
Atributos
El control de acceso de Shibboleth se realiza comparando los atributos proporcionados por los IdP con las reglas definidas por los SP. Un atributo es cualquier información sobre un usuario, como "miembro de esta comunidad", "Alice Smith" o "con licencia bajo contrato A". La identidad del usuario se considera un atributo y solo se transmite cuando se requiere explícitamente, lo que preserva la privacidad del usuario. Los atributos se pueden escribir en Java o extraer de directorios y bases de datos. Los atributos estándar X.520 se utilizan con mayor frecuencia, pero los nuevos atributos se pueden definir arbitrariamente siempre que el IdP y el SP los comprendan e interpreten de manera similar en una transacción.
Confianza
La confianza entre dominios se implementa mediante criptografía de clave pública (a menudo simplemente certificados de servidor TLS ) y metadatos que describen a los proveedores. El uso de la información transmitida se controla mediante acuerdos. Las federaciones se utilizan a menudo para simplificar estas relaciones agregando un gran número de proveedores que aceptan utilizar reglas y contratos comunes.
Desarrollo
Shibboleth es de código abierto y se proporciona bajo la licencia Apache 2. Otros grupos han contribuido con muchas extensiones.
Adopción
Se han formado federaciones en muchos países de todo el mundo para crear estructuras de confianza para el intercambio de información utilizando el software SAML y Shibboleth. Muchos de los principales proveedores de contenido admiten el acceso basado en Shibboleth.
En febrero de 2006, el Comité Conjunto de Sistemas de Información (JISC) de los Consejos de Financiamiento de la Educación Superior de Inglaterra, Escocia, Gales e Irlanda del Norte anunció que pasaría del sistema de autenticación de Atenas a un sistema de gestión de acceso basado en la tecnología Shibboleth. [6] Desde entonces, ha actualizado su posición y respalda una solución de gestión de acceso federada en lugar de Shibboleth. [ cita requerida ]
Ver también
Referencias
- ↑ Pollack, Michelle (1 de julio de 2003). "I2-News: Internet2 lanza software de autorización web que preserva la privacidad" (lista de correo) . Consultado el 28 de noviembre de 2007 .
- ^ "Shibboleth 2.0 disponible" .
- ^ Scavo, Tom; Cantor, Scott (8 de junio de 2005). "Arquitectura Shibboleth: descripción técnica (documento ID: draft-mace-shibboleth-tech-overview-02)" (PDF) . Archivado desde el original el 14 de marzo de 2012 . Consultado el 2 de octubre de 2017 .CS1 maint: bot: estado de URL original desconocido ( enlace )
- ^ "Arquitectura Shibboleth: protocolos y perfiles" (PDF) . 2005-09-10 . Consultado el 24 de agosto de 2017 .
- ^ Cantor, Scott; Morgan, RL "Bob"; Scavo, Tom (10 de septiembre de 2005). "Arquitectura Shibboleth: requisitos de conformidad" (PDF) . Consultado el 24 de agosto de 2017 .
- ^ "JISC anuncia el desarrollo de un nuevo sistema de gestión de acceso para el Reino Unido" . Comité Conjunto de Sistemas de Información . Consultado el 19 de julio de 2006 .
enlaces externos
- Página web oficial
- Wiki oficial de Shibboleth 1.x
- Wiki oficial de Shibboleth 2.x
- Wiki oficial de Shibboleth IdP 3.x
- Wiki oficial de Shibboleth IdP 4.x