Cómo utiliza EJBCA la autenticación OAuth

Al igual que todos los servicios compatibles con OAuth, EJBCA permite el acceso a los clientes que presentan un token de portador en un encabezado al comunicarse con el servidor web de EJBCA. Un token de portador es un objeto de datos firmado por un proveedor de identidad de confianza, como Azure, PingID, KeyCloak, etc., que contiene información sobre el usuario. Al comprobar la firma del token de portador , EJBCA confirma que la comunicación de red que contiene dicho token ha sido enviada por el usuario o por un tercero a quien el usuario le ha proporcionado el token, con la intención de que dicho tercero actúe como dicho usuario. En el caso de los sitios de administración o RA de EJBCA, el token de portador se crea cuando el usuario es redirigido a la página de inicio de sesión del servicio de autenticación de terceros y se envía a EJBCA cuando dicha página redirige el navegador de vuelta a EJBCA. En el caso de las API web de EJBCA, el token de portador debe adquirirse mediante una integración personalizada y enviarse como un encabezado HTTP al realizar llamadas a la API.

Esto significa que un token de portador es un objeto muy sensible y que su valor debe mantenerse en secreto. Su valor solo lo conoce el usuario actual (está contenido en el navegador) y la aplicación de destino, como EJBCA , que necesita ver el valor del token de portador para confirmar su validez. Por lo tanto, al iniciar sesión mediante OAuth, EJBCA ahora tiene ese token de portador y, en teoría, puede actuar como el usuario actual para cualquier otra aplicación que esté integrada con el mismo proveedor de OAuth. Y viceversa, cuando un usuario inicia sesión en otra aplicación que usa OAuth, esa aplicación ahora tiene un token de portador que, en teoría, podría enviarse a EJBCA para actuar como ese usuario. Esta configuración supone un alto nivel de confianza entre las aplicaciones que usan el mismo proveedor de OAuth.

Reclamación de audiencia (aud)

Para mayor seguridad en el escenario anterior, los proveedores de OAuth incluyen una declaración aud (o "Audiencia") en el token de portador cuando el usuario inicia sesión. La declaración aud es un valor que indica a qué aplicación está destinado el token de portador. Por ejemplo, si el sistema de correo electrónico de su organización utiliza OAuth para iniciar sesión, la pantalla de inicio de sesión podría indicar "Permitir que esta aplicación lea y envíe correos electrónicos" y la declaración aud podría estar configurada como email . Ese token de portador se presentaría entonces al sistema de correo electrónico para autenticar al usuario, pero solo para fines de correo electrónico.

Si EJBCA está configurado para permitir únicamente a los usuarios que presenten un token portador con la solicitud aud ejbca , el token portador conocido por el sistema de correo electrónico ya no podrá enviarse a EJBCA para realizar llamadas a la API en nombre del usuario conectado. La solicitud aud limita la aplicación a la que está destinado el token portador y permite que varias aplicaciones utilicen de forma segura el mismo sistema de inicio de sesión único sin comprometer la confianza entre todos los sistemas a los que tiene acceso un usuario.

Deshabilitar la comprobación de reclamaciones de audiencia

Algunos proveedores de OAuth (en particular, Ping Identity) no establecen la notificación aud cuando el usuario inicia sesión. En este caso, EJBCA no puede verificar que los tokens de portador presentados por un usuario estén destinados únicamente a la autenticación EJBCA. En tal caso, se debe tener cuidado al usar OAuth para la autenticación EJBCA, ya que otras aplicaciones que utilicen el mismo proveedor de identidad podrían actuar como un usuario conectado con EJBCA.

Establecer la audiencia

A continuación se explica cómo lograr que Azure y KeyCloak establezcan la audiencia.