SSL bidireccional para servicios web en GAE (java)

Question

Necesitamos implementar SSL bidireccional en Google App Engine, donde enviamos solicitudes de servicios web utilizando JAX-WS a un servidor que requiere autenticación SSL de 2 vías.

¿Cómo podemos configurar SSL bidireccional para nuestras solicitudes de servicios web salientes?

Sabemos que javax.net.ssl* está prohibido en el entorno de App Engine.

He aquí un ejemplo de nuestro código:

@WebService(name="ListenerSoap", targetNamespace = "http://example.com/Listener.Wsdl") 
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) 
public interface ListenerSoap { 

    @WebMethod(operationName = "Ping", action="http://example.com/Listener.Wsdl#Ping") 
    public void ping(); 
} 

@WebServiceClient(name="Listener", targetNamespace="http://example.com/Listener.Wsdl", wsdlLocation = "https://example.com/Listener.asmx?WSDL") 
public class Listener extends Service 
{ 
    public ListenerSoap getListenerSoap() { 
    return super.getPort(new QName("http://example.com/Listener.Wsdl", 
         "ListenerSoap"), ListenerSoap.class); 
    } 
} 

Y un ejemplo de código anterior en uso:

ListenerSoap soap = new Listener().getListenerSoap(); 
soap.ping(); 

Calculo que podemos almacenar los almacenes de claves o cualquier certs necesarios la DataStore como objetos binarios (aunque la forma de cargarlos sigue siendo un poco vaga para mí).

¿Cómo podemos hacer para establecer los valores necesarios necesarios para que este servicio web se autentique mediante SSL bidireccional?

Gracias por cualquier ayuda

Actualización:

través de la investigación que he visto esta es la forma en que se puede hacer en un servidor tradicional (uno con acceso de sistema de archivos):

ListenerSoap soap = new Listener().getListenerSoap(); 
((BindingProvider) soap).getRequestContext().put("javax.net.ssl.keyStore", "client_cert.p12" 

Sin embargo, en este enfoque, se espera que client_cert.p12 esté en el sistema de archivos.

Además, SSLSocketFactory, SSLContext, KeyManager y KeyManagerFactory no están permitidos en GAE.

Actualización:

A partir del GAE SDK versión 1.7.7. esto debería ser posible ahora:

Similarly, Java developers can now use the javax.net.ssl package to make outbound SSL connections. 

GAE 1.7.7 SDK Release Notes

Answer 1

Por lo que sé de dos SSL manera, usted no tendrá ningún vínculo con el código Java EE: dos vías SSL es una seguridad de capa de transporte: cuando la aplicación cliente intentará crear una conexión HTTP segura (HTTPS) con el servicio, el servidor solicitará un certificado y aprobará o no este certificado. Si se aprueba el certificado del cliente, se establecerá una conexión segura entre las partes y se les permitirá intercambiar algunos mensajes a través de este túnel. Pero este proceso se realiza en la capa de transporte. Su código (en la capa de aplicación) nunca será informado de este proceso. Para establecer un SSL de dos vías, la configuración se realiza en la configuración del servidor de aplicaciones para el puerto SSL.

Answer 2

ListenerSoap soap = new Listener().getListenerSoap(); 

espero que mejora

Gracias

Answer 3

Sé que usted podría no querer escuchar esto, pero utilizando SSL es caro y problemático para la comunicación bidireccional.Dependiendo de la cantidad de control que tenga sobre los extremos del servidor/cliente, prefiero un conducto bidireccional simple como sockets web y un protocolo de paquete de datos que simplemente puede implementar AES. Realmente depende del problema que intentas resolver.

Answer 4

Parece que hay confusión sobre la conexión simple a través de SSL (https://...) y lo que se conoce como "autenticación mutua" o "infraestructura de clave pública (PKI)". En realidad puedes hacer ambas cosas o una independientemente de otra. Con este último (a lo que creo que se refiere la pregunta original), cuando realiza una solicitud al servidor, el servidor responderá pidiéndole un certificado que debe presentar para autenticarse.

Para responder a la pregunta específica por encima de (carga de un almacén de claves a partir de datos binarios), no creo que esto es realmente posible, ya que es el tiempo de ejecución de Java que recoge en su almacén de claves. Lo único que puedes hacer es cargar los bits de tu almacén de datos y escribirlos temporalmente en el disco. Opcionalmente elimínelo cuando la aplicación exista. Esto lo he hecho antes y funciona bastante bien. Si hace esto, le recomiendo usar una ubicación probable que sea modificable (como System.getProperty("java.io.tmpdir"));), a continuación, después de escribir el archivo en disco, establezca las propiedades de JVM (por ejemplo System.getProperties().put("javax.net.ssl.keyStore","...");)

Answer 5

Tendrá Socket API de App Engine para esta. Esta API está en modo de prueba confiable, por lo que no está disponible para todos.

Usted puede solicitar una Gere acceso: https://docs.google.com/spreadsheet/viewform?formkey=dF9QR3pnQ2pNa0dqalViSTZoenVkcHc6MQ#gid=0

Answer 6

Desde mi conocimiento limitado acerca de la autorización SSL, parece que puede estar perdiendo algo de vital importancia aquí; los certificados. El SSL bidireccional requiere que los certificados del cliente y del servidor estén en su almacén de claves, que puede ser un certificado autofirmado (un archivo pkcs12 o pem, que puede generar fácilmente con algunos comandos a través de shell) o un certificado propietario emitido por una compañía autorizada como Thawte o Verisign. Aunque no estoy seguro de si ese es el problema al que se enfrenta, pero es bueno comprobarlo. (Además, soy novato así que por favor no degrade mi respuesta, solo intento sugerir posibles opciones.)

Answer 7

SSL de 2 vías (desde una aplicación alojada en GAE al mundo exterior) no es compatible hasta donde yo saber. Intenté una aplicación de muestra hace unos meses y me sentí frustrado al descubrir que GAE ni siquiera admite esta característica básica ... y la documentación tampoco está clara. No podrá presentar el certificado del cliente cuando se contacte con un servicio web. No hay lugar para almacenarlo, no se puede acceder al almacén de claves.