Compartir a través de

Mecanismos de control de acceso

  • Artículo

Puede controlar el acceso de varias formas con Windows Communication Foundation (WCF). Este tema aborda brevemente los diversos mecanismos y proporciona sugerencias sobre cuándo utilizar cada uno; está destinado a ayudarle a seleccionar el mecanismo correcto a utilizar. Las tecnologías de acceso están listadas por orden de complejidad. La más simple es PrincipalPermissionAttribute; la más compleja es el modelo de identidad.

Además de estos mecanismos, la suplantación y delegación con WCF se explica en Delegación y suplantación.

PrincipalPermissionAttribute

PrincipalPermissionAttribute se utiliza para restringir el acceso a un método de servicio. Cuando el atributo se aplica a un método, se puede usar para exigir la identidad de un autor de llamada específico o la pertenencia a un grupo de Windows o rol ASP.NET. Si el cliente se autentica utilizando un certificado X.509, se le proporciona una identidad primaria que está compuesta del nombre de sujeto más la huella digital del certificado.

Utilice PrincipalPermissionAttribute para controlar el acceso a los recursos en el equipo en el que el servicio se está ejecutando y si los usuarios del servicio siempre formarán parte del mismo dominio de Windows en el que el servicio se está ejecutando. Puede crear con facilidad grupos de Windows que hayan especificado niveles de acceso (como ninguno, de solo lectura o lectura y escritura).

Para obtener más información sobre el uso del atributo, consulte Procedimiento para restringir el acceso con la clase PrincipalPermissionAttribute. Para obtener más información sobre la identidad, consulte Identidad de servicio y autenticación.

Proveedor de pertenencia a ASP.NET

Una característica ASP.NET es el proveedor de pertenencia. Aunque el proveedor de pertenencia no es técnicamente un mecanismo de control de acceso, permite controlar el acceso al servicio limitando el conjunto de posibles identidades que pueden tener acceso al punto de conexión del servicio. La característica de pertenencia incluye una base de datos que se puede rellenar con combinaciones de nombre de usuario/contraseña que permitan a los usuarios de un sitio Web establecer cuentas en el sitio. Para acceder a un servicio que use el proveedor de pertenencia, el usuario debe iniciar sesión con su nombre de usuario y contraseña.

Nota

Primero debe rellenar la base de datos mediante la característica ASP.NET antes de que un servicio WCF pueda usarla con fines de autorización.

También puede usar la característica de pertenencia si ya tiene una base de datos de pertenencia de un sitio web ASP.NET existente y quiere permitir que los mismos usuarios usen el servicio, de forma que los autorice con los mismos nombres de usuario y contraseñas.

Para obtener más información sobre el uso de la característica de pertenencia en un servicio WCF, consulte Procedimiento para usar el proveedor de pertenencia ASP.NET.

Proveedor de roles ASP.NET

Otra característica ASP.NET es la capacidad de administrar la autorización mediante roles. El proveedor de roles ASP.NET permite que un programador cree los roles para los usuarios y les asigne a uno o varios roles a cada uno. Al igual que con el proveedor de pertenencia, los roles y asignaciones están almacenados en una base de datos y se pueden rellenar mediante herramientas que proporciona una implementación determinada del proveedor de roles ASP.NET. Al igual que con la característica de pertenencia, los programadores WCF pueden usar la información de la base de datos para autorizar a los usuarios del servicio mediante roles. Por ejemplo, pueden utilizar el proveedor de funciones en combinación con el mecanismo de control de acceso PrincipalPermissionAttribute descrito anteriormente.

También puede usar el proveedor de roles ASP.NET si tiene una base de datos de proveedor de roles ASP.NET existente y quiere usar el mismo conjunto de reglas y asignaciones de usuarios en el servicio.

Para obtener más información sobre el uso de la característica de proveedor de roles, consulte Procedimiento para usar el proveedor de roles ASP.NET con un servicio.

Administrador de autorización

Otra característica combina el administrador de autorización (AzMan) con el proveedor de roles ASP.NET para autorizar a los clientes. Cuando ASP.NET hospeda un servicio web, AzMan se puede integrar en la aplicación para que la autorización del servicio se realice mediante AzMan. El administrador de roles ASP.NET proporciona una API que permite administrar roles de aplicación, agregar y quitar usuarios de roles y comprobar la pertenencia a roles, pero no permite consultar si un usuario está autorizado para realizar una tarea o una operación con nombre. AzMan le permite definir operaciones individuales y combinarlas en tareas. Con AZMan, además de las comprobaciones de la función, también puede comprobar si un usuario puede realizar una tarea. La asignación de funciones y la autorización de tareas se pueden configurar fuera de la aplicación o se pueden realizar mediante programación dentro de la aplicación. El complemento Microsoft Management Console (MMC) de administración de AzMan permite a los administradores cambiar las tareas que una función puede realizar en tiempo de ejecución y administrar la pertenencia de funciones de cada usuario.

También puede usar AzMan y el proveedor de roles ASP.NET si ya tiene el acceso a una instalación AzMan existente y quiere autorizar el servicio a los usuarios mediante las características de la combinación de AzMan o proveedor de roles.

Para obtener más información sobre AzMan y el proveedor de roles ASP.NET, consulte Procedimiento para usar el administrador de autorización (AzMan) con ASP.NET 2.0. Para obtener más información sobre el uso de AzMan y el proveedor de roles para los servicios WCF, consulte Procedimiento para usar el proveedor de roles del administrador de autorización ASP.NET con un servicio .

Modelo de identidad

El modelo de identidad es un conjunto de API que le permiten administrar demandas y directivas para autorizar a los clientes. Con el modelo de identidad, puede examinar cada demanda contenida en credenciales que el llamador utiliza para autenticarse a sí mismo para el servicio, comparar las demandas con el conjunto de directivas para el servicio y conceder o denegar acceso basándose en la comparación.

Utilice el modelo de identidad si necesita un control preciso y la capacidad de establecer criterios concretos antes de conceder el acceso. Por ejemplo, al utilizar PrincipalPermissionAttribute, el criterio simplemente es que la identidad del usuario se pueda autenticar y pertenezca a una función concreta. En cambio, utilizando el modelo de identidad, puede crear una directiva que establezca que el usuario debe ser mayor de 18 años y poseer una licencia de conducir válida antes de que se le permita ver un documento.

Un ejemplo donde puede beneficiarse del control de acceso basado en notificaciones del modelo de identidad es al usar credenciales de federación en el escenario de token emitido. Para obtener más información sobre la federación y los tokens emitidos, consulte Federación y tokens emitidos.

Para obtener más información sobre el modelo de identidad, consulte Administración de notificaciones y autorización con el modelo de identidad.

Consulte también