Vývoj strategie delegovaných oprávnění

Tento článek vám jako vývojář pomůže implementovat nejlepší přístup ke správě oprávnění ve vaší aplikaci a vyvíjet pomocí nulová důvěra (Zero Trust) principů. Jak je popsáno v části Získání autorizace pro přístup k prostředkům, delegovaná oprávnění se používají s delegovaným přístupem, aby aplikace mohla jednat jménem uživatele a přistupovat pouze k tomu, k čemu má uživatel přístup. Pokud chcete získat přístup k datům přidruženým k oprávnění, použijte oprávnění aplikace s přímým přístupem a povolte aplikaci. Jenom správci a vlastníci aplikačních objektů mohou dát souhlas k oprávněním aplikace.

Modely oprávnění a souhlasu se týkají především aplikace. Proces oprávnění a souhlasu nemá žádnou kontrolu nad tím, co může uživatel dělat. Určuje, jaké akce může aplikace provádět.

Odkaz na následující Vennův diagram S delegovanými oprávněními existuje průsečík mezi tím, co může uživatel dělat a co může aplikace dělat. Tento průnik představuje efektivní oprávnění, kterým je aplikace svázaná. Kdykoli použijete delegovaná oprávnění, efektivní oprávnění je omezují.

"Popis Vennova diagramu: Text levého kruhu: Aplikace mají udělený souhlas s rozsahem operace aplikace. Text v pravém kruhu: Uživatelé mají oprávnění k operacím spravovaným jejich organizací. Průnik textu kruhů: Platná oprávnění: průnik oprávnění aplikace a možností uživatele."

Například vaše aplikace, která má uživatele interagující s aplikací, získá oprávnění k aktualizaci profilu každého uživatele v tenantu. To neznamená, že kdokoli, na kterém běží vaše aplikace, může aktualizovat profil někoho jiného. Pokud se správce rozhodne vaší aplikaci udělit User.ReadWrite.All, znamená to, že věří, že vaše aplikace správně aktualizuje profily uživatelů. Vaše aplikace může změny protokolovat a správně chránit informace. Správce hodnotí aplikaci, ne uživatele.

Přístup s nejnižšími oprávněními

Rozhraní API můžou být složitá. Jednoduchá rozhraní API nemusí mít mnoho operací. Složitá rozhraní API, jako je Microsoft Graph, zapouzdřují mnoho požadavků, které může aplikace chtít použít. Jen proto, že aplikace má právo číst, neznamená, že by měla mít právo aktualizovat. Microsoft Graph má například tisíce rozhraní API. Jen proto, že máte oprávnění ke čtení profilu uživatele, neexistuje důvod, proč byste měli mít oprávnění k odstranění všech jejich souborů Na OneDrivu.

Jako vývojář byste měli:

• Zjistěte, která rozhraní API aplikace volá.
• seznamte se s dokumentací k rozhraní API a oprávněními, která rozhraní API vyžaduje.
• k plnění úkolů použijte co nejmenší možná oprávnění.

Rozhraní API často poskytují přístup k úložištům dat organizace a přilákají pozornost špatných herců, kteří chtějí k datům přistupovat.

Vyhodnoťte oprávnění, která požadujete, abyste zajistili, že vyžadujete absolutně nejméně privilegovanou sadu k vykonání úkolu. Vyhněte se vyžádání vyšších oprávnění. Místo toho pečlivě projděte velký počet oprávnění, která poskytují rozhraní API, jako je Microsoft Graph. Vyhledejte a použijte minimální oprávnění k řešení vašich potřeb. Pokud nezapíšete kód pro aktualizaci profilu uživatele, nebudete ho požadovat pro vaši aplikaci. Pokud přistupujete jenom k uživatelům a skupinám, nepožadujete přístup k jiným informacím v adresáři. Pokud nezapisujete kód, který přistupuje k e-mailu uživatele, nepožadujete oprávnění ke správě e-mailů uživatelů.

Ve vývoji aplikací Zero Trust:

• Definujte záměr vaší aplikace a to, co potřebuje.
• Zajistěte, aby špatní aktéři nemohli ohrozit zabezpečení a používat vaši aplikaci způsobem, který jste neplánovali.
• Proveďte žádosti o schválení, ve kterém definujete své požadavky (například přečtěte si e-mail uživatele).

Role správce uživatele a tenanta v oprávnění a souhlasu

Lidé, kteří můžou vaše žádosti schválit, spadají do dvou kategorií: správci, kteří můžou vždy souhlasit s žádostmi o oprávnění a běžnými uživateli, kteří nejsou správci. Správci tenantů mají poslední slovo ohledně toho, která oprávnění vyžadují souhlas správce a k jakým oprávněním může uživatel dát souhlas.

Pokud návrhář rozhraní API vyžaduje souhlas správce s oprávněním, toto oprávnění vždy vyžaduje souhlas správce. Správce tenanta to nemůže přerušovat a vyžadovat pouze souhlas uživatele.

Když návrhář rozhraní API definuje oprávnění, která vyžadují souhlas uživatele, může správce tenanta přerušovat návrhy souhlasu uživatele návrháře rozhraní API. Administrátoři tenantů to mohou udělat s velkým přepínačem, který je v tenantovi: všechno vyžaduje souhlas správce. Mohou podrobněji spravovat a přepisovat souhlas uživatelů pomocí správy oprávnění a souhlasů. Mohou například uživatelům povolit souhlas s žádostmi o souhlas uživatele od ověřených vydavatelů , ale ne od jiných vydavatelů. V jiném příkladu můžou povolit User.Read přihlášení uživatele a čtení jeho profilu, ale vyžadují souhlas správce s aplikacemi, které požadují oprávnění k e-mailu nebo souborům.

Návrháři rozhraní API navrhují své návrhy, ale správci tenantů mají konečné slovo. Jako vývojář proto nemusíte vždy vědět, kdy vaše aplikace vyžaduje souhlas správce. Je hezké plánovat a navrhovat s ohledem na to. Mějte na paměti, že když vytvoříte žádost o token, může být z jakéhokoli důvodu zamítnuta. V kódu musíte řádně zpracovat nedostávání tokenu, protože správci tenantů, ve kterých se vaši zákazníci nebo uživatelé, kteří vaši aplikaci spouští, rozhodnou, kdy oprávnění vyžadují souhlas správce.

Příklad použití knihovny MSAL JavaScriptu

Pro ověřování v tomto příkladu použijete naši knihovnu MSAL (JavaScript Microsoft Authentication Library) k přihlášení uživatele v jednostránkové aplikaci (SPA), kde se veškerá logika aplikace spouští z prohlížeče.

V souvisejícím článku Rychlého startu si můžete stáhnout a spustit ukázku kódu. Ukazuje, jak se mohou jednostránkové aplikace v JavaScriptu (SPA) přihlásit se uživatelem a volat Microsoft Graph s tokem autorizačního kódu pomocí ověřovacího klíče pro výměnu kódu (PKCE). Ukázka kódu ukazuje, jak získat přístupový token pro volání rozhraní Microsoft Graph API nebo libovolného webového rozhraní API.

Jak je znázorněno v následujícím ukázkovém kódu, vytvoříte instanci veřejného klienta, protože aplikace, která běží zcela v prohlížeči, musí být veřejným klientem. Když je kód v prohlížeči, má uživatel přístup k interním částem vaší aplikace.

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

Pak použijete naši knihovnu MSAL. V MSAL JavaScriptu je k dispozici konkrétní rozhraní API pro přihlášení. Existují dvě rozhraní API, která využívají konkrétní funkce v prohlížeči. Jedním z nich je přihlášení pomocí vyskakovacích oken; druhým je přihlášení prostřednictvím přesměrování prohlížeče.

Jak je znázorněno v následujícím příkladu kódu, automaticky otevírané okno se stará o ověření, které uživatel potřebuje provést voláním signIn funkce.

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

Vaše aplikace může získat informace o uživateli, například zobrazované jméno nebo ID uživatele. Dále vaše aplikace potřebuje autorizaci ke čtení úplného profilu uživatele z Microsoft Graphu podle vzoru, který používáte v rámci našich knihoven MSAL.

Jak je znázorněno v následujícím ukázkovém kódu, vaše aplikace se pokusí získat autorizaci voláním AcquireTokenSilent. Pokud může Microsoft Entra ID vydat token bez interakce s uživatelem, AcquireTokenSilent vrátí token, který vaše aplikace potřebuje pro přístup k Microsoft Graphu jménem uživatele.

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

Často ale Microsoft Entra ID nemůže vydat token bez interakce s uživatelem (například uživatel změnil heslo nebo neudělil souhlas). AcquireTokenSilent Proto odešle chybu zpět do aplikace, která vyžaduje interakci uživatele. Když vaše aplikace obdrží chybu, vrátíte se k volání AcquireTokenPopup.

V tomto okamžiku má Microsoft Entra ID konverzaci s uživatelem, aby mohl ověřit uživatele a autorizovat vaši aplikaci tak, aby jednala jménem uživatele (například provést vícefaktorové ověřování, zadat heslo, udělit souhlas). Aplikace pak získá token, který potřebuje k pohybu vpřed.

Primárním krokem na cestě podniku k nulová důvěra (Zero Trust) je přijetí silnějších metod ověřování místo jen ID uživatele a hesla. Předchozí ukázkový kód plně umožňuje podniku přejít na silnější metodu ověřování, kterou podnik zvolí. Například vícefaktorové ověřování, plně bez hesla s klíčem FIDO2, Microsoft Authenticator.

Další kroky

• Získání autorizace pro přístup k prostředkům vám pomůže pochopit, jak nejlépe zajistit nulová důvěra (Zero Trust) při získávání oprávnění přístupu k prostředkům pro vaši aplikaci.
• Strategie vytváření oprávnění aplikací vám pomůže rozhodnout se o přístupu k oprávněním aplikace ke správě přihlašovacích údajů.
• Přizpůsobení tokenů popisuje informace, které můžete přijímat v tokenech Microsoft Entra. Vysvětluje, jak přizpůsobit tokeny, aby se zlepšila flexibilita a řízení při zvýšení zabezpečení nulové důvěryhodnosti aplikací s nejnižšími oprávněními.
• Konfigurace deklarací identity skupin a rolí aplikací v tokenech ukazuje, jak nakonfigurovat aplikace s definicemi rolí aplikace a přiřadit skupiny zabezpečení k rolím aplikací. Tyto metody pomáhají zlepšit flexibilitu a kontrolu při zvyšování zabezpečení nulové důvěryhodnosti aplikací s nejnižšími oprávněními.
• Služba API Protection popisuje osvědčené postupy pro ochranu rozhraní API prostřednictvím registrace, definování oprávnění a souhlasu a vynucování přístupu k dosažení vašich cílů nulová důvěra (Zero Trust).
• Volání rozhraní API z jiného rozhraní API vám pomůže zajistit nulová důvěra (Zero Trust), když máte jedno rozhraní API, které potřebuje volat jiné rozhraní API a bezpečně vyvíjet aplikaci, když pracuje jménem uživatele.
• Osvědčené postupy autorizace pomáhají implementovat nejlepší modely autorizace, oprávnění a souhlasu pro vaše aplikace.
• K vytváření zabezpečených aplikací použijte osvědčené postupy pro vývoj řízení identit a přístupu Zero Trust v životním cyklu vývoje aplikací.