Compartir a través de

Protección de aplicaciones de JBoss EAP de Java mediante roles y notificaciones de rol

  • Artículo

En este artículo se muestra una aplicación de JBoss EAP que usa OpenID Connect para iniciar sesión de usuarios y roles de aplicación de Microsoft Entra ID (roles de aplicación) para la autorización.

Esta aplicación implementa el control de acceso basado en roles (RBAC) mediante los roles de aplicación y la característica de notificaciones de rol de Microsoft Entra ID. Otro enfoque sería usar los grupos de Microsoft Entra ID y las notificaciones de grupo. Los grupos de Microsoft Entra ID y los roles de aplicación no son mutuamente excluyentes. Puede usarlos para proporcionar un control de acceso específico.

También puede usar RBAC con roles de aplicación y notificaciones de rol para aplicar directivas de autorización de forma segura.

Para ver un vídeo que trata este escenario y este ejemplo, consulte Implementación de la autorización en las aplicaciones mediante roles de aplicación, grupos de seguridad, ámbitos y roles de directorio.

Para obtener más información sobre cómo funcionan los protocolos en este y otros escenarios, consulte Autenticación frente a autorización.

Esta aplicación usa MSAL para Java (MSAL4J) para iniciar sesión de un usuario y obtener un token de identificador de Microsoft Entra ID.

En este ejemplo se usa primero MSAL para Java (MSAL4J) para iniciar sesión del usuario. En la página principal, muestra una opción para que el usuario vea las notificaciones en sus tokens de identificador. Esta aplicación también permite a los usuarios ver una página de administrador con privilegios o una página de usuario normal, según el rol de aplicación al que se les haya asignado. La idea es proporcionar un ejemplo de cómo, dentro de una aplicación, el acceso a determinadas funcionalidades o páginas está restringido a subconjuntos de usuarios en función del rol al que pertenecen.

Este tipo de autorización se implementa mediante RBAC. Con RBAC, un administrador concede permisos a roles y no a usuarios individuales o grupos. El administrador, a continuación, puede asignar roles a diferentes usuarios y grupos para controlar quién tiene acceso a qué contenido y funcionalidad.

Esta aplicación de ejemplo define los dos roles de aplicación siguientes:

  • PrivilegedAdmin: se autoriza a acceder a las páginas Solo administradores y Usuarios normales.
  • RegularUser: se autoriza a acceder a las páginas a Usuarios normales.

Estos roles de aplicación se definen en Azure Portal en el manifiesto de registro de la aplicación. Cuando un usuario inicia sesión en la aplicación, Microsoft Entra ID emite una notificación de roles para cada rol concedido individualmente al usuario en forma de pertenencia a roles.

Puede asignar usuarios y grupos a roles con Azure Portal.

Nota:

Las notificaciones de rol no están presentes para los usuarios invitados en un inquilino si el punto de conexión https://login.microsoftonline.com/common/ se usa como autoridad para iniciar sesión de los usuarios. Debe iniciar sesión de un usuario en un punto de conexión inquilino, como https://login.microsoftonline.com/tenantid.

Requisitos previos

Recomendaciones

Configuración del ejemplo

En las secciones siguientes se muestra cómo configurar la aplicación de ejemplo.

Clonación o descarga del repositorio de ejemplo

Para clonar el ejemplo, abra una ventana de Bash y use el siguiente comando:

git clone https://github.com/Azure-Samples/ms-identity-msal-java-samples.git
cd 3-java-servlet-web-app/3-Authorization-II/roles

Como alternativa, vaya al repositorio ms-identity-msal-java-samples y, a continuación, descárguelo como un archivo .zip y extráigalo en el disco duro.

Importante

Para evitar las limitaciones de longitud de la ruta de los archivos en Windows, clone o extraiga el repositorio en un directorio cerca de la raíz del disco duro.

Registro de la aplicación de ejemplo con el inquilino de Microsoft Entra ID

En este ejemplo hay un proyecto. En las secciones siguientes se muestra cómo registrar la aplicación mediante Azure Portal.

Selección del inquilino de Microsoft Entra ID el que quiere crear las aplicaciones

Para elegir el inquilino, siga estos pasos:

  1. Inicie sesión en Azure Portal.

  2. Si su cuenta existe en más de un inquilino de Microsoft Entra ID, seleccione el perfil en la esquina de Azure Portal y seleccione Cambiar directorio para modificar la sesión al inquilino de Microsoft Entra ID que desee.

Registro de la aplicación (java-servlet-webapp-roles)

En primer lugar, registre una nueva aplicación en Azure Portal siguiendo las instrucciones de Inicio rápido: Registro de una aplicación en la plataforma de identidades de Microsoft.

A continuación, siga estos pasos para completar el registro:

  1. Vaya a la página de Registros de aplicaciones de la plataforma de identidad de Microsoft para desarrolladores.

  2. Seleccione Nuevo registro.

  3. En la página Registrar una aplicación que aparece, escriba la siguiente información de registro de la aplicación:

    • En la sección Nombre, escriba un nombre significativo de la aplicación, que se mostrará a los usuarios de la aplicación, por ejemplo, java-servlet-webapp-roles.

    • En Tipos de cuenta admitidos, seleccione una de las siguientes opciones:

      • Seleccione Solo las cuentas de este directorio organizativo si va a crear una aplicación para que solo la utilicen los usuarios de su inquilino, es decir, una aplicación de inquilino.

    • En la sección URI de redirección, seleccione Web en el cuadro combinado y escriba los siguientes URI de redirección: http://localhost:8080/msal4j-servlet-roles/auth/redirect.

  4. Seleccione Registrar para crear la aplicación.

  5. En la página de registro de la aplicación, busque y copie el valor del identificador de la aplicación (cliente) para usarlo más adelante. Este valor se usa en el archivo o los archivos de configuración de la aplicación.

  6. Seleccione Guardar para guardar los cambios.

  7. En la página de registro de la aplicación, seleccione Certificados y secretos en el panel de navegación para abrir la página donde puede generar secretos y cargar certificados.

  8. En la sección Secretos de cliente, seleccione Nuevo secreto de cliente.

  9. Escriba una descripción, por ejemplo, secreto de aplicación.

  10. Seleccione una de las duraciones disponibles: En 1 año, En 2 años o No caduca nunca.

  11. Seleccione Agregar. Se muestra el valor generado.

  12. Copie y guarde el valor generado para usarlo en pasos posteriores. Necesita este valor para los archivos de configuración del código. Este valor no volverá a aparecer y no podrá recuperarlo por ningún otro medio. Por lo tanto, asegúrese de guardarlo desde Azure Portal antes de navegar a cualquier otra pantalla o panel.

Definición de los roles de la aplicación

Use los pasos siguientes para definir los roles de la aplicación:

  1. Todavía en el mismo registro de aplicaciones, seleccione Roles de aplicación en el panel de navegación.

  2. Seleccione Crear rol de aplicación y, a continuación, escriba los valores siguientes:

    • En Nombre para mostrar, escriba un nombre adecuado; por ejemplo, PrivilegedAdmin.
    • En Tipos de miembros permitidos, elija Usuario.
    • En Valor, escriba PrivilegedAdmin.
    • En Descripción, escriba PrivilegedAdmins quién puede ver la página de administración.

  3. Seleccione Crear rol de aplicación y, a continuación, escriba los valores siguientes:

    • En Nombre para mostrar, escriba un nombre adecuado; por ejemplo, RegularUser.
    • En Tipos de miembros permitidos, elija Usuario.
    • En Valor, escriba RegularUser.
    • En Descripción, escriba RegularUsers que pueden ver la página de usuario.

  4. Seleccione Aplicar para guardar los cambios.

Asignación de usuarios a roles de aplicación

Para agregar usuarios al rol de aplicación definido anteriormente, siga las instrucciones que se indican aquí: Asignación de usuarios y grupos a roles.

Configuración de la aplicación (java-servlet-webapp-roles) para usar el registro de la aplicación

Siga estos pasos para configurar la aplicación:

Nota:

En los pasos siguientes, ClientID es igual que Application ID o AppId.

  1. Abra el proyecto en su IDE.

  2. Abra el archivo authentication.properties.

  3. Busque la cadena {enter-your-tenant-id-here}. Reemplace el valor existente por el identificador de inquilino de Microsoft Entra ID.

  4. Busque la cadena {enter-your-client-id-here} y reemplace el valor existente por el identificador de aplicación o clientId de la aplicación java-servlet-webapp-call-graph que ha copiado de Azure Portal.

  5. Busque la cadena {enter-your-client-secret-here} y reemplace el valor existente por el valor que ha guardado durante la creación de la aplicación java-servlet-webapp-roles en Azure Portal.

  6. Busque la propiedad app.roles y asegúrese de que el valor esté establecido en app.roles=admin PrivilegedAdmin, user RegularUser o sustituya los nombres de sus roles específicos.

Compilación del ejemplo

Para crear el ejemplo mediante Maven, vaya al directorio que contiene el archivo pom.xml del ejemplo y, a continuación, ejecute el siguiente comando:

mvn clean package

Este comando genera un archivo .war que se puede ejecutar en varios servidores de aplicaciones.

Ejecución del ejemplo

En las secciones siguientes se indica cómo implementar el ejemplo en Azure App Service.

Requisitos previos

Configuración del complemento Maven

El proceso de implementación en Azure App Service usa sus credenciales de Azure desde la CLI de Azure automáticamente. El complemento Maven se autentica con OAuth o el inicio de sesión del dispositivo si la CLI de Azure no está instalada localmente. Para más información, consulte Autenticación con los complementos de Maven.

Use los pasos siguientes para configurar el complemento:

  1. Ejecute el siguiente comando de Maven para configurar la implementación. Este comando le ayuda a configurar el sistema operativo de App Service, la versión de Java y la versión de Tomcat.

    mvn com.microsoft.azure:azure-webapp-maven-plugin:2.12.0:config

  2. En Crear nueva configuración de ejecución, pulse Y y, a continuación, pulse Intro.

  3. En Definir valor para el sistema operativo, pulse 2 para Linux y, a continuación, pulse Intro.

  4. En Definir valor para javaVersion, pulse 2 para Java 11 y, a continuación, pulse Intro.

  5. En Definir valor para webContainer, pulse 1 para JBosseap7 y, a continuación, pulse Entrar.

  6. En Definir valor para pricingTier, pulse Entrar para seleccionar el nivel P1v3 predeterminado.

  7. En Confirmar, pulse Y y, a continuación, pulse Entrar.

En el ejemplo siguiente se ve el resultado del proceso de implementación:

Please confirm webapp properties
AppName : msal4j-servlet-auth-1707220080695
ResourceGroup : msal4j-servlet-auth-1707220080695-rg
Region : centralus
PricingTier : P1v3
OS : Linux
Java Version: Java 11
Web server stack: JBosseap 7
Deploy to slot : false
Confirm (Y/N) [Y]:
[INFO] Saving configuration to pom.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  26.196 s
[INFO] Finished at: 2024-02-06T11:48:16Z
[INFO] ------------------------------------------------------------------------

Una vez que haya confirmado las opciones, el complemento agregará la configuración del complemento y los ajustes necesarios del archivo pom.xml del proyecto para configurar la aplicación web para que se ejecute en Azure App Service.

La parte correspondiente del archivo pom.xml debe ser similar al ejemplo siguiente:

<build>
    <plugins>
        <plugin>
            <groupId>com.microsoft.azure</groupId>
            <artifactId>>azure-webapp-maven-plugin</artifactId>
            <version>x.xx.x</version>
            <configuration>
                <schemaVersion>v2</schemaVersion>
                <resourceGroup>your-resourcegroup-name</resourceGroup>
                <appName>your-app-name</appName>
            ...
            </configuration>
        </plugin>
    </plugins>
</build>

Las configuraciones de App Service se pueden modificar directamente en el archivo pom.xml. Algunas configuraciones comunes se enumeran en la tabla siguiente:

Propiedad Obligatorio Descripción Versión
schemaVersion false Versión del esquema de configuración. Los valores admitidos son v1 y v2. 1.5.2
subscriptionId false Identificador de la suscripción. 0.1.0+
resourceGroup true El grupo de recursos de Azure para la aplicación. 0.1.0+
appName true Nombre de la aplicación. 0.1.0+
region false Región en la que se va a hospedar la aplicación. El valor predeterminado es centralus. Para conocer las regiones válidas, consulte Regiones admitidas. 0.1.0+
pricingTier false El plan de tarifa de la aplicación. El valor predeterminado es Pv12 para una carga de trabajo de producción. El valor mínimo recomendado para desarrollo y pruebas de Java es B2. Para más información, consulte Precios de App Service 0.1.0+
runtime false Configuración del entorno en runtime. Para obtener más información, consulte Detalles de configuración. 0.1.0+
deployment false Configuración de implementación. Para obtener más información, consulte Detalles de configuración. 0.1.0+

Para obtener la lista completa de configuraciones, consulte la documentación de referencia del complemento. Todos los complementos de Azure Maven comparten un conjunto común de configuraciones. Para ver estas configuraciones, consulte Configuraciones comunes. Para conocer las configuraciones específicas de Azure App Service, consulte Aplicación de Azure: Detalles de configuración.

Asegúrese guardar los valores appName y resourceGroup para usarlos más adelante.

Preparar la aplicación para la implementación

Al implementar la aplicación en App Service, la dirección URL de redireccionamiento cambia a la dirección URL de redireccionamiento de la instancia de aplicación implementada. Siga estos pasos para cambiar esta configuración en el archivo de propiedades:

  1. Acceda al archivo authentication.properties de la aplicación y cambie el valor de app.homePage por el nombre de dominio de la aplicación implementada, tal como se muestra en el ejemplo siguiente. Por ejemplo, si eligió example-domain para el nombre de la aplicación en el paso anterior, ahora debe usar https://example-domain.azurewebsites.net para el valor app.homePage. Asegúrese de que también ha cambiado el protocolo de http a https.

    # app.homePage is by default set to dev server address and app context path on the server
# for apps deployed to azure, use https://your-sub-domain.azurewebsites.net
app.homePage=https://<your-app-name>.azurewebsites.net

  2. Después de guardar este archivo, use el siguiente comando para volver a compilar la aplicación:

    mvn clean package

Importante

En este mismo archivo authentication.properties, tiene una configuración para aad.secret. No es recomendable implementar este valor en App Service. Tampoco es un procedimiento recomendado dejar este valor en el código y potencialmente insertarlo en el repositorio de Git. Para quitar este valor de secreto del código, puede encontrar instrucciones más detalladas en la sección Implementación en App Service - Quitar secreto. En esta guía se agregan pasos adicionales para insertar el valor del secreto en Key Vault y usar referencias de Key Vault.

Actualizar el registro de la aplicación de Microsoft Entra ID

Como el URI de redireccionamiento cambia en la aplicación implementada en Azure App Service, también debe cambiar el URI de redireccionamiento en el registro de la aplicación de Microsoft Entra ID. Para realizar este cambio, siga estos pasos:

  1. Vaya a la página de Registros de aplicaciones de la plataforma de identidad de Microsoft para desarrolladores.

  2. Use el recuadro de búsqueda para buscar el registro de la aplicación; por ejemplo, java-servlet-webapp-authentication.

  3. Para abrir el registro de la aplicación, seleccione el nombre.

  4. Seleccione Autenticar desde el menú.

  5. En la sección Web - URIs de redireccionamiento, seleccione Agregar URI.

  6. Rellene el URI de la aplicación, anexando /auth/redirect; por ejemplo, https://<your-app-name>.azurewebsites.net/auth/redirect.

  7. Seleccione Guardar.

Implementar la aplicación

Ya estamos listos para implementar la aplicación en Azure App Service. Use el comando siguiente para asegurarse de que ha iniciado sesión en el entorno de Azure para ejecutar la implementación:

az login

Con toda la configuración lista en el archivo pom.xml, ahora puede usar el comando siguiente para implementar la aplicación de Java en Azure:

mvn package azure-webapp:deploy

Una vez finalizada la implementación, la aplicación está lista en http://<your-app-name>.azurewebsites.net/. Abra la dirección URL con el explorador web local, donde debería ver la página de inicio de la aplicación msal4j-servlet-auth.

Exploración del ejemplo

Siga estos pasos para explorar el ejemplo:

  1. Observe que el estado de inicio de sesión o de cierre de sesión se muestra en el centro de la pantalla.
  2. Seleccione el botón contextual en la esquina. Este botón indica Iniciar sesión cuando se ejecuta por primera vez la aplicación.
  3. En la página siguiente, siga las instrucciones e inicie sesión con una cuenta en el inquilino de Microsoft Entra ID.
  4. En la pantalla de consentimiento, observe los ámbitos que se solicitan.
  5. Observe que el botón contextual ahora indica Cerrar sesión y muestra el nombre de usuario.
  6. Seleccione Detalles del token de identificador para ver algunas de las notificaciones descodificadas del token de identificador.
  7. Seleccione Solo administradores para ver la página /admin_only. Solo los usuarios con el rol de aplicación PrivilegedAdmin pueden ver esta página. De lo contrario, se muestra un mensaje de error de autorización.
  8. Seleccione Usuarios normales para ver la página /regular_user. Solo los usuarios con el rol de aplicación RegularUser o PrivilegedAdmin pueden ver esta página. De lo contrario, se muestra un mensaje de error de autorización.
  9. Use el botón de la esquina para cerrar la sesión.

Sobre el código

En este ejemplo se usa MSAL para Java (MSAL4J) para iniciar sesión de un usuario y obtener un token de identificador que pueda contener la notificación de roles. En función de la notificación de roles presente, el usuario que ha iniciado sesión puede acceder a ninguna, una o ambas páginas protegidas, Admins Only y Regular Users.

Si desea replicar el comportamiento de este ejemplo, puede copiar el archivo pom.xml y el contenido de las carpetas helpers y authservlets en la carpeta src/main/java/com/microsoft/azuresamples/msal4j. También necesita el archivo authentication.properties. Estas clases y archivos contienen código genérico que puede usar en una amplia gama de aplicaciones. También puede copiar el resto del ejemplo, pero las demás clases y archivos se compilan específicamente para abordar el objetivo de este ejemplo.

Contenido

En la tabla siguiente se muestra el contenido de la carpeta del proyecto de ejemplo:

Archivo/carpeta Descripción
src/main/java/com/microsoft/azuresamples/msal4j/roles/ Este directorio contiene las clases que definen la lógica empresarial de back-end de la aplicación.
src/main/java/com/microsoft/azuresamples/msal4j/authservlets/ Este directorio contiene las clases que se usan para los puntos de conexión de inicio de sesión y cierre de sesión.
____Servlet.java Todos los puntos de conexión disponibles se definen en clases .java que terminan en ____Servlet.java.
src/main/java/com/microsoft/azuresamples/msal4j/helpers/ Clases auxiliares para la autenticación.
AuthenticationFilter.java Redirige las solicitudes no autenticadas a los puntos de conexión protegidos a una página 401.
src/main/resources/authentication.properties Microsoft Entra ID y configuración del programa.
src/main/webapp/ Este directorio contiene la interfaz de usuario: plantillas de JSP
CHANGELOG.md Lista de cambios en la muestra.
CONTRIBUTING.md Directrices para contribuir al ejemplo.
LICENCIA Licencia del ejemplo.

Procesamiento de una notificación de roles en el token de identificador

La notificación de roles del token incluye los nombres de los roles a los que está asignado el usuario que ha iniciado sesión, como se muestra en el ejemplo siguiente:

{
  ...
  "roles": [
    "Role1",
    "Role2",]
  ...
}

ConfidentialClientApplication

Se crea una instancia de ConfidentialClientApplication en el archivo AuthHelper.java, como se muestra en el ejemplo siguiente. Este objeto ayuda a crear la dirección URL de autorización de Microsoft Entra y también ayuda a intercambiar el token de autenticación de un token de acceso.

// getConfidentialClientInstance method
IClientSecret secret = ClientCredentialFactory.createFromSecret(SECRET);
confClientInstance = ConfidentialClientApplication
                     .builder(CLIENT_ID, secret)
                     .authority(AUTHORITY)
                     .build();

Para la instanciación se utilizan los siguientes parámetros:

  • El identificador de cliente de la aplicación.
  • El secreto de cliente, que es un requisito para aplicaciones cliente confidenciales.
  • Microsoft Entra ID Authority, que incluye el identificador de inquilino de Microsoft Entra.

En este ejemplo, estos valores se leen del archivo authentication.properties mediante un lector de propiedades del archivo Config.java.

Tutorial paso a paso

Los pasos siguientes proporcionan un tutorial de la funcionalidad de la aplicación:

  1. El primer paso del proceso de inicio de sesión consiste en enviar una solicitud al punto de conexión /authorize del inquilino de Microsoft Entra ID. La instancia ConfidentialClientApplication de MSAL4J se usa para construir una dirección URL de solicitud de autorización. La aplicación redirige el explorador a esta dirección URL, que es donde el usuario inicia sesión.

    final ConfidentialClientApplication client = getConfidentialClientInstance();
AuthorizationRequestUrlParameters parameters = AuthorizationRequestUrlParameters.builder(Config.REDIRECT_URI, Collections.singleton(Config.SCOPES))
        .responseMode(ResponseMode.QUERY).prompt(Prompt.SELECT_ACCOUNT).state(state).nonce(nonce).build();

final String authorizeUrl = client.getAuthorizationRequestUrl(parameters).toString();
contextAdapter.redirectUser(authorizeUrl);

    En la lista siguiente se describen las características de este código:

    • AuthorizationRequestUrlParameters: parámetros que se deben establecer para crear una instancia de AuthorizationRequestUrl.
    • REDIRECT_URI: donde Microsoft Entra ID redirige el navegador, junto con el código de autenticación, después de recopilar las credenciales de usuario. Debe coincidir con el URI de redireccionamiento en el registro de la aplicación Microsoft Entra ID en Azure Portal.
    • SCOPES: Los ámbitos son permisos solicitados por la aplicación.
      • Normalmente, los tres ámbitos openid profile offline_access son suficientes para recibir una respuesta de token de identificador.
      • La lista completa de ámbitos solicitados por la aplicación se puede encontrar en el archivo authentication.properties. Puede agregar más ámbitos, como User.Read.

  2. Microsoft Entra ID presenta al usuario un mensaje de inicio de sesión. Si el intento de inicio de sesión es correcto, el navegador del usuario se vuelve a redirigir al punto de conexión de redirección de la aplicación. Una solicitud válida a este punto de conexión contendrá un código de autorización.

  3. Después, la instancia de ConfidentialClientApplication intercambia este código de autorización por un token de identificador y un token de acceso de Microsoft Entra ID.

    // First, validate the state, then parse any error codes in response, then extract the authCode. Then:
// build the auth code params:
final AuthorizationCodeParameters authParams = AuthorizationCodeParameters
        .builder(authCode, new URI(Config.REDIRECT_URI)).scopes(Collections.singleton(Config.SCOPES)).build();

// Get a client instance and leverage it to acquire the token:
final ConfidentialClientApplication client = AuthHelper.getConfidentialClientInstance();
final IAuthenticationResult result = client.acquireToken(authParams).get();

    En la lista siguiente se describen las características de este código:

    • AuthorizationCodeParameters: parámetros que se deben establecer para intercambiar el código de autorización por un identificador o token de acceso.
    • authCode: el código de autorización que se ha recibido en el punto de conexión de redireccionamiento.
    • REDIRECT_URI: el URI de redireccionamiento que se ha usado en el paso anterior se debe pasar de nuevo.
    • SCOPES: los ámbitos que se han usado en el paso anterior se deben pasar de nuevo.

  4. Si acquireToken se realiza correctamente, se extraen las notificaciones de token. Si se supera la comprobación nonce, los resultados se colocan en context, una instancia de IdentityContextData, y se guardan en la sesión. Después, la aplicación puede crear una instancia de IdentityContextData a partir de la sesión por medio de una instancia de IdentityContextAdapterServlet siempre que necesite acceder a ella, como se muestra en el código siguiente:

    // parse IdToken claims from the IAuthenticationResult:
// (the next step - validateNonce - requires parsed claims)
context.setIdTokenClaims(result.idToken());

// if nonce is invalid, stop immediately! this could be a token replay!
// if validation fails, throws exception and cancels auth:
validateNonce(context);

// set user to authenticated:
context.setAuthResult(result, client.tokenCache().serialize());

Protección de las rutas

Para obtener información sobre cómo la aplicación de ejemplo filtra el acceso a las rutas, consulte AuthenticationFilter.java. En el archivo authentication.properties, la propiedad app.protect.authenticated contiene las rutas separadas por comas a las que solo pueden acceder los usuarios autenticados, como se muestra en el ejemplo siguiente:

# for example, /token_details requires any user to be signed in and does not require special roles claim(s)
app.protect.authenticated=/token_details

Cualquiera de las rutas enumeradas en los conjuntos de reglas separados por comas en app.protect.roles también están fuera de los límites de los usuarios autenticados no autenticados, como se muestra en el ejemplo siguiente. Sin embargo, estas rutas también contienen una lista separada por espacios de pertenencias a roles de aplicación: solo los usuarios que tienen al menos uno de los roles correspondientes pueden acceder a estas rutas después de la autenticación.

# local short names for app roles - for example, sets admin to mean PrivilegedAdmin (useful for long rule sets defined in the next key, app.protect.roles)
app.roles=admin PrivilegedAdmin, user RegularUser

# A route and its corresponding <space-separated> role(s) that can access it; the start of the next route & its role(s) is delimited by a <comma-and-space-separator>
# this says: /admins_only can be accessed by PrivilegedAdmin, /regular_user can be accessed by PrivilegedAdmin role and the RegularUser role
app.protect.roles=/admin_only admin, /regular_user admin user

Ámbitos

Los ámbitos indican a Microsoft Entra ID el nivel de acceso que solicita la aplicación.

En función de los ámbitos solicitados, Microsoft Entra ID presenta un cuadro de diálogo de consentimiento al usuario cuando inicia sesión. Si el usuario da su consentimiento para uno o varios ámbitos y obtiene un token, los ámbitos con consentimiento se codifican en el access_token resultante.

Para los ámbitos solicitados por la aplicación, consulte authentication.properties. MSAL solicita estos tres ámbitos y se proporcionan de forma predeterminada por Microsoft Entra ID.

Más información