Hispanopedia Wiki
Articulo de referencia

Shibboleth (software)

Shibboleth es un sistema de inicio de sesión único para redes informáticas e Internet . Permite a los usuarios acceder con una sola identidad a diversos sistemas gestionados por...

Hispanopedia WikiContenido en espanolLectura gratuita

Shibboleth es un sistema de inicio de sesión único para redes informáticas e Internet . Permite a los usuarios acceder con una sola identidad a diversos sistemas gestionados por federaciones de diferentes organizaciones o instituciones. Estas federaciones suelen ser universidades u organizaciones de servicio público.

La iniciativa de middleware Shibboleth Internet2 creó una arquitectura e 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, utilizando el lenguaje de marcado de aserciones de seguridad (SAML). La identidad federada permite compartir información sobre los usuarios de un dominio de seguridad con las demás organizaciones de la federación. Esto posibilita el inicio de sesión único entre dominios y elimina la necesidad de que los proveedores de contenido gestionen nombres de usuario y contraseñas. Los proveedores de identidad (IdP) suministran la información del usuario, mientras que los proveedores de servicios (SP) la consumen y otorgan acceso al contenido seguro.

Historia

El proyecto Shibboleth surgió de Internet2. Desde junio de 2025, el proyecto es administrado por el Consorcio Shibboleth . [ 1 ] Dos de los componentes de software más populares administrados por el Consorcio Shibboleth son el Proveedor de Identidad Shibboleth y el Proveedor de Servicios Shibboleth , ambos implementaciones de SAML .

El proyecto recibió su nombre de una frase 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 el año 2000 para facilitar el intercambio de recursos entre organizaciones con infraestructuras de autenticación y autorización incompatibles . El trabajo de arquitectura se llevó a cabo durante más de un año antes del desarrollo del software. Tras el desarrollo y las pruebas, Shibboleth IdP 1.0 se lanzó en julio de 2003. [ 2 ] Posteriormente, en agosto de 2005, se lanzó Shibboleth IdP 1.3.

La versión 2.0 del software Shibboleth fue una actualización importante lanzada en marzo de 2008. [ 3 ] Incluía componentes IdP y SP, pero, más importante aún, Shibboleth 2.0 era compatible con SAML 2.0.

Los protocolos Shibboleth y SAML se desarrollaron simultáneamente. Desde sus inicios, Shibboleth se basó en SAML, pero allí donde SAML presentaba deficiencias, Shibboleth improvisó, e implementó funcionalidades que compensaban las carencias de SAML 1.1 . Algunas de estas funcionalidades se incorporaron posteriormente a SAML 2.0 , y, en ese sentido, Shibboleth contribuyó a la evolución del protocolo SAML.

Quizás la contribución más importante fue el protocolo heredado Shibboleth AuthnRequest. Dado que el protocolo SAML 1.1 era intrínsecamente un protocolo que priorizaba al IdP, Shibboleth inventó un sencillo protocolo de solicitud de autenticación basado en HTTP que convirtió a SAML 1.1 en un protocolo que priorizaba al SP. Este protocolo se implementó por primera vez en Shibboleth IdP 1.0 y posteriormente se perfeccionó en Shibboleth IdP 1.3.

Partiendo de ese trabajo inicial, Liberty Alliance introdujo un protocolo AuthnRequest totalmente ampliado en el Liberty Identity Federation Framework. Posteriormente, Liberty ID-FF 1.2 se integró en OASIS, lo que sirvió de base para el estándar OASIS SAML 2.0.

Arquitectura

Shibboleth es una tecnología web que implementa los perfiles de envío de artefactos y atributos HTTP/POST de SAML , incluyendo componentes de proveedor de identidad (IdP) y proveedor de servicios (SP). Shibboleth 1.3 cuenta con su propia descripción técnica, [ 4 ] documento arquitectónico [ 5 ] y documento de conformidad [ 6 ] que se basan en las especificaciones de SAML 1.1.

Shibboleth 1.3

En el caso de uso canónico:

  1. Un usuario accede primero a un recurso alojado por un servidor web (el proveedor de servicios) que tiene habilitada la protección de contenido Shibboleth.
  2. El proveedor de servicios (SP) elabora una solicitud de autenticación propietaria que se transmite 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 se debe redirigir al usuario.
  3. El usuario es redirigido a su proveedor de identidad (IdP) de origen o a un servicio WAYF (Where Are You From), donde selecciona su IdP de origen para una redirección posterior.
  4. El usuario se autentica en un mecanismo de control de acceso externo a Shibboleth.
  5. Shibboleth genera una aserción de autenticación SAML 1.1 que contiene un identificador temporal. Este identificador permite al proveedor de identidad (IdP) reconocer una solicitud sobre un usuario de navegador específico como correspondiente al usuario que se autenticó previamente.
  6. El usuario se envía mediante POST al servicio de consumidor de aserciones del SP. El SP consume la aserción y emite una consulta de atributos al servicio de atributos del IdP para obtener atributos sobre ese usuario, que pueden incluir o no la identidad del usuario.
  7. El IdP envía al SP una aserción de atributo que contiene información confiable sobre el usuario.
  8. El proveedor de servicios (SP) toma una decisión de control de acceso basándose en los atributos o bien proporciona información a las aplicaciones para que tomen sus propias decisiones.

Shibboleth admite varias variaciones de este caso base, incluidos flujos de estilo portal en los que el IdP genera una aserción no solicitada que se entrega en el acceso inicial al SP, y el inicio diferido de la sesión, que permite a una aplicación activar la protección de contenido mediante el método que elija según sea necesario.

Shibboleth 1.3 y versiones anteriores no incluyen un mecanismo de autenticación integrado , pero se puede utilizar cualquier mecanismo de autenticación web para proporcionar los datos de usuario a Shibboleth. Algunos sistemas comunes para este fin son 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 el IdP (por ejemplo, Tomcat).

Shibboleth 2.0

Shibboleth 2.0 se basa en los estándares SAML 2.0 . El proveedor de identidad (IdP) en Shibboleth 2.0 debe realizar un procesamiento adicional para admitir las solicitudes de autenticación pasiva y forzada en SAML 2.0. El proveedor de servicios (SP) puede solicitar un método de autenticación específico al IdP. Shibboleth 2.0 admite capacidad de cifrado adicional.

Atributos

El control de acceso de Shibboleth se realiza comparando los atributos proporcionados por los proveedores de identidad (IdP) con las reglas definidas por los proveedores de servicios (SP). Un atributo es cualquier información sobre un usuario, como "miembro de esta comunidad", "Alice Smith" o "con licencia del 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 pueden escribirse en Java o extraerse de directorios y bases de datos. Los atributos estándar X.520 son los más utilizados, pero se pueden definir nuevos atributos arbitrariamente siempre que el IdP y el SP los comprendan e interpreten de forma 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 frecuentemente para simplificar estas relaciones, agrupando a un gran número de proveedores que acuerdan utilizar reglas y contratos comunes.

Desarrollo

Shibboleth es de código abierto y se distribuye bajo la licencia Apache 2. [ 7 ] Otros grupos han contribuido con muchas extensiones. [ 8 ] [ 9 ] [ 10 ]

Véase también

Referencias

  1. ↑ "Sobre nosotros" . Consorcio Shibboleth . Consultado el 18 de junio de 2025 .
  2. ↑ Pollack, Michelle (1 de julio de 2003). "I2-News: Internet2 lanza software de autorización web que preserva la privacidad" (Lista de correo) . Recuperado el 28 de noviembre de 2007 .{{cite mailing list}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  3. ↑ "Shibboleth 2.0 disponible" .
  4. ↑ Scavo, Tom; Cantor, Scott (2005-06-08). "Arquitectura Shibboleth: Descripción técnica (ID del documento: draft-mace-shibboleth-tech-overview-02)" (PDF) . Archivado del original el 14-03-2012 . Recuperado el 02-10-2017 .{{cite web}}: CS1 maint: bot: estado de la URL original desconocido ( enlace )
  5. ↑ "Arquitectura Shibboleth: Protocolos y perfiles" (PDF) . 10 de septiembre de 2005. Consultado el 24 de agosto de 2017 .
  6. ↑ Cantor, Scott; Morgan, RL "Bob"; Scavo, Tom (10 de septiembre de 2005). "Arquitectura Shibboleth: Requisitos de conformidad" (PDF) . Recuperado el 24 de agosto de 2017 .
  7. ↑ "Inicio - Shibboleth 2 - Confluence" . shibboleth.atlassian.net . Consultado el 18 de junio de 2025 .
  8. ↑ "Shibboleth" . InCommon . Consultado el 18 de junio de 2025 .
  9. ↑ "Inicio - Shibboleth 2 - Confluence" . shibboleth.atlassian.net . Consultado el 18 de junio de 2025 .
  10. ↑ "Contribuciones - Shibboleth 2 - Confluence" . shibboleth.atlassian.net . Consultado el 18 de junio de 2025 .
  • Sitio web oficial