.net - gratuito - malwarebytes free
Single sign on cookie eliminado por el software anti spyware (3)
Tenemos una implementación de inicio de sesión único para una familia de sitios web donde la cookie de autenticación proviene del dominio raíz (por ejemplo, bar.com), lo que les permite iniciar sesión en un dominio secundario (por ejemplo, foo.bar.com). La implementación está en C # utilizando la autenticación de formularios .net estándar.
Desafortunadamente, algunos de nuestros usuarios están eliminando sus cookies de autenticación con el software anti spyware. Pude recrear esta situación utilizando PC Tools Anti Spyware e IE8.
El resultado práctico es que los usuarios inician sesión en el sitio, navegan a otra página y luego se les pide que inicien sesión de nuevo.
La cookie está marcada como una cookie de seguimiento de bajo riesgo por el software anti spyware.
¿Hay alguna forma de hacer que la cookie sea más apetecible para los gustos aparentemente más exigentes del software anti spyware de nuestro usuario?
Actualizar:
He buscado en el líder ". problema y es una pista falsa. IE no le importa y, como descubrí a través de esta publicación , la especificación RFC 2965 requiere que los implementadores suministren un punto inicial.
La lectura adicional me llevó al artículo "Alerta de privacidad: las variantes de cookies se pueden utilizar para rodear bloqueadores, herramientas anti-spyware" . Esencialmente, muchos sitios web están utilizando subdominios como una forma de ocultar las cookies de seguimiento.
Parece que algún software antispyware respetará las declaraciones P3P (Plataforma de preferencias de privacidad) en el dominio principal. Desafortunadamente, debido a la falta de soporte de los implementadores del navegador, el trabajo se ha suspendido en P3P.
En esta etapa, creo que la solución al problema será la sugerida por un usuario: el subdominio tendrá que crear su propia cookie de autenticación.
Puede verificar que su cookie de autenticación esté utilizando el dominio .bar.com que debería funcionar en www.bar.com , foo.bar.com , etc.bar.com .
Este comportamiento exacto depende del navegador, pero esta es la práctica común de permitir la misma cookie en múltiples subdominios. Tenga en cuenta que si su cookie de autenticación configuró originalmente www.bar.com , un buen navegador debería rechazarla para foo.bar.com pero no para foo.www.bar.com
¿Tengo algún sentido? :-)
Actualización: parece que puede anular el domain en la sección <forms de su Web.config, aquí hay un enlace . Yo comenzaría allí.
Construí un sistema como este. Hay un dominio que realiza el inicio de sesión (sitio de autenticación). Si el inicio de sesión es exitoso redirecciona al usuario del sitio de autenticación al sitio que inició el inicio de sesión con un token único. Entonces ese sitio establece su propia cookie y mueve a su tío. Cuando finaliza la sesión, debe ir directamente al sitio de autenticación, que borra la cookie como parte de la redirección al sitio. Su sitio luego elimina su propia cookie. Jajaja espero que tenga sentido!
Puede examinar transportes predeterminados en las especificaciones del protocolo SAML SSO para tener más ideas. El archivo con todos los documentos está aquí http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip, busque "Aserciones y protocolos" para la descripción del protocolo y "Vinculaciones" para posibles transportes. (en particular en redirigir y POST).
La idea común es preguntar de alguna manera al servidor SSO si el usuario actual está autenticado y luego almacenar ese estado en caché con su propia cookie. De esta forma, cada aplicación establece solo cookies en el dominio propio.