Utvecklarvägledning för funktionen Azure AD villkorlig åtkomst

  • Artikel

Varning

Det här innehållet gäller för den äldre Azure AD v1.0-slutpunkten. Använd Microsofts identitetsplattform för nya projekt.

Anteckning

Den Microsofts identitetsplattform versionen av den här artikeln finns i Utvecklarvägledning för Microsoft Entra villkorlig åtkomst.

Funktionen villkorlig åtkomst i Microsoft Entra ID erbjuder ett av flera sätt som du kan använda för att skydda din app och skydda en tjänst. Villkorsstyrd åtkomst gör det möjligt för utvecklare och företagskunder att skydda tjänster på många olika sätt, bland annat:

  • Multifaktorautentisering
  • Tillåta att endast Intune-registrerade enheter får åtkomst till specifika tjänster
  • Begränsa användarplatser och IP-intervall

Mer information om de fullständiga funktionerna i villkorsstyrd åtkomst finns i Vad är villkorsstyrd åtkomst.

För utvecklare som skapar appar för Azure AD visar den här artikeln hur du kan använda villkorsstyrd åtkomst och du får också lära dig om effekten av att komma åt resurser som du inte har kontroll över som kan ha principer för villkorsstyrd åtkomst tillämpade. Artikeln utforskar också konsekvenserna av villkorsstyrd åtkomst i flödets räkning, webbappar, åtkomst till Microsoft Graph och anrop av API:er.

Kunskap om appar med en och flera klientorganisationer och vanliga autentiseringsmönster förutsätts .

Hur påverkar villkorsstyrd åtkomst en app?

Apptyper påverkas

I de flesta fall ändrar inte villkorsstyrd åtkomst appens beteende eller kräver ändringar från utvecklaren. Endast i vissa fall när en app indirekt eller tyst begär en token för en tjänst kräver en app kodändringar för att hantera "utmaningar" med villkorsstyrd åtkomst. Det kan vara så enkelt som att utföra en interaktiv inloggningsbegäran.

Mer specifikt kräver följande scenarier kod för att hantera "utmaningar med villkorsstyrd åtkomst":

  • Appar som utför flödets räkning
  • Appar som har åtkomst till flera tjänster/resurser
  • Ensidesappar med ADAL.js
  • Web Apps anropa en resurs

Principer för villkorsstyrd åtkomst kan tillämpas på appen, men kan även tillämpas på ett webb-API som appen har åtkomst till. Mer information om hur du konfigurerar en princip för villkorsstyrd åtkomst finns i Vanliga principer för villkorlig åtkomst.

Beroende på scenariot kan en företagskund när som helst tillämpa och ta bort principer för villkorsstyrd åtkomst. För att appen ska kunna fortsätta att fungera när en ny princip tillämpas måste du implementera hanteringen av utmaningen. Följande exempel illustrerar utmaningshantering.

Exempel på villkorsstyrd åtkomst

Vissa scenarier kräver kodändringar för att hantera villkorsstyrd åtkomst medan andra fungerar som de är. Här är några scenarier som använder villkorsstyrd åtkomst för att utföra multifaktorautentisering som ger viss inblick i skillnaden.

  • Du skapar en iOS-app för en enda klientorganisation och tillämpar en princip för villkorsstyrd åtkomst. Appen loggar in en användare och begär inte åtkomst till ett API. När användaren loggar in anropas principen automatiskt och användaren måste utföra multifaktorautentisering (MFA).
  • Du skapar en inbyggd app som använder en mellannivåtjänst för att få åtkomst till ett underordnat API. En företagskund på företaget som använder den här appen tillämpar en princip på det underordnade API:et. När en slutanvändare loggar in begär den inbyggda appen åtkomst till mellannivån och skickar token. Mellannivån utför ett flöde för att begära åtkomst till det underordnade API:et. Nu presenteras en "utmaning" för anspråk på mellannivån. Mellannivån skickar tillbaka utmaningen till den inbyggda appen, som måste följa principen för villkorsstyrd åtkomst.

Microsoft Graph

Microsoft Graph har särskilda överväganden när du skapar appar i miljöer för villkorsstyrd åtkomst. I allmänhet fungerar mekaniken för villkorsstyrd åtkomst på samma sätt, men de principer som användarna ser baseras på underliggande data som appen begär från diagrammet.

Mer specifikt representerar alla Microsoft Graph-omfång vissa datauppsättningar som kan tillämpas individuellt. Eftersom principer för villkorsstyrd åtkomst tilldelas de specifika datauppsättningarna framtvingar Azure AD principer för villkorsstyrd åtkomst baserat på data bakom Graph – i stället för själva Graph.

Om en app till exempel begär följande Microsoft Graph-omfång

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

En app kan förvänta sig att användarna uppfyller alla principer som anges i Bookings och Exchange. Vissa omfång kan mappas till flera datauppsättningar om de ger åtkomst.

Följa en princip för villkorsstyrd åtkomst

För flera olika apptopologier utvärderas en princip för villkorsstyrd åtkomst när sessionen upprättas. När en princip för villkorsstyrd åtkomst fungerar på kornigheten för appar och tjänster beror den punkt där den anropas starkt på det scenario som du försöker åstadkomma.

När din app försöker komma åt en tjänst med en princip för villkorsstyrd åtkomst kan den stöta på en utmaning för villkorsstyrd åtkomst. Den här utmaningen kodas i parametern claims som kommer i ett svar från Azure AD. Här är ett exempel på den här utmaningsparametern:

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

Utvecklare kan anta den här utmaningen och lägga till den i en ny begäran till Azure AD. Om det här tillståndet skickas uppmanas slutanvändaren att utföra alla åtgärder som krävs för att följa principen för villkorsstyrd åtkomst. I följande scenarier förklaras detaljer om felet och hur du extraherar parametern.

Scenarier

Förutsättningar

Microsoft Entra villkorlig åtkomst är en funktion som ingår i Microsoft Entra ID P1 eller P2. Du kan lära dig mer om licensieringskrav i den olicensierade användningsrapporten. Utvecklare kan ansluta till Microsoft Developer Network, som innehåller en kostnadsfri prenumeration på Enterprise Mobility Suite, som innehåller Microsoft Entra ID P1 eller P2.

Överväganden för specifika scenarier

Följande information gäller endast i dessa scenarier för villkorsstyrd åtkomst:

  • Appar som utför flödets räkning
  • Appar som har åtkomst till flera tjänster/resurser
  • Ensidesappar med ADAL.js

I följande avsnitt beskrivs vanliga scenarier som är mer komplexa. Huvudprincipen för drift är principer för villkorsstyrd åtkomst utvärderas när token begärs för tjänsten som har en princip för villkorsstyrd åtkomst tillämpad.

Scenario: App som utför on-behalf-of-flödet

I det här scenariot går vi igenom det fall där en intern app anropar en webbtjänst/API. I sin tur utför den här tjänsten flödet "å-behalf-of" för att anropa en underordnad tjänst. I vårt fall har vi tillämpat vår princip för villkorsstyrd åtkomst på den underordnade tjänsten (Webb-API 2) och använder en intern app i stället för en server/daemon-app.

App som utför flödesdiagrammet för räkning

Den första tokenbegäran för Webb-API 1 frågar inte slutanvändaren om multifaktorautentisering eftersom Webb-API 1 kanske inte alltid når det underordnade API:et. När Webb-API 1 försöker begära en token för användarens räkning för Webb-API 2 misslyckas begäran eftersom användaren inte har loggat in med multifaktorautentisering.

Azure AD returnerar ett HTTP-svar med intressanta data:

Anteckning

I det här fallet är det en felbeskrivning för multifaktorautentisering, men det finns en mängd olika interaction_required möjliga samband med villkorsstyrd åtkomst.

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>"]}}}

I Webb-API 1 får vi felet error=interaction_requiredoch skickar tillbaka claims uppgiften till skrivbordsappen. Då kan skrivbordsappen göra ett nytt acquireToken() anrop och lägga till claimsutmaningen som en extra frågesträngsparameter. Den här nya begäran kräver att användaren utför multifaktorautentisering och sedan skickar tillbaka den här nya token till Webb-API 1 och slutför flödets räkning.

Information om hur du provar det här scenariot finns i vårt .NET-kodexempel. Den visar hur du skickar tillbaka anspråksutmaningen från Webb-API 1 till den interna appen och skapar en ny begäran i klientappen.

Scenario: App som har åtkomst till flera tjänster

I det här scenariot går vi igenom det fall där en webbapp har åtkomst till två tjänster, varav en har en tilldelad princip för villkorsstyrd åtkomst. Beroende på din applogik kan det finnas en sökväg där din app inte kräver åtkomst till båda webbtjänsterna. I det här scenariot spelar den ordning i vilken du begär en token en viktig roll i slutanvändarupplevelsen.

Anta att webbtjänsten A och B och webbtjänsten B har vår princip för villkorsstyrd åtkomst tillämpad. Den första interaktiva autentiseringsbegäran kräver medgivande för båda tjänsterna, men principen för villkorsstyrd åtkomst krävs inte i alla fall. Om appen begär en token för webbtjänsten B anropas principen och efterföljande begäranden för webbtjänsten A lyckas också på följande sätt.

Flödesdiagram för appåtkomst till flera tjänster

Om appen först begär en token för webbtjänsten A anropar inte slutanvändaren principen för villkorsstyrd åtkomst. Detta gör att apputvecklaren kan styra slutanvändarupplevelsen och inte tvinga principen för villkorsstyrd åtkomst att anropas i alla fall. Det svåra fallet är om appen senare begär en token för webbtjänst B. Nu måste slutanvändaren följa principen för villkorsstyrd åtkomst. När appen försöker acquireTokenkan det generera följande fel (illustreras i följande 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 multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App som använder flera tjänster och begär en ny token

Om appen använder ADAL-biblioteket görs alltid ett nytt försök att hämta token interaktivt. När den här interaktiva begäran inträffar har slutanvändaren möjlighet att följa den villkorliga åtkomsten. Detta är sant om inte begäran är en AcquireTokenSilentAsync eller PromptBehavior.Never i vilket fall appen behöver utföra en interaktiv AcquireToken begäran för att ge slutanvändaren möjlighet att följa principen.

Scenario: Ensidesapp (SPA) med ADAL.js

I det här scenariot går vi igenom fallet när vi har en ensidesapp (SPA), med ADAL.js för att anropa ett webb-API för villkorlig åtkomst. Det här är en enkel arkitektur men har vissa nyanser som måste beaktas när du utvecklar kring villkorsstyrd åtkomst.

I ADAL.js finns det några funktioner som hämtar token: login(), acquireToken(...), acquireTokenPopup(…)och acquireTokenRedirect(…).

  • login() hämtar en ID-token via en interaktiv inloggningsbegäran men hämtar inte åtkomsttoken för någon tjänst (inklusive ett webb-API för villkorlig åtkomst).
  • acquireToken(…) kan sedan användas för att tyst hämta en åtkomsttoken, vilket innebär att användargränssnittet inte visas under några omständigheter.
  • acquireTokenPopup(…) och acquireTokenRedirect(…) används båda för att interaktivt begära en token för en resurs, vilket innebär att de alltid visar inloggningsgränssnittet.

När en app behöver en åtkomsttoken för att anropa ett webb-API försöker den använda en acquireToken(…). Om tokensessionen har upphört att gälla eller om vi måste följa en princip för villkorsstyrd åtkomst misslyckas funktionen acquireToken och appen använder acquireTokenPopup() eller acquireTokenRedirect().

Ensidesapp med ADAL-flödesdiagram

Nu ska vi gå igenom ett exempel med vårt scenario för villkorsstyrd åtkomst. Slutanvändaren landade precis på webbplatsen och har ingen session. Vi utför ett login() anrop och hämtar en ID-token utan multifaktorautentisering. Sedan trycker användaren på en knapp som kräver att appen begär data från ett webb-API. Appen försöker utföra ett acquireToken() anrop men misslyckas eftersom användaren inte har utfört multifaktorautentisering ännu och måste följa principen för villkorsstyrd åtkomst.

Azure AD skickar tillbaka följande HTTP-svar:

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>'.

Vår app måste fånga error=interaction_required. Programmet kan sedan använda antingen acquireTokenPopup() eller acquireTokenRedirect() på samma resurs. Användaren tvingas utföra en multifaktorautentisering. När användaren har slutfört multifaktorautentiseringen utfärdas appen en ny åtkomsttoken för den begärda resursen.

Om du vill prova det här scenariot kan du läsa vårt JS SPA-kodexempel för räkning. Det här kodexemplet använder principen för villkorsstyrd åtkomst och webb-API som du registrerade tidigare med ett JS SPA för att demonstrera det här scenariot. Den visar hur du hanterar anspråksutmaningen korrekt och hämtar en åtkomsttoken som kan användas för webb-API:et. Du kan också checka ut det allmänna Angular.js kodexemplet för vägledning om ett Angular SPA

Se även