Para acceder a servicios seguros (basados en token o credenciales), Esri recomienda usar archivos proxy ( ejemplo .net github ). Al enrutar solicitudes a través del proxy, puede solicitar servicios seguros en nombre del cliente sin exponer sus credenciales. Puede definir una propiedad llamada allowedReferers
y asignar una lista de URL de referencia para las que funcionará el proxy. Básicamente, el proxy no hará ninguna solicitud de URL de referencia que no estén definidas. Si se establece en '*'
, se procesará cualquier solicitud de referencia.
El problema es; un hacker puede suplantar fácilmente el encabezado solicitante simplemente configurando una propiedad falsa de referencia HTTP . En esta situación, pueden acceder a servicios seguros enrutando todas sus solicitudes a través del proxy y configurando el encabezado del árbitro a una dirección válida.
Estoy buscando recomendaciones sobre la mejor manera de solucionar este problema. ¿Alguna recomendación?
fuente
agstoken
clave. Esto no agrega mucha seguridad adicional, pero al menos el token no aparece en la cadena de consulta.Respuestas:
Alojo el proxy Java en Apache Tomcat que proporciona una página de inicio de sesión. El proxy ArcGIS se ejecuta en el mismo contexto de aplicación que la página de inicio de sesión. De esta manera, mis usuarios obtienen acceso con credenciales almacenadas en una base de datos segura y separada. Tomcat realiza la administración de sesión habitual, mientras que el proxy ArcGIS ligeramente modificado maneja las credenciales y tokens ocultos de ArcGIS. Todo esto se hace a través de HTTPS.
El resultado es que:
fuente
Creo que esta oración es la clave. Cuando el proxy se autentica en el servidor SIG, ¿está configurado con credenciales? Si es así, y esas credenciales tienen acceso al servicio de mapas que se solicitó, entonces parecería que está "funcionando según lo previsto".
Si el proxy está almacenando / pasando credenciales, entonces el proxy está más preocupado por mantener las credenciales seguras que mantener los datos seguros. Piense en un sitio de intranet de la empresa que muestra datos de mapas de un servicio de mapas seguro.
¿La declaración anterior significa que un atacante externo puede comunicarse con su proxy directamente? Si es así, tiene más de qué preocuparse que un encabezado HTTP falso.
¿Los usuarios, el proxy y el servidor SIG están todos dentro de su red, o los usuarios están usando el proxy para conectarse a los servicios SIG fuera de la red? Conocer algunos detalles sobre la topología de su red podría ayudarlo a obtener mejores respuestas.
editar: si tiene una aplicación web pública que está obteniendo recursos de un servidor SIG seguro dentro de una red, entonces probablemente desee un proxy inverso en lugar de un proxy directo.
fuente