Esta documentación está archivada y no tiene mantenimiento.

Autorización en aplicaciones y servicios web compatibles con notificaciones

Publicada: abril de 2011

Actualizado: junio de 2015

Se aplica a: Azure

  • 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)

En una aplicación de usuario de confianza, la autorización determina a qué recursos puede acceder una identidad autenticada y qué operaciones puede realizar en estos recursos. Una autorización inapropiada o débil da lugar a la divulgació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 ASP.NET compatibles con notificaciones mediante ACS y WIF.

  • 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.

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 WindowsIdentity representa un usuario autenticado por Active Directory, y GenericIdentity representa un usuario autenticado mediante 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 de WindowsIdentity a grupos de Active Directory. Para realizar la comprobación, se llama al método IsInRole en la interfaz IPrincipal. La comprobación de 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. Se pueden usar notificaciones para transportar información sobre roles, para admitir mecanismos de autorización conocidos 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 funciona como servicio de token de seguridad (STS) que emite tokens que transportan las notificaciones a la aplicación. Los tokens se complementan con notificaciones de proveedores de identidades y, de manera opcional, del propio ACS, mediante el 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 acerca de WIF, vea el SDK de WIF (http://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 token IdP puede transformarse mediante el motor de reglas de ACS. ACS puede agregar, quitar o cambiar las notificaciones que vienen en el token que emite el proveedor de identidades. Finalmente, el token emitido por ACS se envía a la aplicación y se procesa mediante WIF. La comprobación de acceso se realiza en WIF, mediante el enfoque RBAC o CBAC.

Autorización WIF de ACS v2

RBAC es un enfoque de autorización en el que una aplicación administra y exige los permisos de usuario según los roles de usuario. Si un usuario tiene un rol necesario para realizar una acción, se concede el acceso; de lo contrario, se deniega el acceso.

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 de forma arbitraria en cualquier lugar del código.

  • Usando la demanda de seguridad PrincipalPermission.Demand(). En este enfoque, el resultado es una excepción en caso de que no se satisfaga la demanda. Esta debe ajustarse a la estrategia de tratamiento 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 lugar del código.

  • Usando los atributos declarativos [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]. Este enfoque se llama declarativo porque se usa para decorar métodos. No se puede usar en bloques de código dentro de las implementaciones de métodos. El resultado es una excepción en caso de que no se satisfaga la demanda. Asegúrese de que se ajuste a la estrategia de tratamiento de excepciones.

  • Mediante la autorización de direcciones URL, usando la sección <authorization> de web.config. Este enfoque es adecuado cuando administra la autorización a nivel de dirección URL. Este es el nivel más general entre los que se mencionaron anteriormente. La ventaja de este enfoque es que los cambios se realizan en el archivo de configuración, lo que hace que no se deba compilar el código para aprovechar el cambio.

Cuando se llama al método IsInRole(), se realiza una comprobación para ver si el usuario actual tiene ese rol. En las aplicaciones compatibles con notificaciones, el rol se expresa mediante un tipo de notificación de roles que debe estar disponible en el token. El tipo de notificación de roles se expresa en el URI siguiente:

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

Hay varias maneras de complementar un token con un tipo de notificación de roles:

  • Utilizando el motor de reglas de ACS: en este caso, 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 acerca de las reglas y la transformación de tokens, vea Grupos de reglas y reglas y Procedimiento: Implementar la 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 cuando inician una aplicación, mediante la inspección de los tokens y su transformación al agregar, modificar o quitar notificaciones. Para obtener más información acerca de cómo usar ClaimsAuthenticationManager para transformar notificaciones, vea Procedimiento: Implementar control de acceso basado en roles (RBAC) en una aplicación ASP.NET compatible con notificaciones usando 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.

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 de RBAC, la única notificación usada era la notificación de tipo de rol. Una notificación de tipo de rol se usa para comprobar si el usuario pertenece a un rol específico o no. Para ilustrar el proceso de toma de decisiones de autorización mediante el enfoque de autorización basado en notificaciones, tenga en cuenta los siguientes pasos:

  1. La aplicación recibe una solicitud.

  2. La aplicación extrae las notificaciones entrantes.

  3. La aplicación pasa las notificaciones al mecanismo de la lógica de toma de decisiones. 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.

  4. El mecanismo de toma de decisiones calcula el resultado según las notificaciones.

  5. El acceso se concede si el resultado es verdadero y se deniega si es falso. Por ejemplo, la regla puede establecer que el usuario es mayor de 21 años, vive en la comunidad autónoma de Cataluña y se autenticó mediante Windows Live ID (cuenta de Microsoft).

ACS funciona como STS que emite tokens que transportan las notificaciones. Puede controlar qué notificaciones se emiten, tanto los tipos de notificaciones como los tipos, mediante el motor de reglas de ACS. Para obtener más información acerca del motor de reglas de ACS, vea Grupos de reglas y reglas y Procedimiento: Implementar la 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 le permite interceptar solicitudes entrantes e implementar cualquier lógica que elija para tomar las decisiones de autorización según 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 se vuelve importante cuando se debe modificar la lógica de autorización. En ese caso, el uso de ClaimsAuthorizationManager no afectará la integridad de la aplicación, por lo que se reducirá la probabilidad de que se produzcan errores en la aplicación como consecuencia del cambio. Para obtener más información acerca de cómo usar ClaimsAuthorizationManager para implementar el control de acceso basado en notificaciones, vea Procedimiento: Implementación de autorización de notificaciones en aplicaciones ASP.Net compatible con notificaciones mediante WIF y ACS.

Vea también

Mostrar: