Pokyny pro vývojáře pro podmíněný přístup Microsoft Entra

  • Článek

Funkce podmíněného přístupu v Microsoft Entra ID nabízí jeden z několika způsobů, jak můžete použít k zabezpečení aplikace a ochraně služby. Podmíněný přístup umožňuje vývojářům a podnikovým zákazníkům chránit služby mnoha způsoby, mezi které patří:

  • Vícefaktorové ověřování
  • Povolení přístupu ke konkrétním službám jenom zařízením zaregistrovaným v Intune
  • Omezení umístění uživatelů a rozsahů IP adres

Další informace o všech možnostech podmíněného přístupu najdete v článku Co je podmíněný přístup.

Pro vývojáře, kteří vytvářejí aplikace pro Microsoft Entra ID, tento článek ukazuje, jak můžete používat podmíněný přístup, a dozvíte se také o dopadu přístupu k prostředkům, u kterých nemáte kontrolu nad tím, že se můžou použít zásady podmíněného přístupu. Tento článek také zkoumá důsledky podmíněného přístupu v toku jménem, webových aplikacích, přístupu k Microsoft Graphu a volání rozhraní API.

Předpokládá se znalost jednoduchých a víceklientských aplikací a běžných vzorů ověřování.

Poznámka:

Použití této funkce vyžaduje licenci Microsoft Entra ID P1. Pokud chcete najít správnou licenci pro vaše požadavky, přečtěte si porovnání obecně dostupných funkcí edic Free, Basic a Premium. Zákazníci s licencemi Microsoft 365 Business mají také přístup k funkcím podmíněného přístupu.

Jaký vliv má podmíněný přístup na aplikaci?

Ovlivněné typy aplikací

Ve většině případů podmíněný přístup nemění chování aplikace ani nevyžaduje žádné změny od vývojáře. Pouze v určitých případech, kdy aplikace nepřímo nebo bezobslužně požaduje token pro službu, aplikace vyžaduje změny kódu pro zpracování problémů s podmíněným přístupem. Může to být jednoduché jako provedení interaktivní žádosti o přihlášení.

Konkrétně následující scénáře vyžadují kód pro zvládnutí problémů s podmíněným přístupem:

  • Aplikace provádějící tok jménem
  • Aplikace, které přistupují k více službám nebo prostředkům
  • Jednostrákové aplikace využívající MSAL.js
  • Webové aplikace volají prostředek

Zásady podmíněného přístupu se dají použít pro aplikaci, ale dají se použít i na webové rozhraní API, ke které vaše aplikace přistupuje. Další informace o tom, jak nakonfigurovat zásady podmíněného přístupu, najdete v tématu Rychlý start: Vyžadování vícefaktorového ověřování pro konkrétní aplikace pomocí podmíněného přístupu Microsoft Entra.

V závislosti na scénáři může podnikový zákazník kdykoli použít a odebrat zásady podmíněného přístupu. Aby vaše aplikace pokračovala v fungování při použití nové zásady, implementujte zpracování výzev. Následující příklady ilustrují zpracování úkolů.

Příklady podmíněného přístupu

Některé scénáře vyžadují změny kódu pro zpracování podmíněného přístupu, zatímco jiné fungují tak, jak jsou. Tady je několik scénářů, které používají podmíněný přístup k vícefaktorovým ověřováním, které poskytují přehled o rozdílu.

  • Vytváříte aplikaci pro iOS s jedním tenantem a používáte zásady podmíněného přístupu. Aplikace se přihlásí k uživateli a nepožádá o přístup k rozhraní API. Když se uživatel přihlásí, zásada se automaticky vyvolá a uživatel musí provést vícefaktorové ověřování (MFA).
  • Vytváříte nativní aplikaci, která pro přístup k podřízenému rozhraní API používá službu střední vrstvy. Podnikový zákazník ve společnosti používající tuto aplikaci použije zásadu pro podřízené rozhraní API. Když se koncový uživatel přihlásí, nativní aplikace požádá o přístup ke střední vrstvě a odešle token. Střední vrstva provádí tok jménem za účelem vyžádání přístupu k podřízenému rozhraní API. V tomto okamžiku se do střední vrstvy zobrazí deklarace identity "výzva". Střední vrstva odešle výzvu zpět do nativní aplikace, která musí dodržovat zásady podmíněného přístupu.

Microsoft Graph

Microsoft Graph má při vytváření aplikací v prostředích podmíněného přístupu zvláštní aspekty. Obecně platí, že mechanika podmíněného přístupu se chová stejně, ale zásady, které uživatelé uvidí, budou založené na podkladových datech, která vaše aplikace požaduje z grafu.

Konkrétně všechny obory Microsoft Graphu představují určitou datovou sadu, která může použít zásady jednotlivě. Vzhledem k tomu, že zásady podmíněného přístupu mají přiřazené konkrétní datové sady, vynucuje Microsoft Entra ID podmíněného přístupu zásady podmíněného přístupu na základě dat, která jsou za Graphem , a ne na samotném Graphu.

Pokud například aplikace požaduje následující obory Microsoft Graphu,

scopes="ChannelMessages.Read.All Mail.Read"

Aplikace může očekávat, že uživatelé splní všechny zásady nastavené v Teams a Exchange. Některé obory se můžou mapovat na více datových sad, pokud udělí přístup.

Dodržování zásad podmíněného přístupu

U několika různých topologií aplikací se při vytvoření relace vyhodnotí zásada podmíněného přístupu. Vzhledem k tomu, že zásady podmíněného přístupu pracují s členitostíaplikacíchm aplikacím a službám, závisí zejména na scénáři, který se pokoušíte provést.

Když se vaše aplikace pokusí o přístup ke službě pomocí zásad podmíněného přístupu, může nastat výzva podmíněného přístupu. Tento problém je kódován v parametru claims , který přichází v odpovědi z Microsoft Entra ID. Tady je příklad tohoto parametru výzvy:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Vývojáři můžou tuto výzvu přijmout a připojit ho k novému požadavku na ID Microsoft Entra. Při předání tohoto stavu se koncovému uživateli zobrazí výzva k provedení jakékoli akce potřebné k dosažení souladu se zásadami podmíněného přístupu. V následujících scénářích jsou vysvětleny specifika chyby a způsobu extrakce parametru.

Scénáře

Požadavky

Podmíněný přístup Microsoft Entra je funkce, která je součástí Microsoft Entra ID P1 nebo P2. Zákazníci s licencemi Microsoft 365 Business mají také přístup k funkcím podmíněného přístupu.

Důležité informace pro konkrétní scénáře

Následující informace platí jenom v těchto scénářích podmíněného přístupu:

  • Aplikace provádějící tok jménem
  • Aplikace, které přistupují k více službám nebo prostředkům
  • Jednostrákové aplikace využívající MSAL.js

V následujících částech jsou popsané běžné scénáře, které jsou složitější. Základním provozním principem jsou zásady podmíněného přístupu vyhodnocovány v době, kdy se token požaduje pro službu, která má použitou zásadu podmíněného přístupu.

Scénář: Aplikace provádí tok On-Behalf-Of

V tomto scénáři si projdeme případ, kdy nativní aplikace volá webovou službu nebo rozhraní API. Tato služba zase tok "on-behalf-of" volá podřízenou službu. V našem případě jsme pro podřízenou službu (Webové rozhraní API 2) použili zásady podmíněného přístupu a místo aplikace serveru nebo démona používáme nativní aplikaci.

App performing the on-behalf-of flow diagram

Počáteční požadavek na token pro webové rozhraní API 1 nevyžaduje koncovému uživateli vícefaktorové ověřování, protože webové rozhraní API 1 nemusí vždy udeřit na podřízené rozhraní API. Jakmile se webové rozhraní API 1 pokusí vyžádat token jménem uživatele pro webové rozhraní API 2, požadavek selže, protože se uživatel nepřihlásil pomocí vícefaktorového ověřování.

Microsoft Entra ID vrátí odpověď HTTP s některými zajímavými daty:

Poznámka:

V tomto případě se jedná o popis chyby vícefaktorového ověřování, ale existuje celá řada interaction_required možností, které se týkají podmíněného přístupu.

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Ve webovém rozhraní API 1 zachytáme chybu error=interaction_requireda pošleme claims výzvu do desktopové aplikace. V tomto okamžiku může desktopová aplikace provést nové acquireToken() volání a připojit claimsvýzvu jako parametr řetězce dotazu navíc. Tento nový požadavek vyžaduje, aby uživatel udělal vícefaktorové ověřování a pak tento nový token odeslal zpět do webového rozhraní API 1 a dokončil tok on-behalf-of.

Pokud si chcete tento scénář vyzkoušet, projděte si ukázku kódu .NET. Ukazuje, jak předat výzvu deklarací identity zpět z webového rozhraní API 1 do nativní aplikace a vytvořit nový požadavek v klientské aplikaci.

Scénář: Aplikace přistupující k více službám

V tomto scénáři si projdeme případ, kdy webová aplikace přistupuje ke dvěma službám, z nichž jedna má přiřazenou zásadu podmíněného přístupu. V závislosti na logice aplikace může existovat cesta, ve které vaše aplikace nevyžaduje přístup k oběma webovým službám. V tomto scénáři hraje pořadí, ve kterém si vyžádáte token, důležitou roli v prostředí koncového uživatele.

Předpokládejme, že máme webovou službu A a B a webovou službu B, pro které se použijí naše zásady podmíněného přístupu. I když počáteční interaktivní žádost o ověření vyžaduje souhlas pro obě služby, zásady podmíněného přístupu se ve všech případech nevyžadují. Pokud aplikace požádá o token pro webovou službu B, zásady se vyvolá a následné požadavky na webovou službu A se také úspěšně promítnou následujícím způsobem.

App accessing multiple-services flow diagram

Pokud aplikace původně požádá o token pro webovou službu A, koncový uživatel nevyvolá zásady podmíněného přístupu. Vývojáři aplikací tak můžou řídit prostředí koncového uživatele, a ne vynutit vyvolání zásad podmíněného přístupu ve všech případech. Složitým případem je, že aplikace později požádá o token pro webovou službu B. V tomto okamžiku musí koncový uživatel dodržovat zásady podmíněného přístupu. Když se aplikace pokusí acquireToken, může vygenerovat následující chybu (znázorněno v následujícím diagramu):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App accessing multiple services requesting a new token

Pokud aplikace používá knihovnu MSAL, dojde k selhání získání tokenu vždy interaktivně. Když k tomuto interaktivnímu požadavku dojde, má koncový uživatel možnost dodržovat podmíněný přístup. To platí, pokud není žádost nebo AcquireTokenSilentAsyncPromptBehavior.Never v takovém případě musí aplikace provést interaktivní AcquireToken žádost, aby koncovému uživateli poskytla příležitost dodržovat zásady.

Scénář: Jednostránkové aplikace (SPA) využívající MSAL.js

V tomto scénáři si projdeme případ, kdy jednostránkové aplikace (SPA) volá webové rozhraní API chráněné podmíněným přístupem pomocí MSAL.js. Jedná se o jednoduchou architekturu, ale má některé nuance, které je potřeba vzít v úvahu při vývoji podmíněného přístupu.

V MSAL.js existuje několik funkcí, které získávají tokeny: acquireTokenSilent(), acquireTokenPopup()a acquireTokenRedirect().

  • acquireTokenSilent() lze použít k tichému získání přístupového tokenu, což znamená, že uživatelské rozhraní se nezobrazuje za žádných okolností.
  • acquireTokenPopup() a acquireTokenRedirect() používají se k interaktivnímu vyžádání tokenu pro prostředek, což znamená, že vždy zobrazují přihlašovací uživatelské rozhraní.

Když aplikace potřebuje přístupový token pro volání webového rozhraní API, pokusí se o acquireTokenSilent(). Pokud platnost tokenu vypršela nebo potřebujeme dodržovat zásady podmíněného přístupu, funkce acquireToken selže a aplikace ji používá acquireTokenPopup() nebo acquireTokenRedirect().

Single-page app using MSAL flow diagram

Pojďme si projít příklad s naším scénářem podmíněného přístupu. Koncový uživatel právě přistál na webu a nemá relaci. Provedeme loginPopup() volání, získáme token ID bez vícefaktorového ověřování. Pak uživatel přejde na tlačítko, které vyžaduje, aby aplikace požadovala data z webového rozhraní API. Aplikace se pokusí provést acquireTokenSilent() volání, ale selže, protože uživatel ještě neprováděl vícefaktorové ověřování a potřebuje dodržovat zásady podmíněného přístupu.

Id Microsoft Entra odešle zpět následující odpověď HTTP:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

Naše aplikace potřebuje zachytit error=interaction_required. Aplikace pak může použít buď acquireTokenPopup() nebo acquireTokenRedirect() ve stejném prostředku. Uživatel musí provést vícefaktorové ověřování. Jakmile uživatel dokončí vícefaktorové ověřování, aplikace vydá pro požadovaný prostředek nový přístupový token.

Pokud si chcete tento scénář vyzkoušet, podívejte se na naše webové rozhraní API React SPA volající Node.js pomocí ukázky kódu toku jménem uživatele. Tento vzorový kód používá zásady podmíněného přístupu a webové rozhraní API, které jste zaregistrovali dříve ve službě React SPA, k předvedení tohoto scénáře. Ukazuje, jak správně zpracovat výzvu deklarací identity a získat přístupový token, který je možné použít pro webové rozhraní API.

Viz také