Compartir a través de

Desarrollo de la estrategia de permisos delegados

  • Artículo

Este artículo le ayuda, como desarrollador, a implementar el mejor enfoque para administrar permisos en la aplicación y desarrollar mediante principios de confianza cero. Como se describe en Adquirir autorización para acceder a los recursos, permisos delegados se usan con acceso delegado para permitir que una aplicación actúe en nombre de un usuario, accediendo solo a lo que el usuario puede acceder. Los permisos de aplicaciónse usan con el acceso directo para permitir a una aplicación acceder a todos los datos con los que está asociado el permiso. Solo los administradores y propietarios de las entidades de servicio pueden dar su consentimiento a los permisos de aplicación.

Los modelos de permisos y consentimiento hacen referencia principalmente a una aplicación. El proceso de permiso y consentimiento no tiene control sobre lo que un usuario puede hacer. Controla qué acciones puede realizar la aplicación.

Observe el siguiente diagrama de Venn. Con los permisos delegados, se produce una intersección entre lo que el usuario puede hacer y lo que la aplicación puede hacer. Esa intersección es el permiso en vigor al que está enlazada la aplicación. Cada vez que use un permiso delegado, los permisos efectivos lo enlazan.

El diagrama de Venn muestra permisos efectivos como intersección de permisos de aplicación y funcionalidades de usuario.

Por ejemplo, la aplicación que tiene usuarios delante obtiene permiso para actualizar el perfil de cada usuario en el inquilino. Eso no significa que cualquier persona que ejecute la aplicación pueda actualizar el perfil de cualquier otra persona. Si el administrador decide conceder la aplicación User.ReadWrite.All, significa que cree que la aplicación está haciendo lo correcto al actualizar cualquier perfil de usuario. La aplicación puede registrar los cambios y proteger correctamente la información. El administrador hace un juicio de valor sobre la aplicación, no sobre el usuario.

Enfoque de privilegios mínimos

Las API pueden resultar complejas. Es posible que las API simples no tengan muchas operaciones. Las API complejas, como Microsoft Graph, encapsulan muchas solicitudes que una aplicación podría querer usar. Solo porque la aplicación tenga derecho de lectura no significa que tenga derecho a actualizarse. Por ejemplo, Microsoft Graph tiene miles de API. Solo porque tenga permiso para leer el perfil del usuario, no significa que también deba tener permiso para eliminar todos sus archivos de OneDrive.

Como desarrollador, debe:

  • Saber a qué API llama la aplicación.
  • Comprender la documentación de la API y los permisos que requiere.
  • Usar el permiso mínimo para realizar las tareas.

Las API suelen proporcionar acceso a los almacenes de datos de la organización y atraer la atención de los atacantes que desean acceder a esos datos.

Evalúe los permisos que solicite para asegurarse de que busca el conjunto con privilegios mínimos absoluto para realizar el trabajo. Evite solicitar permisos de privilegios más elevados; en su lugar, trabaje cuidadosamente con el gran número de permisos que proporcionan las API como Microsoft Graph. Busque y use los permisos mínimos para satisfacer sus necesidades. Si no escribe código para actualizar el perfil del usuario, no lo solicita para la aplicación. Si solo accede a usuarios y grupos, no solicita acceso a otra información del directorio. No solicita permiso para administrar el correo electrónico de usuario si no escribe código que accede al correo electrónico del usuario.

En el desarrollo de aplicaciones de confianza cero:

  • Defina la intención de la aplicación y lo que necesita.
  • Asegúrese de que los actores malintencionados no puedan poner en peligro la aplicación y usarla de una manera imprevista.
  • Realice solicitudes de aprobación en las que defina sus requisitos (por ejemplo, leer el correo del usuario).

Las personas que pueden aprobar las solicitudes se dividen en dos categorías: administradores que siempre pueden dar su consentimiento a solicitudes de permisos y usuarios normales que no son administradores. Sin embargo, los administradores de inquilinos tienen la última palabra en su inquilino con respecto a qué permisos requieren consentimiento del administrador y a qué permisos puede dar su consentimiento un usuario.

Cuando un diseñador de API requiere el consentimiento del administrador para un permiso, ese permiso siempre requiere el consentimiento del administrador. Un administrador de inquilinos no puede invalidar eso y requerir solo el consentimiento del usuario.

Cuando un diseñador de API define permisos que requieren consentimiento del usuario, el administrador de inquilinos puede invalidar las sugerencias de consentimiento del usuario del diseñador de API. Los administradores de inquilinos pueden hacerlo con un "gran modificador" en el inquilino: todo requiere consentimiento del administrador. Los administradores de inquilinos pueden invalidar el consentimiento del usuario de forma más detallada mediante la administración de permisos y consentimiento. Por ejemplo, podrían permitir que los usuarios consienten las solicitudes de consentimiento del usuario de publicadores comprobados pero no de otros publicadores. En otro ejemplo, pueden permitir que User.Read inicien sesión en el usuario y lean su perfil, pero requieren el consentimiento del administrador para las aplicaciones que solicitan permiso para enviar correo o archivos.

Los diseñadores de API realizan sus sugerencias, pero los administradores de inquilinos tienen la última palabra. Por lo tanto, como desarrollador, no siempre sabes cuándo la aplicación requiere consentimiento del administrador. Es agradable planear y diseñar teniendo todo esto en cuenta, pero recuerde, cuando se envía una solicitud de token, esta se podría denegar por cualquier motivo. En el código, debe gestionar las situaciones en las que no se obtiene un token, porque los administradores de inquilinos en los que los clientes o usuarios ejecutan la aplicación deciden cuándo requieren los permisos el consentimiento del administrador.

Ejemplo de uso de MSAL de JavaScript

Para la autenticación de este ejemplo, se usa nuestra Biblioteca de autenticación de Microsoft (MSAL) de JavaScript para iniciar sesión en el usuario en una sola aplicación de página (SPA) donde se ejecuta toda la lógica de la aplicación desde el explorador.

En el artículo de inicio rápido relacionado, puede descargar y ejecutar un ejemplo de código. Muestra cómo una aplicación de página única de JavaScript puede iniciar la sesión de usuarios y llamar a Microsoft Graph API mediante el flujo de código de autorización con la clave de prueba para el intercambio de códigos (PKCE). En el ejemplo de código se muestra cómo obtener un token de acceso para llamar a Microsoft Graph API o a cualquier API web.

Como se muestra en el código de ejemplo siguiente, se crea una instancia de un cliente público porque una aplicación que se ejecuta completamente en el explorador debe ser un cliente público. Es decir, el usuario puede acceder a los elementos internos de la aplicación cuando el código está en el explorador.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

A continuación, use nuestra biblioteca MSAL. En MSAL JavaScript, hay una API específica para iniciar sesión. Hay dos API que usan funcionalidades específicas en el explorador. Una es iniciar sesión con una experiencia emergente; la otra consiste en iniciar sesión con una experiencia de redirección del explorador.

Como se muestra en el ejemplo de código siguiente, el elemento emergente de inicio de sesión controla la autenticación que el usuario debe realizar mediante una llamada a la función signIn.

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

La aplicación puede obtener información sobre el usuario, como su nombre para mostrar o el id. de usuario. A continuación, la aplicación necesita autorización para leer el perfil completo del usuario de Microsoft Graph siguiendo un patrón que use en todas nuestras bibliotecas de MSAL.

Como se muestra en el código de ejemplo siguiente, la aplicación intenta obtener la autorización llamando a AcquireTokenSilent. Si Microsoft Entra ID puede emitir el token sin interactuar con el usuario, AcquireTokenSilent devuelve el token que la aplicación necesita para acceder a Microsoft Graph en nombre del usuario.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

Sin embargo, a menudo, el identificador de Entra de Microsoft no puede emitir el token sin interactuar con el usuario (por ejemplo, el usuario cambió su contraseña o no concede consentimiento). Por lo tanto, AcquireTokenSilent devuelve un error a la aplicación que requiere interacción del usuario. Cuando la aplicación recibe el error, vuelve a llamar a AcquireTokenPopup.

En ese momento, Microsoft Entra ID tiene una conversación con el usuario para que pueda autenticar al usuario y autorizar a la aplicación a actuar en nombre del usuario (por ejemplo, hacer una MFA, proporcionar su contraseña, conceder consentimiento). A continuación, la aplicación obtiene el token que necesita para avanzar.

Un paso principal en el recorrido de una empresa para una estrategia de confianza cero es adoptar métodos de autenticación más seguros en lugar de solo un id. de usuario y una contraseña. El código de ejemplo anterior permite a una empresa pasar al método de autenticación más seguro que elija la empresa. Por ejemplo, el software de autenticación multifactor totalmente sin contraseña con una clave FIDO2: Microsoft Authenticator.

Pasos siguientes