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

Platí pro: Zelený kruh se symbolem bílé značky zaškrtnutí, který označuje následující obsah platí pro tenanty pracovních sil. Tenanti pracovních sil (další informace)

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 uživatele, webových aplikacích, přístupu do Microsoft Graph a volání 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 článek 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í postup jménem uživatele
  • 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í zdroj

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 společnosti, který používá tuto aplikaci, aplikuje zásadu na 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 je střední vrstvě předložena námitka na pohledávku. 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 scope Microsoft Graph představují určitou datovou sadu, na které lze jednotlivě uplatňovat zásady. Protože jsou zásady podmíněného přístupu přiřazeny konkrétním datovým sadám, vynucuje Microsoft Entra ID zásady podmíněného přístupu na základě dat 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é části se můžou mapovat na více datových sad, pokud umožňují přístup.

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

U různých topologií aplikací se zásada podmíněného přístupu vyhodnotí při vytvoření relace. Vzhledem k tomu, že zásady podmíněného přístupu pracují na úrovni aplikací a služeb, závisí bod, ve kterém jsou uplatněny, zejména na scénáři, který se snažíte realizovat.

Když se vaše aplikace pokusí získat přístup ke službě s politikou podmíněného přístupu, může být vyzvána k podmíněnému 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 zahrnutá v 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í postup jménem uživatele
  • 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ějící tok jménem uživatele

V tomto scénáři si projdeme případ, kdy nativní aplikace volá webovou službu nebo rozhraní API. Tato služba proto provádí tok "jménem" k vyvolání podřízené služby. 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.

aplikace provádějící diagram toku jménem jiné aplikace

Počáteční požadavek na token pro webové rozhraní API 1 nepožaduje od koncového uživatele vícefaktorové ověřování, protože webové rozhraní API 1 nemusí vždy přistupovat k podřízenému 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 multifactor 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 zpět claims výzvu do desktopové aplikace. V tomto okamžiku může desktopová aplikace provést nové volání acquireToken() a připojit výzvu claimsjako 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, podívejte se na 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, je politika uplatněna a následné požadavky na webovou službu A také úspěšně proběhnou následujícím způsobem.

Aplikace přistupující k diagramu toku více služeb

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í provést acquireToken, může vygenerovat následující chybu (viz následující diagram):

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 multifactor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Aplikace, která přistupuje k více službám, které požadují nový token,

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

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

V tomto scénáři si projdeme případ, kdy máme jednostránkovou aplikaci (SPA) volající 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.jsexistuje 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() i acquireTokenRedirect() slouží 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().

Jednostráková aplikace využívající diagram toku MSAL

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 multifactor authentication to access '<Web API App/Client ID>'.

Naše aplikace potřebuje zachytávat error=interaction_required. Aplikace pak může použít buď acquireTokenPopup(), nebo acquireTokenRedirect() ve stejném zdroji. 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 náš příklad kódu pro React SPA volající webové rozhraní API Node.js pomocí toku 'on-behalf-of'. 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é

  • Last updated on