Configuración de notificaciones de grupo y roles de aplicación en tokens

Este artículo le ayuda a configurar las aplicaciones con definiciones de roles de aplicación y asignar grupos de seguridad a roles de aplicación para que pueda mejorar la flexibilidad y el control, al tiempo que aumenta la seguridad de las aplicaciones con privilegios mínimos.

Microsoft Entra ID admite el envío de grupos de seguridad asignados a un usuario, roles de directorio de Microsoft Entra y grupos de distribución como notificaciones en un token. Puede usar este enfoque para configurar la autorización en las aplicaciones. Sin embargo, el Microsoft Entra ID limita el soporte con grupos en un token por el tamaño del token. Cuando el usuario es miembro de demasiados grupos, no hay grupos en el token.

En este artículo, aprenderá un enfoque alternativo para obtener información de usuario en tokens mediante el soporte con grupos de Microsoft Entra. En su lugar, configure las aplicaciones con definiciones de roles de aplicación y asigne grupos a roles de aplicación. Este procedimiento recomendado para desarrolladores Confianza cero mejora la flexibilidad y el control, mientras que aumentar la seguridad de las aplicaciones con menos privilegios.

Puede configurar notificaciones de grupo en tokens que puede usar dentro de las aplicaciones para la autorización. Recuerde que la información de grupos del token solo está actualizada cuando recibe el token. Las notificaciones de grupo admiten dos patrones principales:

• Grupos identificados por su atributo de identificador de objeto (OID) de Microsoft Entra.
• Grupos identificados por los atributos sAMAccountName o GroupSID para usuarios y grupos sincronizados por Active Directory.

La pertenencia a grupos puede impulsar las decisiones de autorización. En el ejemplo siguiente se muestran algunas notificaciones en un token. Puede agregar notificaciones de grupo y roles a tokens de identificador o de acceso.

"aud": "e18c04b1-4868-4b93-93d1-8d71f17ab99b", 
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0", 
"iat": 1669657224, "nbf": 1669657224, "exp": 1669661124, 
"groups": [ 
   "0760b6cf-170e-4a14-91b3-4b78e0739963", 
   "3b2b0c93-acd8-4208-8eba-7a48db1cd4c0" 
 ],
"oid": "cb7eda1b-d09a-40ae-b8bb-37836ebc6abd",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "833ced3d-cb2e-41ce-92f1-29e2af035ddc", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

La matriz de notificaciones groups contiene los identificadores de los grupos de los que este usuario es miembro. La matriz wids incluye los identificadores de los roles de Microsoft Entra asignados a este usuario. Aquí, cf1c38e5-3621-4004-a7cb-879624dced7c muestra que los roles asignados de este usuario incluyen Desarrollador de aplicaciones y Miembro estándar, como indica 3b2b0c93-acd8-4208-8eba-7a48db1cd4c0.

La aplicación puede tomar decisiones de autorización en función de la presencia o ausencia de estas notificaciones y de sus valores. Consulte Roles integrados de Microsoft Entra para obtener una lista de los valores de la notificación wids.

Para agregar las notificaciones groups y wids a los tokens, seleccione Todos los grupos como se muestra en el ejemplo siguiente de la pantalla Registros de aplicaciones | Configuración de token | Notificaciones opcionales | Editar notificación de grupos.

Uso por encima del límite de grupos

Al solicitar todos los grupos del token como se muestra en el ejemplo anterior, no puede confiar en que el token contenga la notificación groups. Se aplican límites de tamaño a los tokens y las notificaciones groups para que no lleguen a ser demasiado grandes. Cuando el usuario es miembro de demasiados grupos, la aplicación debe obtener la pertenencia a grupos del usuario de Microsoft Graph. Los límites de grupos en una notificación groups son:

• 200 grupos para tokens web JSON (JWT).
• 150 grupos para tokens del Lenguaje de Marcado para Confirmaciones de Seguridad (SAML).
• Seis grupos al usar el flujo implícito (por ejemplo, mediante ASP.NET Core, que obtiene los tokens de identificador por medio de la parte de flujo implícito de un flujo híbrido).
  • El flujo implícito ya no se recomienda para aplicaciones web de página única.
  • El flujo implícito solo se puede usar en aplicaciones web para el token de identificador, nunca para el token de acceso, en un flujo híbrido de OAuth2.

Si usa OpenID Connect o OAuth2, puede tener hasta 200 grupos en el token. Si usa SAML, solo puede tener 150 grupos, porque los tokens SAML son mayores que los tokens de OAuth2 y OpenID Connect. Si usa el flujo implícito, el límite son seis porque esas respuestas aparecen en la dirección URL. En todos estos casos, en lugar de tener una notificación de groups, verá una indicación (conocida como uso por encima del límite del grupo) que le indica que el usuario es miembro de demasiados grupos para ajustarse al token.

En el ejemplo de token siguiente, para una conexión OpenID o OAuth2, token web JSON (JWT), no hay una notificación de groups si el usuario es miembro de demasiados grupos. En su lugar, hay una notificación _claim_names que contiene un miembro groups de la matriz.

En el ejemplo de token anterior, verá que la notificación groups parece estar asignada a src1. En teoría, si buscara la notificación _claim_sources, encontraría el miembro src1. Después, encontraría la consulta de Graph que usaría para obtener la pertenencia a grupos. Pero hay un problema con lo que se muestra en la consulta de Graph de ejemplo. Redirige a Azure AD Graph (que Microsoft dejará en desuso), así que no la use.

La indicación de uso por encima del límite del flujo implícito se realiza con una notificación hasgroups en lugar de una notificación groups.

Para garantizar una autorización adecuada mediante la pertenencia a grupos, haga que la aplicación compruebe la notificación groups. Si está presente, use esa notificación para determinar la pertenencia a grupos del usuario. Si no hay ninguna notificación groups, compruebe la existencia de una notificación hasgroups o _claim_names con un miembro groups de la matriz. Si alguna de estas notificaciones está presente, el usuario es miembro de demasiados grupos para el token. En este caso, la aplicación debe usar Microsoft Graph para determinar la pertenencia a grupos del usuario. Consulte Enumeración de las pertenencias de un usuario (directas y transitivas) para buscar todos los grupos, tanto directos como transitivos, de los que es miembro el usuario.

Si la aplicación requiere información de pertenencia a grupos en tiempo real, use Microsoft Graph para determinar la pertenencia a grupos. Recuerde que la información del token que recibe está actualizada solo en el momento en que adquiere el token.

Consulte el ejemplo siguiente de la pantalla Registros de aplicaciones | Configuración de token | Notificaciones opcionales | Editar notificación de grupos. Una manera de evitar recibir una notificación de uso por encima del límite de grupos es seleccionar Grupos asignados a la aplicación en la pantalla Editar notificación de grupos en lugar de Todos los grupos.

Al seleccionar Grupos asignados a la aplicación, se incluye un grupo en la notificación groups si se cumplen las condiciones siguientes:

• El grupo está asignado a la aplicación empresarial.
• El usuario es un miembro directo del grupo.

A partir de la publicación de este artículo, la opción Grupos asignados a la aplicación no admite la pertenencia indirecta. La asignación de grupos requiere al menos una licencia de nivel P1. Un inquilino gratuito no puede asignar grupos a una aplicación.

Grupos y roles de aplicación

Otra manera de evitar el problema de uso por encima del límite de grupos es que la aplicación defina roles de aplicación que permitan los usuarios y los grupos como tipos de miembro. Tal y como se muestra en la siguiente pantalla de Registros de aplicaciones | Roles de aplicación | Crear rol de aplicación, seleccione Usuarios o grupos para Tipos de miembro permitidos.

Después de crear el rol de aplicación en el registro de la aplicación, los profesionales de TI pueden asignar usuarios y grupos al rol. La aplicación obtiene una notificación de roles en el token (token de identificador para la aplicación, token de acceso para las API) con todos los roles asignados del usuario que ha iniciado sesión, tal como se muestra en el ejemplo de token siguiente.

"aud": "acaf6ce9-81f0-462a-a93d-a314070738d3",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "cb7eda1b-d09a-419e-b8bb-37836ebc6abd",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "833ced3d-cb3e-41de-92f1-29e2af035ddc",

Recuerde que la aplicación debe controlar las siguientes condiciones:

• Ausencia de notificación roles
• el usuario no tiene ninguna asignación de roles
• varios valores de la notificación roles cuando el usuario tiene más de una asignación de roles

Al crear roles de aplicación que permitan usuarios y grupos como miembros, defina siempre un rol de usuario de línea base sin roles de autorización elevados. Cuando una configuración de aplicaciones empresariales requiere asignación, solo los usuarios con asignación directa a una aplicación o pertenencia a un grupo asignado a la aplicación pueden usar la aplicación.

Si la aplicación tiene roles de aplicación definidos que permiten a los usuarios y grupos como miembros, cuando se asigna un usuario o grupo a la aplicación, uno de los roles de aplicación definidos debe formar parte de la asignación del usuario o grupo a la aplicación. Si la aplicación solo ha definido roles elevados (como admin) para la aplicación, a todos los usuarios y grupos se les asignará el rol de administrador. Al definir un rol base (por ejemplo, user), los usuarios y grupos asignados a la aplicación se pueden asignar al rol de usuario base.

Además de evitar las notificaciones de uso por encima del límite de grupo, no es necesario asignar otra ventaja de usar roles entre un identificador de grupo o un nombre y lo que significa en la aplicación. Por ejemplo, el código puede buscar la notificación de rol de administrador en lugar de recorrer en iteración los grupos de las notificaciones groups y decidir a qué identificadores de grupo debe permitirse la funcionalidad de administrador.

Comprobación y uso de roles en el código

Al definir roles de aplicación para la aplicación, es su responsabilidad implementar la lógica de autorización para esos roles. Consulte Implementación en aplicaciones del control de acceso basado en roles para obtener información sobre cómo puede implementar la lógica de autorización en las aplicaciones.

Pasos siguientes

• Personalizar tokens describe la información que puede recibir en tokens de Microsoft Entra. Explica cómo personalizar tokens para mejorar la flexibilidad y el control, al tiempo que aumenta la seguridad de confianza cero de la aplicación con privilegios mínimos.
• El artículo Configuración de notificaciones de grupo para aplicaciones mediante Microsoft Entra ID muestra cómo Microsoft Entra ID puede proporcionar información de pertenencia a grupos de un usuario en tokens para su uso en las aplicaciones.
• En el artículo Procedimientos recomendados de seguridad para las propiedades de la aplicación en Microsoft Entra ID se describen el URI de redireccionamiento, los tokens de acceso (usados para flujos implícitos), los certificados y los secretos, el identificador URI de la aplicación y la propiedad de la aplicación.
• Los ámbitos, permisos y consentimiento de la plataforma de identidad de Microsoft explica los conceptos fundamentales de acceso y autorización para ayudarle a crear aplicaciones más seguras y de confianza.
• Use los procedimientos recomendados de desarrollo para la administración de identidad y acceso de confianza cero en el ciclo de vida de desarrollo de las aplicaciones para crear aplicaciones seguras.