2012-02-04 10 views
6

Estoy construyendo un sitio web que está protegido con un token SAML para el inicio de sesión único. Uno de los formularios tiene muchos campos de entrada, que deben desencadenar actualizaciones y validación en el mismo u otros campos de entrada y contenido de tabla.volver a utilizar un token SAML, lado del cliente para un servicio web JSON: después de iniciar sesión en el sitio web

La validación y las actualizaciones se manejan desde el lado del servidor. Una actualización de un valor en el formulario desencadena javascript que notifica al servidor, utilizando un servicio web WCF JSON. El servicio devuelve nuevos valores y mensajes de validación.

El problema es que el servicio web debe estar protegido y el acceso debe otorgarse, utilizando el token SAML emitido para el usuario iniciando sesión en el sitio web.

[Editar: más investigación realizada] Después de la autenticación, el token SAML siempre se pasa al servidor en forma de una cookie FedAuth. Agregar el token al JSON (o ajax) Obtener encabezado no es necesario. El problema es que no puedo permitir que WIF maneje la verificación de la cookie. Así que eliminé la autenticación fedarated del servicio JSON e intentaré leer la cookie, desde HttpContext. Lo que funciona, pero no puedo descifrarlo.

¿Hay alguien con exprerience con esto? ¿Hay alguien con experiencia en esto?

Respuesta

1

El token no se pasa como una cookie FedAuth. Eso es generado por el sitio web en sí (por WIF realmente). El token generalmente se pasa como un POST luego de una autenticación exitosa en el IdP.

Si los servicios web están alojados conjuntamente en el mismo sitio web, entonces "simplemente funciona", gracias a la magia de WIF. Las llamadas a los servicios incluirán la cookie y WIF la analizará/verificará felizmente, y le dará un IPrincipal (un IClaimsPrincipal).

Cuestiones relacionadas