Artículo
· 23 sep, 2019 Lectura de 3 min

Desplegar servicios web con y sin autenticación

¡Hola a tod@s!

Este artículo lo encontré en el Blog de Ensemble >>. Sí, lo sé... parece un poco  "antiguo",  pero me pareció muy útil porque son dudas que siguen siendo recurrentes, así que espero os sea de utilidad.

La pregunta es: ¿cómo se deben desplegar los servicios web? ¿Cómo gestionar la autenticación?

En base a la experiencia que tenemos en otros clientes, es posible usar un usuario con permisos limitados para invocar los servicios. Esta opción inicialmente está bien, pero si estudiamos los requisitos de seguridad posiblemente se nos queda corto.

Lo ideal sería:

1 - Dejar el acceso al portal privado y evitar el acceso al puerto del portal desde el exterior

2 - Utilizar un puerto diferente para las invocaciones de servicios web y habilitar SSL si es necesario

3 - Facilitar el acceso no autenticado en la invocación del servicio si no es necesario identificar el usuario que invoca

4 - Establecer políticas de seguridad especificas para los usuarios y procesos que puedan ser invocados desde el exterior, como en este caso los servicios web.

Resumiendo la situación, cuando se despliega un servicio web en Ensemble, este servicio puede ser invocado a través del CSP Gateway (habilitando la propiedad "entable standard request" de manera que se dispone de URL) o a través del puerto directo del adaptador (no se dispone URL, solo servidor y puerto). 

Esta imagen representa la configuración expuesta en el párrafo anterior:

 

OPCIÓN 1:

Podéis utilizar para los servicios solo el puerto del adaptador, de manera que podéis establecer políticas de acceso y seguridad mediante cortafuegos, etc. diferentes para cada uno de estos puertos. Así podéis conservar el puerto del CSP Gateway privado dentro de una red limitada y solo con objeto de administración (es el canal que se utiliza para llegar al portal de gestión), mientras que el puerto del adaptador lo podéis hacer público para posibilitar la invocación del servicio. 

Sin embargo, esta opción tiene un par de restricciones: al no pasar por el CSP Gateway el WSDL no puede ser consultado por ese canal (el WSDL solo se genera a través de CSP, aunque esto se puede resolver publicando el WSDL de manera estática en una URL). Pero, además, no puedes establecer estrategias de seguridad basadas en CSP a la hora de invocar el servicio.


OPCIÓN 2:

Simplemente crear una nueva aplicación dentro del Namespace de la producción. De esta manera no necesitas un usuario con permisos especiales, incluso puedes no necesitar autenticación en el servicio y entonces se usará el UnknowUser como usuario que lo invoca.

Para tener 2 aplicaciones web asociadas al mismo Namespace (y así tener diferentes niveles y políticas de seguridad en una y en otra) hay que ir a security —> Web aplications y crear una nueva aplicación que use el mismo Namespace. Luego en el servicio web añadir un parámetro:

Parameter LOCATION = "http://localhost:57773/csp/test2”; // Cambiar por la URL de tu aplicación

Por supuesto hay que tener en cuenta que el usuario que invoque el servicio tenga los roles de acceso adecuados dentro del namespace.

Aquí el problema es que utilizareis el mismo puerto para los servicios y para el portal, de manera que no se puede limitar el acceso desde el exterior mediante cortafuegos o similares.


OPCIÓN 3:

Esta es la opción más general: consiste en instalar un nuevo servidor web (canal CSP Gateway) para manejar las peticiones por un puerto diferente del portal de administración (en este caso 1981). Esto soluciona gran parte de las cuestiones de seguridad, ya que las llamadas pasan por un canal CSP diferente al del canal de administración, que queda privado. 

De esta manera la configuración sería la siguiente:

 

Para llevarla a cabo, solo es necesario instalar un nuevo servidor web conectado a un nuevo CSP Gateway y configurarlo correctamente. Requiere hacer instalación de un par de componentes en la máquina (el servidor y el CSP gateway).

El problema es tener que involucrar a recursos de sistemas. Aunque a priori esta solución pueda parecer algo complicada, es muy flexible y escalable y no es difícil de implementar.

Espero haberme explicado adecuadamente. 

Comentarios (0)1
Inicie sesión o regístrese para continuar