6 entradas etiquetados con "OIDC"

Cada herramienta en un stack DevOps autoalojado típico puede actuar como cliente OpenID Connect: Gitea y Argo CD hablan OIDC nativamente, Jenkins lo hace mediante el plugin oic-auth, Grafana y Portainer mediante OAuth 2.0 genérico, y MinIO, Harbor y GitLab mediante sus configuraciones OIDC. Apunte todas ellas a una instancia de Casdoor, dé a cada herramienta su propia aplicación de Casdoor y coloque a su personal en grupos de Casdoor. Cada herramienta leerá entonces la afirmación groups y decidirá quién es administrador. Esta publicación enumera la URL de callback, las claves de configuración y el mapeo de grupos para cada herramienta, y luego cubre las partes que comparten.

nginx de código abierto no tiene un módulo CAS, por lo que "nginx CAS authentication" en la práctica significa uno de dos tipos de configuración. O bien nginx pregunta a un servicio de autenticación sobre cada solicitud a través de su módulo auth_request, y Casdoor responde (directamente en /api/forward-auth, o mediante casdoor-forward-auth u OAuth2 Proxy), o la aplicación detrás de nginx es en sí misma un cliente CAS y se comunica con los endpoints del servidor CAS de Casdoor. Si puedes recompilar nginx, el módulo Casdoor nginx ejecuta el inicio de sesión dentro de nginx, y si prefieres no ejecutar nginx en absoluto, el proxy de sitio de Casdoor puede situarse delante de la aplicación. En todos los casos, la página de inicio de sesión es la de Casdoor, por lo que una sola sesión SSO, un conjunto de permisos y una política de MFA cubren todas las aplicaciones.

Cerrar la sesión de un usuario en una aplicación OpenID Connect requiere más que eliminar tu propia cookie de sesión. El usuario sigue conectado en el proveedor de identidad, por lo que el siguiente clic en "Sign in" pasa directamente sin contraseña, y las otras aplicaciones que comparten esa sesión del proveedor de identidad también permanecen conectadas. Un cierre de sesión adecuado tiene tres partes: limpiar la sesión local de tu aplicación, enviar el navegador al end_session_endpoint del proveedor (cierre de sesión iniciado por RP) para que finalice la sesión del proveedor, y permitir que el proveedor informe a las otras aplicaciones mediante el cierre de sesión por canal posterior. Con Casdoor, el endpoint de fin de sesión es /api/logout, el cierre de sesión por canal posterior se configura por aplicación y los tokens de actualización pueden revocarse en /api/login/oauth/revoke.

Para agregar inicio de sesión único a Spring Boot, registre cada aplicación como una aplicación en un proveedor de OpenID Connect como Casdoor, apunte Spring Security a la URL del emisor del proveedor y elija el módulo de Spring que coincida con la aplicación: oauth2Login() para una aplicación web renderizada en el servidor, oauth2ResourceServer().jwt() para una API REST que recibe tokens bearer, y Spring Cloud Gateway con el filtro TokenRelay cuando una puerta de enlace inicia sesión a los usuarios para un conjunto de microservicios. Los usuarios obtienen SSO porque todas las aplicaciones los envían al mismo Casdoor, que recuerda la sesión: la segunda aplicación redirige, Casdoor ya conoce al usuario y este vuelve directamente sin un formulario de inicio de sesión. Esta publicación configura las tres formas contra un solo Casdoor, cada una con un application.yml funcional y un SecurityFilterChain personalizado.

Varios proyectos de datos y middleware de Apache incluyen su propio inicio de sesión de Casdoor: Apache DolphinScheduler tiene un tipo de autenticación llamado CASDOOR_SSO (desde 3.2.0) y un modo OIDC genérico (desde 3.4.0), Apache ShenYu tiene un plugin de Casdoor (desde 2.5.1), Apache Pulsar Manager tiene un botón "Log in with Casdoor" (desde 0.3.0), y Apache APISIX tiene el plugin authz-casdoor (desde 2.14.0). Apache IoTDB es la excepción: la base de datos en sí autentica con sus propios usuarios y contraseñas, y solo la ahora archivada IoTDB Web Workbench se comunica con Casdoor. La tabla siguiente lista cada proyecto, la versión y dónde residen los ajustes; la segunda mitad del artículo configura paso a paso la autenticación de usuarios en IoTDB.

No existe "OAuth de Steam": Steam inicia sesión a los usuarios con OpenID 2.0 y le proporciona un SteamID de 64 bits, nada más. El clásico Login Widget de Telegram tampoco es OAuth: entrega a su página un conjunto de campos de usuario más un hash HMAC-SHA256 que usted verifica con su token de bot. Telegram ahora también ejecuta un proveedor real de OpenID Connect en oauth.telegram.org. Si coloca Casdoor entre su aplicación y estos proveedores, Casdoor realiza las verificaciones específicas del protocolo y su aplicación solo habla OpenID Connect con Casdoor, de la misma manera que lo haría con Google o GitHub.