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, como reclamaciones en un token, de los grupos de seguridad asignados a un usuario, los roles de directorio de Microsoft Entra y los grupos de distribución. Puede usar este enfoque para impulsar la autorización en las aplicaciones. Sin embargo, Microsoft Entra ID limita el soporte de grupos en un token debido al tamaño del mismo. 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 con el soporte de 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 grupo del token es actual solo cuando recibe el token. Las afirmaciones de grupo apoyan dos patrones principales.

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

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

"aud": "00001111-aaaa-2222-bbbb-3333cccc4444", 
"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": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

La matriz de afirmaciones groups consta de los identificadores de los grupos de los que este usuario es miembro. La matriz wids consta de 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 el desarrollador de aplicaciones y el 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 afirmaciones y 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. Hay límites de tamaño en los tokens y en las reclamaciones groups para que no se vuelvan 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 para grupos en una reclamación de 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 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 de SAML son mayores que los tokens de OAuth2 y OpenID Connect. Si usa el flujo implícito, el límite es 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.

Se supone que la reclamación de groups se debe asignar a src1. En teoría, si buscara la notificación _claim_sources, encontraría el miembro src1. Desde allí, encontrarías la consulta de Graph de la que te valdrías para obtener la pertenencia al grupo. Pero hay un problema con lo que se muestra en la consulta de Graph de ejemplo. Va a Azure AD Graph (que Microsoft está obsoletando), por lo tanto, no lo 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 una notificación _claim_names con un miembro identificado por groups en 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 para el usuario. Consulte Enumerar las pertenencias de un usuario (directa y transitiva) para buscar todos los grupos, tanto directos como transitivos, de los que el usuario es miembro.

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.

Cuando seleccionas Grupos asignados a la aplicación, un grupo se incluye en la reclamación groups si se cumplen las siguientes condiciones:

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

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

Grupos y roles de aplicaciones

Otra manera de evitar el problema de excedente de grupo es que la aplicación defina roles de aplicación que permitan definir a usuarios y grupos como tipos de miembros. Tal y como se muestra en la siguiente pantalla de Registros de aplicaciones | Roles de aplicación | Crear rol de aplicación, seleccione Usuarios/Grupos para Tipos de miembro permitidos.

Una vez creado el rol de aplicación en el registrode la aplicación, los profesionales de TI pueden asignar usuarios y grupos al rol. La aplicación recibe una reclamación roles en su token (token de ID para la aplicación, token de acceso para las API) con todos los roles asignados al usuario que ha iniciado sesión, como se muestra en el siguiente ejemplo de token.

"aud": "11112222-bbbb-3333-cccc-4444dddd5555",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "ccccdddd-2222-eeee-3333-ffff4444aaaa",

Recuerde que su aplicación debe manejar las siguientes condiciones:

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

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ía el rol de administrador. Al definir un rol base (como 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.

Verifica y utiliza los roles en tu 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 del control de acceso basado en rol en aplicaciones 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.
• Configurar reclamaciones 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 dentro de las aplicaciones.
• Procedimientos recomendados de seguridad para las propiedades de la aplicación describe el URI de redireccionamiento, los tokens de acceso (que se usan para flujos implícitos), los certificados y los secretos, el URI del identificador de aplicación y la propiedad de la aplicación.
• ámbitos, permisos, 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 confiables.
• 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.