Autorización en aplicaciones y servicios web compatibles con notificaciones
Actualizado: 19 de junio de 2015
Se aplica a: Azure
Se aplica a
Active Directory Access Control de Microsoft Azure (también conocido como Access Control Service o ACS)
Windows® Identity Foundation (WIF)
ASP.NET
Windows Communication Foundation (WCF)
Resumen
En una aplicación de usuario de confianza, la autorización determina los recursos a los que una identidad autenticada puede tener acceso y las operaciones que puede realizar en estos. Una autorización incorrecta o débil da lugar a la revelación de información y a la alteración de los datos. En este tema se describen los enfoques disponibles para implementar la autorización para aplicaciones y servicios web compatibles con notificaciones ASP.NET mediante ACS y WIF.
Objetivos
Enumerar los enfoques de autorización que usan notificaciones.
Detallar el diseño de alto nivel de cada enfoque.
Indicar las ventajas y las desventajas de cada enfoque.
Información general
Desde su primera versión, .NET Framework ha ofrecido un mecanismo flexible para implementar la autorización. Este mecanismo se basa en dos simples interfaces: IPrincipal e IIentity. Determinadas implementaciones de IIentity representan un usuario autenticado. Por ejemplo, la implementación de WindowsIdentity representa a un usuario autenticado por Active Directory y GenericIdentity representa a un usuario autenticado por una autenticación personalizada. Determinadas implementaciones de IPrincipal permiten comprobar los permisos mediante roles, según el almacén de roles. Por ejemplo, WindowsPrincipal comprueba la pertenencia a grupos de Active Directory de WindowsIdentity. Para realizar la comprobación, se llama al método IsInRole en la interfaz IPrincipal. La comprobación del acceso basada en roles se denomina control de acceso basado en roles (RBAC). El RBAC se explica en la sección “Control de acceso basado en roles” de este tema. Las notificaciones se pueden usar para proporcionar información sobre roles a fin de admitir mecanismos de autorización basados en roles.
Las notificaciones también se pueden usar para permitir mejores decisiones de autorización más allá de los roles. Las notificaciones pueden basarse en prácticamente cualquier cosa: edad, código postal, número de calzado, etc. La comprobación del acceso basada en notificaciones arbitrarias se denomina control de acceso basado en notificaciones (CBAC) o autorización basada en notificaciones. La autorización basada en notificaciones se explica en la sección “Control de acceso basado en notificaciones” de este tema.
Las comprobaciones de autorización se realizan en el lado de la aplicación, no en el lado de ACS. ACS actúa como servicio de token de seguridad (STS) que emite tokens que llevan las notificaciones a la aplicación. Los tokens se enriquecen con notificaciones por parte de los proveedores de identidades y, opcionalmente, por ACS, mediante su motor de reglas. Cuando la aplicación recibe el token con notificaciones, puede analizar el token, extraer las notificaciones pertinentes y tomar decisiones de autorización mediante un enfoque RBAC o basado en notificaciones. WIF se usa para analizar el token y para que se pueda usar para las decisiones de autorización, mediante una interfaz de programación de aplicaciones (API) fácil de usar. Para obtener más información sobre WIF, consulte el SDK de WIF (https://go.microsoft.com/fwlink/?LinkID=187481). Tenga en cuenta el siguiente diagrama al pensar en la autorización en servicios y aplicaciones compatibles con notificaciones. Tenga en cuenta que después de una autenticación correcta, el proveedor de identidades genera un token (el token IdP en el diagrama). El motor de reglas de ACS puede transformar el token de IdP. ACS puede agregar, quitar o cambiar las notificaciones que vienen en el token que emite el proveedor de identidades. Por último, el token emitido por ACS se envía a la aplicación y lo procesa WIF. La comprobación de acceso se realiza en WIF, mediante el enfoque RBAC o CBAC.
.gif "ACS v2 WIF Authorization")
Control de acceso basado en roles
El control de acceso basado en roles (RBAC) es un enfoque de autorización en el cual una aplicación basada en roles de usuario administra y aplica los permisos de usuario. Si un usuario tiene un rol necesario para realizar una acción, se concede el acceso; de lo contrario, se deniega.
Método IPrincipal.IsInRole
Para implementar el enfoque RBAC en aplicaciones compatibles con notificaciones, use el método IsInRole() de la interfaz IPrinicpal, tal como lo haría en las aplicaciones que no son compatibles con notificaciones. Existen varias maneras de usar el método IsInRole():
Llamado expresamente a IPrincipal.IsInRole(“Administrator”). En este enfoque, el resultado es un valor booleano. Úselo en las instrucciones condicionales. Se puede usar arbitrariamente en cualquier parte del código.
Usando la demanda de seguridad PrincipalPermission.Demand(). En este enfoque, se produce una excepción en caso de que la petición no se cumpla. Esta debe ajustarse a la estrategia de control de excepciones. Lanzar excepciones resulta mucho más caro, desde el punto de vista del rendimiento, que retirar un valor booleano. Se puede usar en cualquier parte del código.
Usando los atributos declarativos [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]. Este enfoque se denomina declarativo porque se usa para representar métodos. No se puede usar en bloques de código dentro de implementaciones de método. Se produce una excepción en caso de que no se cumpla la petición. Debe asegurarse de que se ajuste a la estrategia de control de excepciones.
Con la autorización de dirección URL, use la <sección de autorización> de web.config. Este enfoque es adecuado cuando se administra la autorización en un nivel de dirección URL. Es el nivel más amplio de todos los mencionados anteriormente. La ventaja de este enfoque es que los cambios se realizan en el archivo de configuración, lo que significa que el código no debe compilarse para beneficiarse del cambio.
Expresar roles como notificaciones
Cuando se llama al método IsInRole(), se realiza una comprobación para ver si el usuario actual tiene ese rol. En las aplicaciones para notificaciones, el rol se expresa mediante un tipo de notificación de rol que debe estar disponible en el token. El tipo de notificación de rol se expresa mediante el URI siguiente:
https://schemas.microsoft.com/ws/2008/06/identity/claims/role
Hay varias formas de enriquecer un token con un tipo de notificación de rol:
Con el motor de reglas de ACS: en este caso, se crea una regla mediante el Portal de administración de ACS o el Servicio de administración de ACS para crear reglas de transformación de notificaciones que generan notificaciones de un tipo de rol determinado. Para obtener más información sobre las reglas y la transformación de tokens, consulte Reglas y grupos de reglas y Cómo: Implementar lógica de transformación de tokens mediante reglas.
Transformando notificaciones arbitrarias en notificaciones de tipo de rol mediante ClaimsAuthenticationManager: el componente ClaimsAuthenticationManager es un componente que se proporciona como parte de WIF. Permite interceptar las solicitudes al iniciar una aplicación, inspeccionar tokens y transformarlos mediante la adición, cambio o eliminación de notificaciones. Para obtener más información sobre cómo usar ClaimsAuthenticationManager para transformar notificaciones, vea How to: Implement Role Based Access Control (RBAC) in a Claims-Aware ASP.NET Application Using WIF and ACS (Cómo: Implementar Access Control basado en roles (RBAC) en una aplicación ASP.NET compatible con notificaciones mediante WIF y ACS.
Asignando notificaciones arbitrarias a un tipo de rol mediante la sección de configuración samlSecurityTokenRequirement: un enfoque declarativo en el que la transformación de las notificaciones se realiza usando solo la configuración, sin que sea necesario ningún código.
Control de acceso basado en notificaciones
CBAC es un enfoque de autorización en el que la decisión de autorización para conceder o denegar el acceso se basa en una lógica arbitraria que usa los datos disponibles en las notificaciones para tomar la decisión. Recuerde que, en el caso del RBAC, la única notificación que se usaba era la de tipo de rol para comprobar si el usuario pertenecía o no a un rol concreto. Para ilustrar el proceso de toma de decisiones de autorización mediante un enfoque basado en notificaciones, tenga en cuenta los pasos siguientes:
La aplicación recibe una solicitud.
La aplicación extrae las notificaciones entrantes.
La aplicación pasa las notificaciones al mecanismo de lógica de decisión. Puede tratarse de un código en la memoria o de una llamada a un servicio web, una consulta a una base de datos o puede invocar un motor de reglas sofisticado.
El mecanismo de decisión calcula el resultado en función de las notificaciones.
El acceso se concede si el resultado es true y se deniega si es false. Por ejemplo, la regla podría ser que el usuario tiene una edad de 21 años o superior, reside en el estado de Washington y se autentica mediante Windows Live ID (cuenta Microsoft).
ACS actúa como STS que emite tokens que llevan las notificaciones. Puede controlar qué notificaciones se emiten (tanto los tipos de notificaciones como los valores) mediante el motor de reglas de ACS. Para obtener más información sobre el motor de reglas de ACS, consulte Reglas y grupos de reglas y Cómo: Implementar lógica de transformación de tokens mediante reglas. ClaimsAuthorizationManager es una clave para implementar CBAC en aplicaciones compatibles con notificaciones. ClaimsAuthorizationManager es un componente que se proporciona como parte de WIF. ClaimsAuthorizationManager permite interceptar solicitudes entrantes e implementar la lógica deseada para tomar decisiones de autorización en función de las notificaciones entrantes. Este es también un punto de ampliación, donde las decisiones de autorización se pueden externalizar y desacoplar del código de la aplicación. Esto es importante cuando es necesario cambiar la lógica de autorización. En ese caso, el uso de ClaimsAuthorizationManager no afectará a la integridad de la aplicación y se reducirá la probabilidad de un error de aplicación como resultado del cambio. Para obtener más información sobre cómo usar ClaimsAuthorizationManager para implementar el control de acceso basado en notificaciones, consulte How to: Implement Claims Authorization in a Claims-Aware ASP.NET Application Using WIF and ACS.