Autenticación del cliente mediante certificados en el motor de aplicaciones de Google Java

El punto de los certificados de usuario es que hay cosas que se almacenan en el lado del usuario, en particular la clave privada del usuario . Los certificados para la autenticación se utilizarán como parte de SSL (HTTPS es HTTP dentro de SSL).

En SSL, las cosas van de la siguiente manera:

• El cliente se conecta. El cliente y el servidor se comunican entre sí.
• El servidor muestra su certificado (que contiene la clave pública del servidor). El cliente verifica que el certificado es válido (debidamente firmado por una CA que el cliente confía; contiene el nombre del servidor deseado; no está vencido; y así sucesivamente) y luego utiliza la clave pública del servidor para realizar el intercambio de claves asimétrico del cual se deriva clave de sesión utilizada para proteger el flujo de datos posterior.
• El servidor puede solicitar un certificado de cliente . En ese caso, el cliente debe enviar su certificado (que contiene la clave pública del cliente) y demostrar el dominio de la clave privada correspondiente.

Todos estos pasos se realizan en el protocolo SSL y solo hay que dejarlos ejecutar. Sin embargo, su trabajo en el servidor es validar el certificado del cliente. Que es eso ? Un certificado, por sí mismo, no prueba nada. De hecho, todo el mundo puede crear un certificado autofirmado con contenido arbitrario; lo acabas de hacer tú mismo. Lo que hace que un certificado sea útil es cómo se ha generado en primer lugar.

En tu caso, hay principalmente tres posibilidades:

1. El servidor tiene una copia de todos los certificados de usuario (no las claves privadas) y, por lo tanto, puede comparar el certificado recibido con todos los certificados de usuario conocidos. Por lo tanto, un certificado se valida en virtud de ser bit a bit igual a un certificado conocido. Dado que el certificado se creó en el lado del cliente, esto requiere una fase de registro inicial en la que el usuario presente su certificado al servidor.

2. El servidor emite los certificados a los usuarios. Esto significa que para crear un certificado, algunos códigos en el lado del usuario (por ejemplo, en su navegador) generan un par de claves privadas / públicas, envían la clave pública al servidor y el servidor la coloca en un certificado nuevo junto con El nombre de usuario, y el servidor lo firma. El certificado resultante se devuelve al usuario. Más adelante, cuando el usuario se conecta, el servidor reconoce el certificado de usuario en virtud de que está firmado por el propio servidor: el servidor utiliza su propia clave pública para verificar la firma en el certificado de usuario. Si esa firma es válida, entonces el servidor sabe que el contenido del certificado es confiable, en particular el nombre de usuario.

3. El mismo sistema que en la situación 2, excepto que la emisión del certificado está delegada a otro sistema dedicado que se llamará Certificación Autoridad . El usuario obtiene su certificado de la CA, sin involucrar a su servidor. Su servidor puede validar el certificado enviado por el usuario al verificar que esté debidamente firmado por la CA; el servidor tiene una copia de la clave pública de la CA y confía en la CA para emitir certificados solo a usuarios debidamente autenticados.

Sólo el tercer caso realmente tiene sentido. Los certificados son útiles en situaciones en las que la afirmación de identidad (por parte de la entidad emisora de certificados) no está relacionada con el uso de dicha identidad (en su servidor). Si el servidor es el CA en sí mismo, el uso de certificados no ofrece ninguna ventaja sobre una autenticación basada en contraseña más simple (la "contraseña" puede ser una larga secuencia almacenada automáticamente por el navegador; esto se conoce como cookie ).

Si aún tiene intención de usar certificados, primero debe tener claro qué es una CA, qué hace y dónde encajará en su sistema.

Creo que no se puede autenticar al cliente mediante el protocolo de enlace SSL / TLS mutuo con GAE.

Para lograr esto en Java EE, debes poner esto en web.xml

<login-config>
    <auth-method>CLIENT-CERT</auth-method>
</login-config>

Fuente: enlace

Sin embargo, los documentos de AppEngine dicen:

  

App Engine no admite roles de seguridad personalizados ( <security-role> ) o mecanismos de autenticación alternativos ( <login-config> ) en el descriptor de implementación.

Fuente: enlace

Para que un usuario le presente un certificado válido para la autenticación, deberá proporcionar dicho certificado basándose en su clave autofirmada a dicho usuario de antemano. Según su comentario sobre la extracción del nombre del problema, parece que necesitará establecer una Autoridad de Certificación (CA) para generar certificados para proporcionar al usuario de antemano dicho nombre incrustado (y su clave autofirmada en la raíz).

Por lo general, ese tipo de aprovisionamiento es engorroso y contrario a la experiencia general de la web. En consecuencia, su estrategia no se utiliza y los navegadores no están diseñados para admitirla. Si desea continuar en esta línea, considere revisar cómo los certificados de SSH pueden ser autenticados (utiliza claves públicas y privadas de PKI pero no una cadena de confianza de CA, sin embargo, comprender el método debería ser esclarecedor).

Nuevamente, los navegadores de los usuarios no están diseñados para ofrecer este certificado, por lo que tendrá que proporcionar una función para cargarlos en su servidor. En cuanto a la validación y extracción del nombre, Java tiene las rutinas necesarias en la funcionalidad que proporciona la herramienta clave que ya ha utilizado.