Pokyny pro vývojáře pro funkci podmíněného přístupu Azure AD

  • Článek

Upozornění

Tento obsah je určený pro starší koncový bod Azure AD verze 1.0. Pro nové projekty použijte Microsoft identity platform.

Poznámka

Microsoft identity platform verzi tohoto článku najdete v pokynech pro vývojáře pro Microsoft Entra podmíněný přístup.

Funkce podmíněného přístupu v Microsoft Entra ID nabízí jeden z několika způsobů zabezpečení aplikace a ochrany 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ří:

  • Ověřování pomocí služby Multi-Factor Authentication
  • 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 úplných funkcích podmíněného přístupu najdete v tématu Co je podmíněný přístup.

Pro vývojáře, kteří vytvářejí aplikace pro Azure AD, 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, nad kterými nemáte kontrolu, a můžou se 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 on-behalf-of, webových aplikacích, přístupu k Microsoft Graphu a volání rozhraní API.

Předpokládá se znalost aplikací s jedním a více tenanty a běžných vzorů ověřování .

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

Ovlivněné typy aplikací

Ve většině nejčastějších případů podmíněný přístup nemění chování aplikace ani nevyžaduje žádné změny od vývojáře. Pouze v některých případech, kdy aplikace nepřímo nebo bezobslužně požádá o token pro službu, vyžaduje aplikace změny kódu, aby zvládla "výzvy" podmíněného přístupu. 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 zpracování "výzev" podmíněného přístupu:

  • Aplikace provádějící tok on-behalf-of
  • Aplikace přistupující k více službám nebo prostředkům
  • Jednostránkové aplikace využívající ADAL.js
  • Web Apps volání prostředku

Zásady podmíněného přístupu se dají použít pro aplikaci, ale také pro webové rozhraní API, ke které vaše aplikace přistupuje. Další informace o konfiguraci zásad podmíněného přístupu najdete v tématu Běžné zásady podmíněného přístupu.

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 fungovala i při použití nové zásady, musíte implementovat zpracování výzvy. Následující příklady znázorňují zpracování výzvy.

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ářů použití podmíněného přístupu k vícefaktorovému ověřování, které poskytuje určitý 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 nevyžaduje 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é aplikaci 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 on-behalf-of a žádá o přístup k podřízené rozhraní API. V tomto okamžiku se pro střední vrstvu zobrazí "výzva" deklarací identity. Střední vrstva odešle výzvu zpět do nativní aplikace, která musí splň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 mechanismus 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í některou datovou sadu, u které se můžou zásady použít jednotlivě. Vzhledem k tomu, že zásady podmíněného přístupu jsou přiřazené ke konkrétním datovým sadám, Azure AD vynucuje zásady podmíněného přístupu na základě dat, která jsou za grafem, nikoli samotným Grafem.

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

scopes="Bookings.Read.All Mail.Read"

Aplikace může očekávat, že její uživatelé budou splňovat všechny zásady nastavené na Bookings 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 vyhodnocují zásady podmíněného přístupu. Vzhledem k tomu, že zásady podmíněného přístupu fungují na členitosti aplikací a služeb, závisí bod, ve kterém se vyvolá, do značné míry na scénáři, kterého se pokoušíte dosáhnout.

Když se aplikace pokusí o přístup ke službě pomocí zásad podmíněného přístupu, může narazit na výzvu podmíněného přístupu. Tato výzva je zakódována v parametruclaims, který přichází v odpovědi z Azure AD. 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 ji k novému požadavku na Azure AD. Předání tohoto stavu vyzve koncového uživatele k provedení jakékoli akce potřebné k dodržování zásad podmíněného přístupu. V následujících scénářích jsou vysvětlena specifika chyby a způsob extrahování parametru.

Scénáře

Požadavky

Microsoft Entra podmíněný přístup je funkce, která je součástí Microsoft Entra ID P1 nebo P2. Další informace o licenčních požadavcích najdete v sestavě využití bez licence. Vývojáři se můžou připojit ke službě Microsoft Developer Network, která zahrnuje bezplatné předplatné sady Enterprise Mobility Suite, které zahrnuje Microsoft Entra ID P1 nebo P2.

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

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

  • Aplikace provádějící tok on-behalf-of
  • Aplikace přistupující k více službám nebo prostředkům
  • Jednostránkové aplikace využívající ADAL.js

Následující části popisují běžné scénáře, které jsou složitější. Základním provozním principem je, že zásady podmíněného přístupu se vyhodnocují v okamžiku, kdy je token požadován pro službu, která má použité zásady podmíněného přístupu.

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

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

Aplikace provádějící vývojový diagram on-behalf-of

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

Azure AD 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 široká škála možných týkajících se podmíněného interaction_required 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 odešleme výzvu zpět claims do desktopové aplikace. V tomto okamžiku může desktopová aplikace provést nové acquireToken() volání a připojit claimsvýzvu jako další parametr řetězce dotazu. Tento nový požadavek vyžaduje, aby uživatel udělal vícefaktorové ověřování a pak odeslal tento nový token 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 vaší logice aplikace může existovat cesta, ve které aplikace nevyžaduje přístup k oběma webovým službám. V tomto scénáři hraje pořadí, ve kterém požadujete token, důležitou roli v prostředí koncového uživatele.

Předpokládejme, že máme webové služby A a B a webová služba B má použité zásady podmíněného přístupu. I když počáteční žádost o interaktivní ověřování 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, vyvolá se zásada a následné požadavky na webovou službu A budou také úspěšné následujícím způsobem.

Vývojový diagram aplikace přistupující k více službám

Případně pokud aplikace zpočátku požádá o token pro webovou službu A, koncový uživatel zásady podmíněného přístupu nevyvolá. To umožňuje vývojáři aplikace řídit prostředí koncového uživatele a nenutit vyvolání zásad podmíněného přístupu ve všech případech. Složitým případem je, když aplikace následně 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ěnou na 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>"]}}}

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

Pokud aplikace používá knihovnu ADAL, selhání získání tokenu se vždy interaktivně opakuje. Když dojde k tomuto interaktivnímu požadavku, má koncový uživatel možnost vyhovět podmíněnému přístupu. To platí, pokud se nejedná o AcquireTokenSilentAsync požadavek nebo PromptBehavior.Never v takovém případě aplikace potřebuje provést interaktivní AcquireToken požadavek, aby koncový uživatel mohl zásady dodržovat.

Scénář: Jednostránková aplikace (SPA) s využitím ADAL.js

V tomto scénáři si projdeme případ, kdy máme jednostránkovou aplikaci (SPA), která používá ADAL.js k volání webového rozhraní API chráněného podmíněným přístupem. Jedná se o jednoduchou architekturu, ale má určité nuance, které je potřeba vzít v úvahu při vývoji podmíněného přístupu.

V ADAL.js existuje několik funkcí, které získávají tokeny: login(), acquireToken(...), acquireTokenPopup(…)a acquireTokenRedirect(…).

  • login() získá token ID prostřednictvím interaktivní žádosti o přihlášení, ale nezíseká přístupové tokeny pro žádnou službu (včetně webového rozhraní API chráněného podmíněným přístupem).
  • acquireToken(…) lze pak použít k tichému získání přístupového tokenu, což znamená, že za žádných okolností nezobrazuje uživatelské rozhraní.
  • 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 acquireToken(…). Pokud vypršela platnost relace tokenu nebo potřebujeme dodržovat zásady podmíněného přístupu, funkce acquireToken selže a aplikace použije acquireTokenPopup() nebo acquireTokenRedirect().

Jednostránková aplikace s využitím vývojového diagramu ADAL

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 login() volání, získáme token ID bez vícefaktorového ověřování. Uživatel pak stiskne tlačítko, které vyžaduje, aby aplikace požadovala data z webového rozhraní API. Aplikace se pokusí provést volání, acquireToken() ale selže, protože uživatel ještě neprovede vícefaktorové ověřování a musí dodržovat zásady podmíněného přístupu.

Azure AD 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() na stejném prostředku. Uživatel je nucen provést vícefaktorové ověřování. Po dokončení vícefaktorového ověřování se aplikaci pro požadovaný prostředek vystaví nový přístupový token.

Pokud si chcete tento scénář vyzkoušet, podívejte se na ukázku kódu JS SPA On-behalf-of. Tento ukázkový kód k předvedení tohoto scénáře používá zásady podmíněného přístupu a webové rozhraní API, které jste zaregistrovali dříve v JS SPA. Ukazuje, jak správně zpracovat výzvu deklarací identity a získat přístupový token, který lze použít pro webové rozhraní API. Případně si projděte ukázku obecného kóduAngular.js, kde najdete pokyny k Angular SPA.

Viz také