Utveckla en strategi för delegerade behörigheter

  • Artikel

Den här artikeln hjälper dig som utvecklare att implementera den bästa metoden för att hantera behörigheter i ditt program och utveckla med hjälp av Nolltillit principer. Enligt beskrivningen i Hämta auktorisering för åtkomst till resurser används delegerade behörigheter med delegerad åtkomst för att tillåta ett program att agera för en användares räkning och endast komma åt vad användaren kan komma åt. Programbehörigheter används med direkt åtkomst för att tillåta ett program att komma åt alla data som behörigheten är associerad med. Endast administratörer och ägare av tjänstens huvudnamn kan godkänna programbehörigheter.

Behörighets- och medgivandemodellerna refererar främst till ett program. Behörighets- och medgivandeprocessen har ingen kontroll över vad en användare kan göra. Den styr vilka åtgärder programmet tillåts utföra.

Referera till följande Venn-diagram. Med delegerade behörigheter finns det en skärningspunkt mellan vad användaren får göra och vad programmet får göra. Den skärningspunkten är den effektiva behörighet som programmet är bundet till. När du använder en delegerad behörighet begränsas den av de gällande behörigheterna.

Venndiagram visar effektiva behörigheter som skärningspunkt för appbehörigheter och användarfunktioner.

Ditt program som har användare framför appen får till exempel behörighet att uppdatera varje användares profil i klientorganisationen. Det betyder inte att alla som kör ditt program kan uppdatera någon annans profil. Om administratören bestämmer sig för att bevilja ditt program User.ReadWrite.Alltror de att programmet gör rätt saker när de uppdaterar användarprofilen. Din app kan logga ändringarna och skydda informationen korrekt. Administratören gör en värdebedömning om programmet, inte om användaren.

Metod med minsta möjliga behörighet

API:er kan vara komplexa. Enkla API:er kanske inte har många åtgärder. Komplexa API:er som Microsoft Graph kapslar in många begäranden som ett program kanske vill använda. Bara för att programmet har läsbehörighet betyder det inte att det ska ha rätt att uppdatera. Microsoft Graph har till exempel tusentals API:er. Bara för att du har behörighet att läsa användarens profil finns det ingen anledning till att du också ska ha behörighet att ta bort alla deras OneDrive-filer.

Som utvecklare bör du:

  • vet vilka API:er appen anropar.
  • förstå API-dokumentationen och vilka behörigheter API:et kräver.
  • använd minsta möjliga behörighet för att utföra dina uppgifter.

API:er ger ofta åtkomst till organisationens datalager och drar till sig uppmärksamheten hos angripare som vill komma åt dessa data.

Utvärdera de behörigheter som du begär för att säkerställa att du söker den absolut minst privilegierade uppsättningen för att få jobbet gjort. Undvik att begära behörigheter med högre behörighet. I stället bör du noggrant gå igenom det stora antal behörigheter som API:er som Microsoft Graph tillhandahåller. Leta upp och använd de minsta behörigheterna för att uppfylla dina behov. Om du inte skriver kod för att uppdatera användarens profil begär du den inte för ditt program. Om du bara kommer åt användare och grupper begär du inte åtkomst till annan information i katalogen. Du begär inte behörighet att hantera användarens e-post om du inte skriver kod som kommer åt användarens e-post.

I Nolltillit programutveckling:

  • Definiera programmets avsikt och vad det behöver.
  • Se till att dåliga aktörer inte kan kompromettera och använda din app på ett sätt som du inte hade för avsikt att göra.
  • Gör begäranden om godkännande där du definierar dina krav (till exempel läsa användarens e-post).

Personer som kan godkänna dina begäranden finns i två kategorier: administratörer som alltid kan samtycka till behörighetsbegäranden och vanliga användare som inte är administratörer. Klientadministratörerna har dock sista ord i sin klientorganisation om vilka behörigheter som kräver administratörsmedgivande och till vilka behörigheter en användare kan samtycka till.

När en API-designer kräver administratörsmedgivande för en behörighet kräver den behörigheten alltid administratörsmedgivande. en klientorganisationsadministratör kan inte åsidosätta detta och kräver endast användarmedgivande.

När en API-designer definierar behörigheter som kräver användarmedgivande kan förslag på användarmedgivande från API-designern åsidosättas av klientadministratören. Klientadministratörerna kan göra det med en "stor växel" i klientorganisationen: allt kräver administratörsmedgivande. De kan åsidosätta användarmedgivande på ett mer detaljerat sätt med behörighets- och medgivandehantering. De kan till exempel tillåta användare att samtycka till begäranden om användarmedgivande från verifierade utgivare , men inte från andra utgivare. I ett annat exempel kan de tillåta User.Read att användaren loggar in och läser sin profil men kräver administratörsmedgivande till appar som ber om behörighet att skicka e-post eller till filer.

API-designers ger sina förslag, men klientadministratörer har sista ord. Därför vet du som utvecklare inte alltid när din app kräver administratörsmedgivande. Det är trevligt att planera och utforma runt det, men kom ihåg att när du gör en tokenbegäran kan det nekas av någon anledning. I koden måste du hantera att inte hämta en token eftersom klientadministratörer där dina kunder eller användare kör programmet bestämmer när behörigheter kräver administratörsmedgivande.

Exempel med JavaScript MSAL

För autentiseringen i det här exemplet använder du vårt JavaScript Microsoft Authentication Library (MSAL) för att logga in användaren i ett ensidesprogram (SPA) där all applogik körs från webbläsaren.

I den relaterade snabbstartsartikeln kan du ladda ned och köra ett kodexempel. Den visar hur ett JavaScript-ensidesprogram (SPA) kan logga in användare och anropa Microsoft Graph med hjälp av auktoriseringskodflödet med Proof Key for Code Exchange (PKCE). Kodexemplet visar hur du hämtar en åtkomsttoken för att anropa Microsoft Graph API eller något webb-API.

Som du ser i exempelkoden nedan instansierar du en offentlig klient eftersom ett program som körs helt i webbläsaren måste vara en offentlig klient. Användaren kan få tag på det interna i ditt program när koden finns i webbläsaren.

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

Sedan använder du vårt MSAL-bibliotek. I MSAL JavaScript finns det ett specifikt API för inloggning. Det finns två API:er som använder specifika funktioner i webbläsaren. En är att logga in med en popup-upplevelse; den andra är att logga in med en webbläsaromdirigeringsupplevelse.

Som du ser i kodexemplet nedan hanterar popup-fönstret för inloggning den autentisering som användaren behöver utföra genom att anropa signIn funktionen.

function signIn() {

    /**
     * You can pass a custom request object below. This will override 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);
        });
}

Din app kan hämta information om användaren, till exempel deras visningsnamn eller användar-ID. Därefter behöver din app auktorisering för att läsa användarens fullständiga profil från Microsoft Graph genom att följa ett mönster som du använder i våra MSAL-bibliotek.

Som du ser i exempelkoden nedan försöker appen få auktoriseringen genom att anropa AcquireTokenSilent. Om Microsoft Entra-ID:t kan utfärda token utan att interagera med användaren AcquireTokenSilent returnerar den token som din app behöver för att få åtkomst till Microsoft Graph åt användaren.

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);
            }
    });
}

Men ofta kan Microsoft Entra-ID:t inte utfärda token utan att interagera med användaren (till exempel har användaren ändrat sitt lösenord eller inte har beviljat medgivande). AcquireTokenSilent Därför skickar ett fel tillbaka till programmet som kräver användarinteraktion. När du är din app får felet återgår du till att anropa AcquireTokenPopup.

Då kommer Microsoft Entra-ID:t att ha en konversation med användaren så att de kan autentisera användaren och auktorisera appen att agera för användarens räkning (till exempel göra en MFA, ange sitt lösenord, bevilja medgivande). Sedan får appen den token som behövs för att gå vidare.

Ett primärt steg i företagets resa till Nolltillit är att använda starkare autentiseringsmetoder i stället för bara ett användar-ID och lösenord. Med den exempelkod som beskrivs ovan kan ett företag övergå till den starkare autentiseringsmetod som företaget väljer. Till exempel multifaktorautentisering, helt lösenordslös med en FIDO2-nyckel, Microsoft Authenticator.

Nästa steg

  • När du skaffar auktorisering för åtkomst till resurser kan du förstå hur du bäst kan säkerställa Nolltillit när du hämtar behörigheter för resursåtkomst för ditt program.
  • Genom att utveckla en strategi för programbehörigheter kan du bestämma hur programmets behörigheter ska hanteras.
  • Anpassning av token beskriver den information som du kan ta emot i Microsoft Entra-token och hur du anpassar token för att förbättra flexibiliteten och kontrollen samtidigt som du ökar säkerheten för program utan förtroende med minsta möjliga behörighet.
  • När du konfigurerar gruppanspråk och approller i token visas hur du konfigurerar dina appar med approlldefinitioner och tilldelar säkerhetsgrupper till approller för att förbättra flexibiliteten och kontrollen samtidigt som du ökar säkerheten för program utan förtroende med minsta möjliga behörighet.
  • API Protection beskriver metodtips för att skydda ditt API genom registrering, definiera behörigheter och medgivande samt framtvinga åtkomst för att uppnå dina Nolltillit mål.
  • Genom att anropa ett API från ett annat API kan du se till att Nolltillit när du har ett API som behöver anropa ett annat API och på ett säkert sätt utveckla ditt program när det fungerar för en användares räkning.
  • Metodtips för auktorisering hjälper dig att implementera de bästa auktoriserings-, behörighets- och medgivandemodellerna för dina program.
  • Använd bästa praxis för utveckling av Nolltillit identitets- och åtkomsthantering i programutvecklingslivscykeln för att skapa säkra program.