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í v aplikaci a vyvíjet pomocí principů nulová důvěra (Zero Trust). Jak je popsáno v tématu 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í, je svázané efektivními oprávněními.
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 nebudete psát kód pro aktualizaci profilu uživatele, nebudete si ho vyžádat pro vaši aplikaci. Pokud přistupujete jenom k uživatelům a skupinám, nebudete žádat o přístup k jiným informacím v adresáři. Nebudete požadovat oprávnění ke správě e-mailů uživatelů, pokud nebudete psát kód, který přistupuje k e-mailu uživatele.
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é, kdo může 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 pro oprávnění, bude toto oprávnění vždy vyžadovat souhlas správce; správce tenanta nemůže tuto možnost 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 od 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 nebudete 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 příkladu kódu níže, automaticky otevírané okno přihlašování zpracovává ověřování, které uživatel potřebuje provést voláním signIn funkce.
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);
});
}
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ý budete používat v našich knihovnách 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). Proto odešle chybu zpět do aplikace, AcquireTokenSilent která vyžaduje interakci uživatele. Když se vám zobrazí chyba, vrátíte se zpět do hovoru AcquireTokenPopup.
V tomto okamžiku bude Microsoft Entra ID mít konverzaci s uživatelem, aby mohl ověřit uživatele a autorizovat vaši aplikaci tak, aby jednala jménem uživatele (například mfaktoring, zadat heslo, udělit souhlas). Aplikace pak získá token potřebný 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. Ukázkový kód popsaný výše 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í pro přístup k prostředkům pro vaši aplikaci.
- Vývoj strategie oprávnění aplikací vám pomůže při rozhodování 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 získat v tokenech Microsoft Entra a jak přizpůsobit tokeny, aby se zlepšila flexibilita a řízení a současně se zvyšuje zabezpečení nulové důvěryhodnosti aplikace s nejnižšími oprávněními.
- Při konfiguraci skupinových deklarací identity a rolí aplikací v tokenech se dozvíte, jak nakonfigurovat aplikace s definicemi rolí aplikací a přiřadit skupiny zabezpečení k rolím aplikací, 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.
- 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í.
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro