¿Cómo puedo confiar en que los encabezados HTTP de SiteMinder no se hayan manipulado?

Question

Soy completamente nuevo en SiteMinder y SSO en general. Recorrí toda la tarde el sitio web de SO y CA para obtener un ejemplo básico y no puedo encontrar uno. No me importa configurar o programar SM o algo así. Todo eso ya lo ha hecho alguien más. Solo quiero adaptar mi aplicación web JS para usar SM para la autenticación.

Supongo que SM agregará un encabezado HTTP con una clave como SM_USER que me dirá quién es el usuario. Lo que no entiendo es: ¿qué impide que alguien agregue este encabezado y omita por completo SM? ¿Qué debo poner en mi código del lado del servidor para verificar que SM_USER realmente venga de SM? Supongo galletas seguras están involucrados ...

Answer 1

El agente web SM instalado en la Web servidor está diseñado para interceptar todo el tráfico y comprueba si la solicitud de recursos es ...

1. protegido por SiteMinder

2. Si el usuario tiene una SMSE válida SIÓN (es decir está autenticado)

3. Si 1 y 2 son verdaderas, entonces el WA comprueba el servidor de políticas de SiteMinder para ver si el usuario está autorizada de para acceder al recurso solicitado.

Para asegurarse de que usted no tiene inyecciones cabecera HTTP de la información del usuario, la SiteMinder WebAgent volverá a escribir toda la información específica de SiteMinder encabezado HTTP. Básicamente, esto significa que puede "confiar" en la información SM_ que WebAgent presenta sobre el usuario, ya que es creada por el Agente web en el servidor y no como parte de la solicitud entrante.

Answer 2

Debido a que todo el tráfico debe pasar a través del agente web Siteminder por lo que incluso si el usuario establece esta cabecera se sobrescribirá/elimina

Answer 3

SiteMinder r12.52 contiene una nueva funcionalidad llamada Enhanced Session Assurance con DeviceDNA ™. DeviceDNA se puede utilizar para garantizar que la cookie de sesión de SiteMinder no se haya manipulado. Si la sesión se reproduce en una máquina diferente o desde otra instancia de navegador en la misma máquina, DeviceDNA detectará esto y bloqueará la solicitud.

Click here to view a webcast discussing new features in CA SiteMinder r12.52

Answer 4

arquitecturas Todo Siteminder sí hacen la suposición de que la aplicación sólo tiene que confiar en los encabezados "SM_".

En la práctica, esto puede no ser suficiente según la arquitectura de su aplicación. Básicamente, usted tiene 3 casos:

• El agente web está instalado en el servidor web en la que se ejecuta la aplicación (caso típico de aplicaciones Apache/PHP): como se dijo anteriormente, se puede confiar en las cabeceras como ninguna solicitud puede llegue a su aplicación sin ser filtrado por el agente web.
• El Agente web está instalado en un servidor web diferente al que ejecuta su aplicación, pero en la misma máquina (caso típico: Agente SM instalado en un servidor front-end Apache que sirve un servidor de aplicaciones JEE): debe asegurarse de que ninguna solicitud puede llegar directamente a su servidor de aplicaciones. O enlaza su servidor de aplicaciones a la interfaz loopback o filtra los puertos en el servidor.
• El agente web se ejecuta con un proxy inverso en frente de su aplicación. El mismo comentario. La única solución aquí es implementar un filtro de IP en su aplicación para permitir solo las solicitudes provenientes de su proxy inverso.

Answer 5

Arquitectura típica empresa será Servidor web (Siteminder agente) + AppServer (Aplicaciones)

filtrado Say IP no está habilitado, y las solicitudes bandas se permitió directamente a AppServer, sin pasar por el servidor web y el OPB-agente.

Si las aplicaciones tienen que implementar una solución para afirmar que los encabezados/cookies de solicitud no se manipulan/inyectan, ¿tenemos alguna solución similar a la siguiente?

• Enviar el SM_USERID cifrada en una cookie separada o cifrado (Sym/Asin) junto con id SMSESSION
• aplicación utilizará la clave para descifrar el SMSESSION o SM_USERID retrive el identificador de usuario, el estado de caducidad de sesión y cualquier otros detalles adicionales y detalles de autorización si corresponde.
• aplicación ahora confía en el user_id y hacer la autenticación