¿Se puede crear un buen protocolo de SSO alrededor de un servidor que firme tickets en lugar de validarlos bajo demanda?

Question

¿Se puede crear un buen protocolo de SSO alrededor de un servidor que firme tickets en lugar de validarlos bajo demanda?

#1 de Thomas Pornin (4 votos)
#2 de AJ Henderson (3 votos)

3

CAS y sus alternativas parecen requerir un flujo como este cuando un servicio actúa como proxy para un usuario cuando accede a un servicio de back-end:

El servicio A realiza una solicitud al servicio B en nombre de un usuario. La solicitud incluye un token perecedero (ticket de proxy) del servidor de autenticación. El servicio B reenvía el token al servidor de autenticación, preguntando si es válido.

Parece que podría ser más eficiente que el servidor de autenticación firme el ticket, y que el Servicio B conozca la clave pública del servidor para que pueda validar el ticket por sí solo, sin necesidad por la solicitud extra. Obviamente, cualquier funcionalidad de cierre de sesión único debería dejarse en el Servicio A, pero, de lo contrario, todo esto parece ser algo positivo: es más robusto ante la latencia de la red o la caída del servidor de autenticación, y es aún más difícil de forzar. que un token aleatorio.

¿Hay desventajas o riesgos que me estoy perdiendo? ¿Alguien ha implementado esto realmente?

authentication pgp sso

pregunta histocrat 02.04.2013 - 20:14

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication pgp sso

¿Se considera que el último cifrado de Apple es de municiones? TLS y seguridad del correo electrónico

score 4 · Answer 1

Hasta cierto punto, lo que sugieres existe: se llama certificados X.509 .

Los principales problemas con los tokens firmados son:

Latencia de control: una vez que se ha firmado un token, no se puede cancelar de inmediato; Tienes que esperar a que caduque el token. O implementa una comprobación de revocación en línea (que se denomina OCSP en el caso de los certificados X.509), lo que lo regresa al modelo del "servidor de autenticación en línea".
Sincronización de reloj: para imponer una fecha de caducidad, un verificador debe tener un reloj razonablemente preciso, que puede ser un desafío en un contexto de seguridad. De hecho, los sistemas operativos modernos saben NTP fuera de la caja, pero NTP no está protegido.
Fichas firmadas para autenticación , no autorización . El servidor B quiere estar seguro de que está hablando con el cliente correcto, pero también quiere saber si ese cliente tiene permiso para acceder al servicio. No es fácil ajustar una matriz de autorización genérica dentro de un token firmado. Casi todos los que intentaron trabajar con certificados X.509 intentaron usarlos para obtener la autorización, y lo lamentaron.

Con un servidor de autenticación en línea, con el que tanto A como B hablan, ese servidor de autenticación puede actuar como un gran interruptor de supresión, con cancelación inmediata y también un posible control de autorización detallado.

score 3 · Answer 2

Si entiendo tu ejemplo correctamente, parece que estás hablando de aplicar algo como Kerberos al SSO. Siempre que el proveedor de servicios sepa cómo confiar en el servidor de autenticación de otorgamiento de tickets, entonces sí, debería ser seguro.

En cuanto a por qué no se hace de esa manera, creo que puede proporcionar un mayor control de la información y mantenerla actualizada. Cuando el proveedor del servicio realmente solicita detalles sobre el usuario del servicio en sí, puede actualizar la información en un lugar y reflejarla en múltiples sistemas.

Si dijera que soy AJ Henderson y que Facebook firmara algo que decía que yo era AJ Henderson, pero luego cambié mi nombre a Bilbow Bagins, la información firmada no se actualizaría, pero el token que vincula mi cuenta sería capaz de obtener actualizaciones. Tampoco tiene que preocuparse por cosas como la caducidad de las firmas, ya que cada verificación se realiza de forma reciente. Esto significa que se necesitan más intercambios, pero también proporciona un control más estricto.