Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este tema se tratan varios aspectos relacionados con las aplicaciones federadas, los límites de confianza y la configuración, y el uso de tokens emitidos en Windows Communication Foundation (WCF).
Servicios, servicios de token de seguridad y confianza
Los servicios que exponen puntos de conexión federados suelen esperar que los clientes se autentiquen mediante un token proporcionado por un emisor específico. Es importante que el servicio esté configurado con las credenciales correctas para el emisor; de lo contrario, no podrá comprobar las firmas sobre los tokens emitidos y el cliente no podrá comunicarse con el servicio. Para obtener más información sobre cómo configurar las credenciales del emisor en el servicio, consulte How to: Configure Credentials on a Federation Service( Cómo: Configurar credenciales en un servicio de federación).
Del mismo modo, al usar claves simétricas, las claves se cifran para el servicio de destino, por lo que debe configurar el servicio de token de seguridad con las credenciales correctas para el servicio de destino; de lo contrario, no podrá cifrar la clave del servicio de destino y, de nuevo, el cliente no podrá comunicarse con el servicio.
Los servicios WCF usan el valor de la propiedad MaxClockSkew en SecurityBindingElement para permitir el desfase de reloj entre el cliente y el servicio. En la federación, la configuración MaxClockSkew se aplica a las desviaciones del reloj entre el cliente y el servicio de token de seguridad desde el cual el cliente obtuvo el token que fue emitido. Por lo tanto, los servicios de token de seguridad no necesitan realizar ajustes por desajuste de reloj al establecer los tiempos de vigencia y expiración del token emitido.
Nota:
La importancia del sesgo del reloj aumenta a medida que la duración del token emitido se acorta. En la mayoría de los casos, la asimetría del reloj no es un problema significativo si la duración del token es de 30 minutos o más. Los escenarios con duraciones más cortas o en los que el tiempo de validez exacto del token es importante deben diseñarse para tener en cuenta la asimetría del reloj.
Extremos federados y tiempos de espera
Cuando un cliente se comunica con un punto de conexión federado, primero debe adquirir un token adecuado de un servicio de token de seguridad. Si el servicio de token de seguridad expone un punto de conexión federado, el cliente primero debe obtener un token del emisor para ese punto de conexión. Cada adquisición de tokens tarda tiempo y ese tiempo está sujeto al tiempo de espera general para enviar el mensaje real al punto de conexión final.
Por ejemplo, el tiempo de espera en el canal del lado cliente se establece en 30 segundos. Se debe llamar a dos emisores de tokens para recuperar tokens antes de enviar el mensaje al punto de conexión final y cada uno tarda 15 segundos en emitir un token. En este caso, no se realizará el intento correctamente y se produce una TimeoutException. Por lo tanto, debe establecer el OperationTimeout valor en el canal de cliente en un valor lo suficientemente grande como para incluir el tiempo necesario para recuperar todos los tokens emitidos. En el caso de que no se especifique un valor para la OperationTimeout propiedad , la OpenTimeout propiedad o la SendTimeout propiedad (o ambas) deben establecerse en un valor lo suficientemente grande como para incluir el tiempo necesario para recuperar todos los tokens emitidos.
Vigencia y renovación de tokens
Los clientes WCF no comprueban el token emitido al realizar una solicitud inicial a un servicio. En su lugar, WCF confía en el servicio de token de seguridad para emitir un token con tiempos de efectividad y expiración adecuados. Si el cliente almacena en caché el token y se reutiliza, la duración del token se comprueba en las solicitudes posteriores y el cliente renueva automáticamente el token si es necesario. Para obtener más información sobre el almacenamiento en caché de tokens, consulte How to: Create a Federated Client.
La especificación de duraciones cortas, en el orden de 30 segundos o menos para tokens emitidos o tokens de contexto de seguridad, puede dar lugar a tiempos de espera de negociación o bien a que los clientes WCF produzcan excepciones al solicitar tokens emitidos o al negociar o renovar tokens de contexto de seguridad.
Tokens emitidos y Modo de Inclusión
Si un token emitido se serializa en un mensaje enviado desde un cliente a un punto de conexión federado o no se controla estableciendo la InclusionMode propiedad de la SecurityTokenParameters clase . Esta propiedad se puede establecer en uno de los SecurityTokenInclusionMode valores de enumeración, pero no es útil en la mayoría de los escenarios federados. Los valores SecurityTokenInclusionMode.Never y SecurityTokenInclusionMode.AlwaysToInitiator hacen que el cliente envíe una referencia al token emitido por el servicio de token de seguridad a la parte confiable. A menos que el usuario de confianza posea una copia del token emitido, se producirá un error en la autenticación porque la referencia del token no se puede resolver. WCF trata SecurityTokenInclusionMode.Once como equivalente a SecurityTokenInclusionMode.AlwaysToRecipient.