sso single-sign-on siteminder

single-sign-on - sso - siteminder login



¿Cómo puedo confiar en que los encabezados HTTP de SiteMinder no han sido manipulados? (5)

Debido a que todo el tráfico debe pasar a través del Agente web de Siteminder, por lo que incluso si el usuario establece este encabezado, se sobrescribirá / eliminará

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

Comprendo 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 pase por alto a SM por completo? ¿Qué tengo que poner en mi código del lado del servidor para verificar que el SM_USER realmente proviene de SM? Supongo que las cookies seguras están involucradas ...

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

  1. Protegido por SiteMinder

  2. Si el usuario tiene un SMSESSION válido (es decir, está autenticado )

  3. Si 1 y 2 son verdaderos, el WA verifica el Servidor de políticas de Siteminder para ver si el usuario está autorizado para acceder al recurso solicitado.

Para asegurarse de que no tiene inyecciones de información de usuario en el encabezado HTTP, el Agente de sitio web de SiteMinder volverá a escribir toda la información del encabezado HTTP específico de SiteMinder. Básicamente, esto significa que puede "confiar" en la información de SM_ el Agente de Web está presentando sobre el usuario, ya que fue creada por el Agente Web en el servidor y no es parte de la solicitud entrante.

La arquitectura empresarial típica será Servidor web (Agente de Siteminder) + Servidor de aplicaciones (Aplicaciones)

Supongamos que el filtrado de IP no está habilitado, y las solicitudes de sitios web se permiten directamente a AppServer, sin pasar por el servidor web y el sso-agent.

Si las aplicaciones tienen que implementar una solución para afirmar que las cabeceras / cookies de solicitud no son manipuladas / inyectadas, ¿tenemos alguna solución similar a la siguiente?

  • Envíe el SM_USERID encriptado en una cookie separada o encriptado (Sym / Asym) junto con el ID de SMSESSION
  • La aplicación utilizará la clave para descifrar SMSESSION o SM_USERID para recuperar la identificación del usuario, el estado de vencimiento de la sesión y cualquier otro detalle adicional y detalles de autorización, si corresponde.
  • La aplicación ahora confía en el user_id y hace la autenticación

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

Haga clic aquí para ver un webcast sobre las nuevas funciones en CA SiteMinder r12.52

Todas las arquitecturas de Siteminder sí suponen que la aplicación solo tiene que confiar en los encabezados "SM_".

En la práctica, esto puede no ser suficiente dependiendo de la arquitectura de su aplicación. Básicamente, tienes 3 casos:

  • El Agente web se instala en el servidor web donde se ejecuta su aplicación (caso típico para aplicaciones Apache / PHP): como se indicó anteriormente, puede confiar en los encabezados ya que ninguna solicitud puede llegar a su aplicación sin ser filtrada por el agente web.
  • El Agente web está instalado en un servidor web diferente al servidor donde se ejecuta su aplicación, pero en la misma máquina (caso típico: el Agente SM instalado en un front-end de Apache que sirve un servidor de aplicaciones JEE): debe asegurarse de que no se puedan realizar solicitudes. llegar directamente a su servidor de aplicaciones. O vincula su servidor de aplicaciones a la interfaz de bucle invertido o filtra los puertos en el servidor.
  • El Agente Web se ejecuta en un proxy inverso frente a su aplicación. Mismo comentario. La única solución aquí es implementar un filtro de IP en su aplicación para permitir solo las solicitudes que provienen de su proxy inverso.