SSO
En gestión de identidad, SSO es single sign-on: un solo evento de autenticación da acceso a muchas aplicaciones, de forma que el usuario demuestra quién es una vez y cada aplicación acepta una aserción en lugar de tener su propio acceso. Es cómodo, elimina un montón de contraseñas y concentra el riesgo en un solo sitio.
Cómo funciona
Un proveedor de identidad autentica al usuario y emite una aserción firmada a cada proveedor de servicio que confía en él. La aplicación valida la firma, lee las afirmaciones y crea su propia sesión local. En la práctica esto lo transportan dos protocolos: SAML, basado en XML y todavía dominante en el software corporativo, y OpenID Connect, construido sobre OAuth 2.0 y dominante en las aplicaciones más nuevas y en las móviles.
El detalle que importa en la operación es que hay dos sesiones, no una. La sesión del proveedor de identidad decide si se te va a volver a preguntar; la sesión dentro de cada aplicación es independiente de esa y tiene su propia duración.
Qué sale mal
Esa segunda sesión es el hallazgo recurrente. Dar de baja a un usuario en el proveedor de identidad impide que se emitan aserciones nuevas y no hace nada con las sesiones ya creadas dentro de cada aplicación, así que un usuario revocado sigue trabajando hasta que caduque cada sesión local. Durante un incidente, cuando la velocidad es todo, esa es la diferencia entre contener y aparentar que se ha contenido.
El segundo asunto es el radio de daño. Comprometer el proveedor de identidad es comprometer todo lo que hay detrás, y las rutas que usamos rara vez son un fallo del protocolo: un administrador sin una credencial resistente al phishing, una relación de confianza añadida para un proveedor, un certificado de firma guardado donde puede leerlo un equipo de aplicación, o la posibilidad de registrar una aplicación nueva y concederle permisos. El proveedor merece por tanto los controles de un controlador de dominio, y con frecuencia se administra como una aplicación de negocio.
El tercero es lo que se queda fuera. Todos los parques tienen sistemas que no soportan federación, y acaban con credenciales locales y sin visibilidad central, que es a donde va primero el password spraying.
Dónde aparece esto en una auditoría
Probamos la vía de revocación de forma explícita, porque es el control que los clientes creen tener con más frecuencia: deshabilitar la cuenta y después seguir usando una sesión de aplicación establecida antes, anotando cuánto sobrevive. Revisamos también quién puede administrar el proveedor, registrar aplicaciones y modificar la confianza, y enumeramos qué no está federado. El hallazgo suele estar en las costuras y no en el protocolo. Esto forma parte de cómo evaluamos la plataforma de identidad que hay detrás de tus aplicaciones.