Control de acceso basado en rol para desarrolladores de aplicaciones

  • Artículo

El control de acceso basado en roles (RBAC) permite que algunos usuarios o grupos tengan permisos específicos para acceder y administrar recursos. El control de acceso basado en roles de la aplicación difiere del control de acceso basado en roles de Azure y del control de acceso basado en roles de Microsoft Entra. Los roles personalizados de Azure y los roles integrados forman parte de RBAC de Azure, lo cual permite administrar los recursos de Azure. RBAC de Microsoft Entra se utiliza para administrar recursos de Microsoft Entra. En este artículo se explica el control de acceso basado en roles específico de la aplicación. Para más información sobre la implementación de RBAC específico de la aplicación, consulte Para ver más ejemplos e información, consulte Procedimientos para agregar roles de aplicación a una aplicación y recibirlos en el token.

Definiciones de roles

El control de acceso basado en roles (RBAC) es un mecanismo popular para exigir la autorización de las aplicaciones. Cuando una organización usa RBAC, un desarrollador de aplicaciones define roles en lugar de autorizar usuarios o grupos individuales. Después, un administrador puede asignar roles a diferentes usuarios y grupos para controlar la funcionalidad y el contenido al que tienen acceso.

RBAC permite al desarrollador de aplicaciones administrar los recursos y el uso que se hace de ellos. RBAC también permite al desarrollador de aplicaciones controlar a qué áreas de una aplicación pueden acceder los usuarios. Los administradores pueden controlar qué usuarios tienen acceso a una aplicación mediante la propiedad Asignación de usuarios requerida. Los desarrolladores deben tener en cuenta a los usuarios específicos dentro de la aplicación y qué pueden hacer dentro de esta.

Un desarrollador de aplicaciones crea primero una definición de roles en la sección de registro de la aplicación en el centro de administración de Microsoft Entra. La definición de roles incluye un valor que se devuelve para los usuarios que están asignados a ese rol. Después, un desarrollador puede usar este valor para implementar la lógica de aplicación a fin de determinar lo que esos usuarios pueden o no pueden hacer en una aplicación.

Opciones para agregar RBAC

Debe seguir las instrucciones siguientes para incluir la autorización de control de acceso basado en roles en una aplicación:

  • Definir los roles necesarios para las necesidades de autorización de una aplicación.
  • Aplicar, almacenar y recuperar los roles pertinentes para los usuarios autenticados.
  • Determinar el comportamiento de la aplicación en función de los roles asignados al usuario actual.

Una vez definidos los roles, la Plataforma de identidad de Microsoft admite diferentes soluciones que se pueden usar con el fin de aplicar, almacenar y recuperar información de roles para los usuarios autenticados. Estas soluciones incluyen roles de aplicación, grupos de Microsoft Entra y el uso de almacenes de datos personalizados para la información de rol de usuario.

Los desarrolladores tienen la flexibilidad de proporcionar su propia implementación para saber cómo se interpretarán las asignaciones de roles como permisos de aplicación. Esta interpretación de los permisos puede implicar el uso de middleware u otras opciones proporcionadas por la plataforma de las aplicaciones o bibliotecas relacionadas. Las aplicaciones normalmente recibirán información del rol de usuario en forma notificaciones y decidirán los permisos de usuario en función de estas.

Roles de aplicación

Microsoft Entra ID permite definir roles de aplicación para la aplicación y asignar esos roles a usuarios y otras aplicaciones. Los roles que asigne a un usuario o aplicación definen su nivel de acceso a los recursos y operaciones de la aplicación.

Cuando Microsoft Entra ID emite un token de acceso para un usuario o aplicación autenticado, incluye los nombres de los roles que ha asignado a la entidad (el usuario o la aplicación) en la notificación roles del token de acceso. Una aplicación como una API web que recibe ese token de acceso en una solicitud puede tomar decisiones de autorización basadas en los valores de la notificación roles.

Grupos

Los desarrolladores también pueden utilizar grupos de Microsoft Entra para implementar el control de acceso basado en roles en sus aplicaciones, donde las pertenencias de los usuarios en grupos específicos se interpretan como pertenencias a roles. Cuando una organización usa grupos, el token incluye una notificación de grupos. La notificación de grupo especifica los identificadores de todos los grupos asignados al usuario dentro del inquilino.

Importante

Al trabajar con grupos, los desarrolladores deben ser conscientes del concepto de una notificación de uso por encima del límite. De manera predeterminada, si un usuario es miembro de más grupos que el máximo de uso por encima del límite (150 para los tokens SAML, 200 para los tokens JWT y 6 si se usa el flujo implícito), Microsoft Entra ID no emitirá una notificación de grupos en el token. En su lugar, incluirá una "notificación de uso por encima del límite" en el token que indica que el consumidor del token tendrá que consultar la API de Microsoft Graph para recuperar las pertenencias a grupos del usuario. Para obtener más información sobre cómo trabajar con notificaciones de uso por encima del límite, vea Notificaciones en tokens de acceso. Es posible emitir únicamente grupos asignados a una aplicación, aunque la asignación basada en grupos necesita la edición Microsoft Entra ID P1 o P2.

Almacén de datos personalizado

Tanto los roles como los grupos de aplicaciones almacenan información sobre las asignaciones de usuario en el directorio de Microsoft Entra. Otra opción a fin de administrar la información de rol de usuario que está disponible para los desarrolladores es mantener la información fuera del directorio, en un almacén de datos personalizado. Por ejemplo, en una base de datos SQL, en Azure Table Storage o en Azure Cosmos DB for Table.

Usar el almacenamiento personalizado permite a los desarrolladores una personalización y un control adicionales sobre cómo asignar roles a los usuarios y cómo representarlos. Pero una mayor flexibilidad también conlleva más responsabilidad. Por ejemplo, actualmente no hay ningún mecanismo disponible para incluir esta información en los tokens devueltos desde Microsoft Entra ID. Las aplicaciones deben recuperar los roles si la información del rol se mantiene en un almacén de datos personalizado. Por lo general, esto se hace mediante puntos de extensibilidad definidos en el middleware disponible para la plataforma que se usa, con el fin de desarrollar la aplicación. Además, los desarrolladores tienen la responsabilidad de proteger correctamente el almacén de datos personalizado.

Con directivas personalizadas de Azure AD B2C es posible interactuar con almacenes de datos personalizados e incluir notificaciones personalizadas en un token.

Elegir un método

En general, los roles de aplicación son la solución recomendada. Los roles de aplicación proporcionan el modelo de programación más sencillo y están hechos a propósito para implementaciones de RBAC, Aún así, algunos requisitos específicos referentes a la aplicación pueden indicar que un enfoque distinto sería una solución mejor.

Los desarrolladores pueden usar los roles de aplicación con el fin de controlar si un usuario puede iniciar sesión en una aplicación o si una aplicación puede obtener un token de acceso para una API web. Los desarrolladores prefieren los roles de aplicación más que los grupos de Microsoft Entra cuando quieren describir y controlar los parámetros de autorización en sus propias aplicaciones. Por ejemplo, una aplicación que use grupos para la autorización se interrumpirá en el siguiente inquilino, ya que el identificador y el nombre del grupo pueden ser distintos. Una aplicación que use roles de aplicación seguirá siendo segura.

Aunque se pueden usar roles de aplicación o grupos para la autorización, las diferencias clave entre ellos pueden influir en cuál es la mejor solución para un escenario determinado.

Roles de aplicación Grupos de Microsoft Entra Almacén de datos personalizado
Modelo de programación La más sencilla. Son específicos de una aplicación y se definen en el registro de la aplicación. Se mueven con la aplicación. Más compleja. Los id. de grupo varían entre inquilinos y es posible que haya que tener en cuenta las notificaciones de uso por encima del límite. Los grupos no son específicos de una aplicación, sino de un inquilino de Microsoft Entra. La más compleja. Los desarrolladores deben implementar los medios por los que la información de rol se almacena y recupera.
Los valores de rol son estáticos entre inquilinos de Microsoft Entra Sí No Depende de la implementación.
Los valores de rol se pueden usar en varias aplicaciones No (a menos que la configuración del rol se duplique en cada registro de aplicación). Sí Sí
Información almacenada en el directorio Sí Sí No
La información se entrega mediante tokens Sí (notificación de roles). Sí (en el caso de un uso por encima del límite, es posible que sea necesario recuperar las notificaciones de grupos en tiempo de ejecución) No. Se recupera en tiempo de ejecución mediante código personalizado.
Duración Reside en el registro de aplicación del directorio. Se quita cuando se elimina el registro de aplicación. Reside en el directorio. Permanecen intactos incluso si se quita el registro de aplicación. Reside en el almacén de datos personalizado. No está vinculado al registro de aplicación.

Pasos siguientes