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. Oprávnění aplikace se používají s přímým přístupem, aby aplikace mohla přistupovat k datům, ke kterým je oprávnění přidruženo. Oprávnění aplikace můžou udělit jenom správci a vlastníci instančních objektů .

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 vázaná.

"Popis Vennova diagramu: Text levého kruhu: Aplikace mají udělený souhlas s rozsahem operace aplikace. Správný text 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 před aplikací, získá oprávnění k aktualizaci profilu každého uživatele v tenantovi. To neznamená, že kdokoli, na kterém běží vaše aplikace, může aktualizovat profil někoho jiného. Pokud se správce rozhodne aplikaci udělit User.ReadWrite.All, pak se domnívá, že vaše aplikace provádí správné věci při aktualizaci profilu uživatelů. Vaše aplikace může změny protokolovat a správně chránit informace. Správce rozhodne o aplikaci hodnotu, ne o uživateli.

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 upoutají pozornost útočníků, kteří chtějí k datům přistupovat.

Vyhodnoťte oprávnění, která požadujete, abyste zajistili, že hledáte absolutní privilegovanou sadu pro dokončení úlohy. 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 nulová důvěra (Zero Trust) vývoji aplikací:

• 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ů ale mají ve svém tenantovi konečné vyjádření toho, která oprávnění vyžadují souhlas správce a jaká oprávnění může uživatel udělit.

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. Správci tenanta to můžou udělat s velkým přepínačem v tenantovi: všechno vyžaduje souhlas správce. S oprávněními a správou souhlasu můžou uživatele přerušovat podrobněji. 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é naplánovat a navrhnout kolem toho, ale pamatujte si, že když vytvoříte žádost o token, může být zamítnut z jakéhokoli důvodu. V kódu musíte řádně zpracovat nedostávání tokenu, protože správci tenantů, ve kterých vaši zákazníci nebo uživatelé používají vaši aplikaci, rozhodují, 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 jednostránkové aplikace JavaScriptu (SPA) může přihlásit uživatele a volat Microsoft Graph pomocí toku autorizačního kódu s ověřovacím klíčem 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ůže si uživatel pořídit interní informace o vaší aplikaci.

// 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í automaticky otevíraných oken; druhým je přihlášení pomocí prostředí pro 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ž se vám zobrazí chyba, 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í a současně se zvýšilo zabezpečení nulové důvěryhodnosti aplikace 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 řízení a současně zvýšit zabezpečení nulové důvěryhodnosti aplikace 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 identit a přístupu nulová důvěra (Zero Trust) v životním cyklu vývoje aplikací.