Exportar (0) Imprimir
Expandir todo

Autorización en servicios y aplicaciones web para notificaciones

Publicada: abril de 2011

Actualizado: mayo de 2011

Se aplica a: Windows Azure

Se aplica a

  • Microsoft® Windows Azure™ AppFabric Access Control Service (ACS)

  • Windows® Identity Foundation (WIF)

  • ASP.NET

  • Windows Communication Foundation (WCF)

Resumen

En una aplicación de usuario de confianza, la autorización determina a qué recursos puede obtener acceso una identidad autenticada y qué operaciones puede realizar en estos recursos. Una autorización inapropiada o débil puede causar la divulgación de información o la alteración de los datos. En este tema se muestran los enfoques disponibles para implementar la autorización para servicios y aplicaciones web de ASP.NET para notificaciones mediante ACS y WIF.

Objetivos

  • Enumerar los enfoques de autorización que usan notificaciones.

  • Mostrar el diseño de alto nivel de cada enfoque.

  • Indicar las ventajas e inconvenientes 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 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 en grupos de Active Directory. La comprobación se realiza llamando el 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 familiares basados en roles.

Las notificaciones también se pueden usar para habilitar más decisiones de autorización además 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 para 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 sirve 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, opcionalmente, del propio ACS, mediante el motor de reglas. Cuando la aplicación recibe el token con notificaciones, puede analizar el token, extraer las notificaciones relevantes y tomar decisiones de autorización mediante un enfoque RBAC o basado en notificaciones. WIF se usa para analizar el token y hacerlo utilizable para las decisiones de autorización, mediante una interfaz de programación de aplicaciones (API) de uso simple. Para obtener más información acerca de WIF, vea WIF SDK (http://go.microsoft.com/fwlink/?LinkID=187481). Tenga en cuenta el siguiente diagrama al pensar sobre la autorización en servicios y aplicaciones para 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 aparecen en el token que el proveedor de identidades emite. 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

Control de acceso basado en roles

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 otorga el acceso; de lo contrario, el acceso se deniega.

Método IPrincipal.IsInRole

Para implementar el enfoque RBAC en aplicaciones para notificaciones, use el método IsInRole() de la interfaz IPrinicpal, tal y como se haría en las aplicaciones que no son para notificaciones. Existen varias maneras de usar el método IsInRole():

  • Llamando explícitamente IPrincipal.IsInRole(“Administrator”). En este enfoque, el resultado es un valor booleano. Úselo en las instrucciones condicionales. Se puede usar arbitrariamente en cualquier lugar del código.

  • Mediante la demanda de seguridad PrincipalPermission.Demand(). En este enfoque, el resultado es una excepción en el 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 booleano. Se puede usar en cualquier lugar del código.

  • Mediante los atributos declarativos [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]. Este enfoque se denomina declarativo, porque se usa para decorar métodos. No se puede usar en bloques de códigos dentro de las implementaciones de métodos. El resultado es una excepción en el caso de que no se satisfaga la demanda. Se debe comprobar que se ajusta a la estrategia de tratamiento de excepciones.

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

Expresión de roles como notificaciones

Cuando se llama el método IsInRole(), se comprueba si el usuario actual tiene ese rol. En las aplicaciones para 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 mediante el URI siguiente:

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

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

  • Mediante 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 generar 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, inspeccionando los tokens y transformándolos agregando, modificando o quitando notificaciones. Para obtener más información sobre cómo usar ClaimsAuthenticationManager para transformar notificaciones, vea Procedimiento: Implementar el control de acceso basado en roles RBAC) en una aplicación ASP.NET para notificaciones mediante WIF y ACS.

  • Asignando notificaciones arbitrarias al 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 ninguna codificación necesaria.

Control de acceso basado en notificaciones

CBAC es un enfoque de autorización en que la decisión de autorización para otorgar 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. Se usaba una notificación de tipo de rol 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 de entrada.

  3. La aplicación pasa las notificaciones al mecanismo de lógica de decisión. Puede ser un código en la memoria, una llamada a un servicio web, una consulta de la base de datos o puede implicar un motor de reglas sofisticado.

  4. El mecanismo de decisión calcula el resultado según las notificaciones.

  5. El acceso se otorga si el resultado es verdadero, y se deniega si el resultado es falso. Por ejemplo, la regla puede ser que el usuario tenga 21 o más años, que viva en el estado de Washington y que se haya autenticado mediante Windows Live® ID.

ACS sirve como un STS que emite tokens que transportan las notificaciones. Se puede controlar qué notificaciones se usan, los tipos de notificaciones y los valores, 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 clave para implementar CBAC en aplicaciones para notificaciones. ClaimsAuthorizationManager es un componente que se proporciona como parte de WIF. ClaimsAuthorizationManager permite interceptar las solicitudes de entrada e implementar cualquier lógica deseada para tomar las decisiones de autorización según las notificaciones de entrada. Este es también un punto de ampliación, en que las decisiones de autorización se pueden externalizar y desacoplar el código de aplicación. Esto es importante cuando se necesita 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án las probabilidades de errores en la 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, vea Procedimiento: Implementar la autorización de notificaciones en una aplicación ASP.NET para notificaciones mediante WIF y ACS.

Elementos relacionados

Vea también

Mostrar:
© 2014 Microsoft