Arquitectura de seguridad
Esta sección describe varios puntos de extensibilidad que se pueden utilizar para modificar o extender la funcionalidad del componente de seguridad de Windows Communication Foundation (WCF). Para entender estos puntos de extensibilidad, es necesario comprender la arquitectura de seguridad completa de WCF. En este tema se describe la arquitectura de seguridad de WCF según sus componentes y relaciones, y cómo los puntos de extensibilidad que se van a describir posteriormente en esta sección se ajustan al modelo de arquitectura global.
Ámbito del componente de seguridad de WCF
La seguridad de WCF abarca varios componentes en la arquitectura de WCF. El objetivo principal de la seguridad en WCF es proporcionar integridad, confidencialidad, autenticación, autorización y auditoría para las aplicaciones generadas en la parte superior con el marco de WCF. La arquitectura de WCF divide estas funciones en las partes siguientes:
Seguridad de transferencia: responsable de proporcionar confidencialidad a los mensajes, integridad a los datos y la autenticación de las partes que se comunican.
Autorización: responsable de proporcionar un marco para tomar decisiones de autorización.
Auditoría: responsable del registro de eventos relacionados con la seguridad en el registro de auditoría.
Modos de seguridad y ámbito de este documento
Se puede realizar la seguridad de la transferencia con uno de los modos de seguridad siguientes:
Transporte. Las tres funciones de seguridad de comunicación son proporcionadas por el transporte que se utiliza para transmitir los mensajes entre el cliente y el servicio.
Mensaje. La seguridad de transferencia se proporciona solamente en el nivel de mensaje SOAP, lo que significa que la seguridad se aplica directamente al mensaje SOAP en el nivel de XML.
Transporte con credencial de mensaje. La seguridad de transferencia se aplica tanto en el nivel de transporte como en el nivel de mensaje. El nivel de transporte proporciona confidencialidad de la comunicación, integridad de datos y autenticación del servicio. El mensaje proporciona la autenticación del cliente.
El resto de este documento se concentra en modo de seguridad del mensaje aunque se puede aplicar también parte de la información al modo de transporte con credencial de mensaje. De manera concreta, la parte de este documento que se aplica a la autenticación del cliente también se aplica al modo de transporte con credencial de mensaje porque este modo utiliza el nivel de mensaje para realizar la autenticación del cliente de la misma forma que lo hace el modo de mensaje.
Las discusiones sobre los componentes de autorización y auditoría se aplican a los tres modos de seguridad de la misma manera. Por consiguiente, toda la información relacionada con estos componentes descrita en este documento se aplica a todos los modos de seguridad compatibles.
Conceptos de modo de seguridad del mensaje
Modelo WS-Security
El modo de seguridad de mensajes se basa en la especificación WS-Security. La especificación de WS-Security define un marco que permite aplicar seguridad a los mensajes SOAP. Especifica un modelo de seguridad del mensaje utilizando tokens de seguridad combinados con firmas digitales y cifrado para proteger y autenticar mensajes SOAP. Consulte la especificación en Web Services Security (WS-Security).
Terminología
Un token de seguridad asegura las notificaciones y se puede utilizar para asegurar el enlace entre los secretos de autenticación o las identidades de las claves y de seguridad.
Una notificación es una declaración realizada por una entidad sobre una entidad (por ejemplo, un nombre, identidad, grupo, clave, grupo o privilegio). Se hace referencia a la entidad que realiza la notificación como un emisor de notificaciones; se hace referencia a la entidad sobre la que se realiza la notificación como un asunto de notificación.
Un emisor de la notificación puede responder o refrendar las notificaciones en un token de seguridad utilizando su clave para firmar o cifrar el token de seguridad. Esto permite la autenticación de las notificaciones en el token de seguridad.
Las firmas del mensaje se utilizan para comprobar el origen y la integridad del mensaje. Las firmas del mensaje también las utilizan los creadores de los mensajes para mostrar el conocimiento de la clave, normalmente desde un tercero, que se utiliza para confirmar las notificaciones en un token de seguridad y así enlazar su identidad (y otras notificaciones representadas por el token de seguridad) con los mensajes que crean.
Tokens de seguridad
WS-Security define varios tipos de tokens de seguridad y proporciona un modelo extensible que permite que los tipos de token de seguridad adicionales se definan de manera independiente. Cada definición de tipo de token contiene una serialización XML del token. Esto permite agregar la representación del token directamente al mensaje.
A continuación, se muestran algunos de los tipos de token de seguridad definidos en WS-Security:
Token del nombre de usuario.
Token del certificado X.509.
Token de Kerberos.
Token de SAML.
Hay cuatro maneras definidas de utilizar tokens, y los tokens adjuntos a un mensaje determinado se clasifican exactamente dentro de una de estas categorías:
SignedSupporting
SignedEndorsing
SignedEncrypted
EncryptedEndorsing
En .NET Framework 3.0, un mensaje de cliente puede contener un solo token de cada tipo, pero puede contener tokens de tipos diferentes.
En .NET Framework 3,5, los mensajes de cliente pueden contener varios tokens de cada tipo, así como tokens de tipos diferentes.
Esta característica permite una variedad de escenarios, entre los que se incluyen los siguientes:
Envío de notificaciones incremental. Todas las operaciones de un servicio pueden necesitar la presencia de un conjunto de notificaciones, pero algunas operaciones pueden necesitar notificaciones adicionales. En lugar de utilizar tokens emitidos de manera independiente para cada operación, el cliente puede obtener un token emitido con el conjunto inicial de notificaciones y utilizar otro token emitido con el resto de las notificaciones necesarias para la operación a la que se está llamando.
Autenticación multifactor. Cuando el cliente debe reunir tokens emitidos desde varios emisores o tokens emitidos con diferentes conjuntos de notificaciones antes de que se le permita realizar una operación. WCF considera el token emitido como un tipo de token, por lo que este escenario requiere la capacidad de disponer de dos tokens emitidos auxiliares en el mensaje.
Tenga en cuenta que no se puede configurar un servicio de esta manera: un servicio puede contener solo un token auxiliar.
Para obtener más información, vea Cómo: Utilizar múltiples tokens de seguridad del mismo tipo.
Implementación de WS-Security
Dado que WS-Security pone una base para la seguridad del mensaje, la implementación de WCF de WS-Security es una piedra angular de todo el modo de seguridad del mensaje. Para extender la funcionalidad del modo de seguridad, es necesario entender cómo funciona la implementación de WS-Security.
La implementación de WS-Security en WCF administra lo siguiente:
La serialización de tokens de seguridad a y desde los mensajes SOAP.
La autenticación de tokens de seguridad.
La aplicación y comprobación de firmas de mensajes.
El cifrado y descifrado de mensajes SOAP.
Los puntos de extensibilidad de WCF permiten la personalización de los dos primeros elementos. Es posible cambiar la serialización de tokens de seguridad existentes o la forma en que la seguridad de WCF autentica esos tokens. También es posible introducir completamente los nuevos tipos de tokens de seguridad a la seguridad de WCF, incluida la funcionalidad de serialización y autenticación.
En los temas siguientes de esta sección se muestra cómo se pueden usar los puntos de extensibilidad de implementación de WS-Security para personalizar la funcionalidad de los tokens de seguridad.
Autorización
Los tokens de seguridad se deserializan desde el mensaje entrante y se autentican. El proceso de autenticación produce un conjunto de objetos de directiva de autorización. Cada objeto representa una parte de los datos del token de seguridad. Estos datos se utilizan durante la fase de autorización.
La directiva de autorización crea un conjunto de notificaciones que un token de seguridad determinado representa. Se ofrece este conjunto de notificaciones para las decisiones de autorización para ServiceAuthorizationManager y la lógica dentro de la propiedad AuthorizationContext.
Identidad
Además de las notificaciones, WCF crea una implementación de la interfaz IIdentity para representar al autor de la llamada a la infraestructura existente (creada por el modelo de seguridad de .NET Framework). Esta instancia de IIdentity representa la identidad de Windows del autor de la llamada si se asigna el token de seguridad a una cuenta de Windows o a una identidad principal que contiene el nombre del autor de la llamada. Esas identidades también son accesibles utilizando ServiceSecurityContext. (Para obtener más información, vea Cómo: Examinar el contexto de seguridad.) Es posible personalizar la manera en que se crean las identidades en WCF utilizando uno de los métodos siguientes:
Implementación de una extensión personalizada de la clase SecurityTokenAuthenticator.
Integración con ASP.NET mediante la extensión de la clase MembershipProvider o mediante la creación de una implementación de IAuthorizationPolicy personalizada y su conexión a ServiceAuthorizationManager.
Creación de un IAuthorizationPolicy personalizado.
El proveedor de pertenencias personalizado solo funciona si se utiliza la autenticación mediante nombre de usuario y contraseña para autenticar al llamador. MembershipProvider valida el par de nombre y contraseña . Si son válidos, WCF crea una identidad primaria que representa al autor de la llamada autenticado después de la validación MembershipProvider.
Para facilitar la integración con la infraestructura de seguridad .NET Framework existente, WCF establece de forma predeterminada la propiedad CurrentPrincipal en una instancia IPrincipal que representa al autor de la llamada. La instancia IPrincipal se crea dependiendo de la información contenida en el IIdentity generado.
IIdentity se puede aumentar aún más integrando con el RoleProvider de ASP.NET. RoleProvider agrega un conjunto de funciones a las que pertenece el llamador. La lógica de autorización usa esta información para tomar la decisión de acceso.
Para obtener más información sobre la identidad, consulte Identidad del servicio y autenticación.
Envío de mensajes seguros
La ilustración siguiente muestra cómo se protege un mensaje en el cliente cuando se usa el modo de seguridad de mensajes. En la ilustración se muestran los componentes involucrados y las relaciones entre ellos:
El código de aplicación se ejecuta y genera un mensaje.
En la fase de aprovisionamiento de token, se adjuntan las credenciales del cliente (como los certificados X.509). En un escenario federado, se contacta con un emisor de token para proporcionar las credenciales.
Las credenciales se utilizan para crear el token de seguridad.
En la fase de autenticación de token, se comprobarán los tokens.
Finalmente, los tokens de seguridad se serializan y se envían.
.gif "Enviar un mensaje seguro")
Recepción de mensajes seguros
En la ilustración siguiente se muestran los procesos que se producen cuando un mensaje seguro se extrae de la conexión y se comprueba en el lado receptor:
Los tokens de seguridad se deserializan y se procesan en la fase de autenticación de token. Si se desea, se puede usar un proveedor de suscripciones de ASP.NET para proporcionar en este punto los nombres de usuario y contraseñas.
Después de la autenticación, se extraen las directivas de autorización.
En la fase de evaluación de directivas de evaluación, las directivas de autorización se evalúan y se pueden agregar notificaciones a un contexto de evaluación. En este punto, se utilizan las directivas de autorización externas. Este paso, al igual que el siguiente, lo realizan métodos del ServiceAuthorizationManager.
En la fase de autorización del servicio, las autorizaciones correctas se proporcionan según las notificaciones agregadas por las directivas de autorización. Este paso lo realizan métodos del ServiceAuthorizationManager.
Después de que se produzca la autorización, la suplantación del autor de la llamada se produce si así lo permite al autor de la llamada y el método de servicio lo requiere, o se define la propiedad ImpersonateCallerForAllOperations en el comportamiento de autorización de servicio. Para obtener más información, vea Delegación y suplantación con WCF.
WCF genera un PrincipalPermission mediante las credenciales en este punto. Si es necesario, se puede usar un proveedor de funciones de ASP.NET en este punto.
El código de aplicación se ejecuta.
.gif "Recepción de un mensaje seguro")
Información general de puntos de extensibilidad de seguridad
En la ilustración siguiente, se muestran los puntos de extensibilidad proporcionados por los componentes de seguridad de WCF. La ilustración está dividida en cuatro categorías diferentes que dependen del momento en que se alcance ese punto de la extensibilidad durante el procesamiento de mensajes. Esas categorías se asignan a las fases de procesamiento de seguridad en el mensaje tal y como se ha descrito en las dos secciones anteriores. La ilustración también muestra que las tecnologías de infraestructura existentes se pueden integrar con la seguridad de WCF.
.gif "Puntos de extensibilidad de seguridad WCF")
Vea también
Referencia
PrincipalPermission
ServiceAuthorizationManager
ServiceSecurityContext
Conceptos
Arquitectura de Windows Communication Foundation
Delegación y suplantación con WCF