Utvecklarguide för autentiseringskontext i Conditional Access

Gäller för: Externa klienter (läs mer)

Conditional Access är Nulová dôvera (Zero Trust)-kontrollplanet som gör att du kan rikta principer för åtkomst till alla dina appar – gamla eller nya, privata eller offentliga, lokala eller i multicloud. Med autentiseringskontexten för villkorsstyrd åtkomst kan du tillämpa olika policyer i dessa appar.

Med autentiseringskontexten för villkorsstyrd åtkomst (autentiseringskontext) kan du tillämpa detaljerade policyer på känsliga data och åtgärder i stället för bara på appnivå. Du kan förfina dina Nulová dôvera (Zero Trust)-principer för minst privilegierad åtkomst samtidigt som du minimerar användarfriktionen och håller användarna mer produktiva och dina resurser säkrare. Idag används den av program som har utvecklats av ditt företag och som använder OpenId Connect för autentisering för att skydda känsliga resurser, till exempel transaktioner med högt värde eller visning av personuppgifter för anställda.

För att utlösa en förhöjd autentisering inifrån dina program och tjänster använder du Villkorsstyrd åtkomst i Microsoft Entra-motorns autentiseringskontextfunktion. Utvecklare har nu möjlighet att kräva starkare autentisering, selektivt, till exempel MFA, från sina slutanvändare inifrån sina program. Den här funktionen hjälper utvecklare att skapa smidigare användarupplevelser för de flesta delar av sitt program, samtidigt som åtkomst till säkrare åtgärder och data finns kvar bakom starkare autentiseringskontroller.

Problembeskrivning

IT-administratörer och tillsynsmyndigheter har ofta svårt att balansera att uppmana användare att använda extra autentiseringsfaktorer och uppnå tillräcklig säkerhet och policyefterlevnad för program. Det kan vara ett val mellan en stark princip som påverkar användarnas produktivitet eller en princip som inte är tillräckligt stark för känsliga resurser.

Så vad händer om appar kunde blanda båda? Fungerar med en lägre säkerhetsnivå och färre frågor för de flesta scenarier. Ökar sedan säkerhetskravet villkorligt när känsligare data används?

Vanliga scenarier

Även om användarna till exempel kan logga in på SharePoint med multifaktorautentisering kan åtkomst till en webbplatssamling i SharePoint som innehåller känsliga dokument kräva en enhet som uppfyller kraven och endast vara tillgänglig från betrodda IP-intervall.

Förutsättningar

Först bör appen integreras med Microsofts identitetsplattform med hjälp av protokollen OpenID Connect/ och OAuth 2.0 för autentisering och auktorisering. Vi rekommenderar att du använder autentiseringsbibliotek för Microsoft Identity Platform för att integrera och skydda ditt program med Microsoft Entra-ID. Microsofts identitetsplattform dokumentation är ett bra ställe att börja lära dig hur du integrerar dina appar med Microsofts identitetsplattform. Funktionsstöd för autentiseringskontext för villkorsstyrd åtkomst bygger på protokolltillägg som tillhandahålls av branschstandarden OpenID Connect-protokollet. Utvecklare använder ett referensvärde för autentiseringskontext för villkorsstyrd åtkomstvärde med parametern Claims Request för att ge appar ett sätt att utlösa och uppfylla principen.

För det andra, villkorsstyrd åtkomst kräver Microsoft Entra ID P1-licensiering. Mer information om licensiering finns på prissidan för Microsoft Entra.

För det tredje är den i dag endast tillgänglig för program som loggar in användare. Applikationer som autentiserar som sig själva stöds inte. Använd guiden om autentiseringsflöden och programscenarier om du vill lära dig mer om de typer av autentiseringsappar och flöden som stöds i Microsofts identitetsplattform.

Integrationssteg

Du kan börja integrera den här funktionen i dina program när den har integrerats med de autentiseringsprotokoll som stöds och registrerats i en Microsoft Entra-klient som har funktionen villkorlig åtkomst tillgänglig.

Deklarera först och gör autentiseringskontexterna tillgängliga i din tenant. Mer information finns i Konfigurera autentiseringskontexter.

Värden C1-C99 är tillgängliga för användning som Auth-kontext-ID:er i en klientorganisation. Exempel på autentiseringskontext kan vara:

• C1 – Kräv stark autentisering
• C2 – Kräv enheter som uppfyller kraven
• C3 – Kräv betrodda platser

Om du vill använda autentiseringskontexter för villkorsstyrd åtkomst skapar eller ändrar du dina principer för villkorsstyrd åtkomst. Exempel på policyer kan vara:

• Alla användare som loggar in på det här webbprogrammet måste slutföra 2FA för autentiseringskontext-ID C1.
• Alla användare som loggar in på det här webbprogrammet måste slutföra 2FA och även komma åt appen från ett definierat IP-adressintervall för autentiseringskontext-ID C3.

För det andra: Utvecklarna av ett program som planerar att använda autentiseringskontext för villkorsstyrd åtkomst rekommenderas att först ge programadministratörerna eller IT-administratörerna ett sätt att mappa potentiella känsliga åtgärder till autentiseringskontext-ID:er. Stegen är ungefär följande:

1. Identifiera åtgärder i koden som kan göras tillgängliga för mappning mot autentiseringskontext-ID:er.
2. Skapa en skärm i administratörsportalen för appen (eller motsvarande funktioner) som IT-administratörer kan använda för att mappa känsliga åtgärder mot ett tillgängligt autentiseringskontext-ID.
3. I kodexemplet använder du autentiseringskontexten för villkorsstyrd åtkomst för att utföra stegvis autentisering för ett exempel.

De här stegen är de ändringar som du behöver genomföra i din kodbas. Stegen består i stora drag av

• Fråga MS Graph för att visa en lista över alla tillgängliga autentiseringskontexter.
• Tillåt IT-administratörer att välja känsliga/högprivilegierade åtgärder och tilldela dem till de tillgängliga autentiseringskontexterna med hjälp av principer för villkorsstyrd åtkomst.
• Spara den här mappningsinformationen i databasen/det lokala arkivet.

För det tredje: Ditt program, och för det här exemplet antar vi att det är ett webb-API, måste sedan utvärdera anrop mot den sparade mappningen och därmed skapa claim challenges för sina klientappar. För att förbereda för den här åtgärden ska följande steg vidtas:

1. I en känslig och skyddad åtgärd med autentiseringskontext utvärderar du värdena i acrs-anspråket mot de Auth Context ID-mappningar som sparades tidigare och skapar en Claims Challenge enligt följande kodfragment.

2. Följande diagram visar interaktionen mellan användaren, klientappen och webb-API:et.

   

   Kodfragmentet som följer är från kodexemplet, Använd autentiseringskontexten för villkorsstyrd åtkomst för att utföra stegvis autentisering. Den första metoden, CheckForRequiredAuthContext(), i API:et

   • Kontrollerar om applikationens aktion som anropas kräver step-up-autentisering. Det gör den genom att kontrollera databasen för en sparad mappning för den här metoden
   • Om den här åtgärden verkligen kräver en förhöjd autentiseringskontext kontrollerar den anspråket acrs för ett befintligt, matchande Auth-kontext-ID.
   • Om ett matchande Auth-kontext-ID inte hittas genereras en claims challenge.

   public void CheckForRequiredAuthContext(string method)
   {
       string authType = _commonDBContext.AuthContext.FirstOrDefault(x => x.Operation == method
                   && x.TenantId == _configuration["AzureAD:TenantId"])?.AuthContextId;
   
       if (!string.IsNullOrEmpty(authType))
       {
           HttpContext context = this.HttpContext;
           string authenticationContextClassReferencesClaim = "acrs";
   
           if (context == null || context.User == null || context.User.Claims == null
               || !context.User.Claims.Any())
           {
               throw new ArgumentNullException("No Usercontext is available to pick claims from");
           }
   
           Claim acrsClaim = context.User.FindAll(authenticationContextClassReferencesClaim).FirstOrDefault(x
               => x.Value == authType);
   
           if (acrsClaim == null || acrsClaim.Value != authType)
           {
               if (IsClientCapableofClaimsChallenge(context))
               {
                   string clientId = _configuration.GetSection("AzureAd").GetSection("ClientId").Value;
                   var base64str = Convert.ToBase64String(Encoding.UTF8.GetBytes("{\"access_token\":{\"acrs\":{\"essential\":true,\"value\":\"" + authType + "\"}}}"));
   
                   context.Response.Headers.Append("WWW-Authenticate", $"Bearer realm=\"\", authorization_uri=\"https://login.microsoftonline.com/common/oauth2/authorize\", client_id=\"" + clientId + "\", error=\"insufficient_claims\", claims=\"" + base64str + "\", cc_type=\"authcontext\"");
                   context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
                   string message = string.Format(CultureInfo.InvariantCulture, "The presented access tokens had insufficient claims. Please request for claims requested in the WWW-Authentication header and try again.");
                   context.Response.WriteAsync(message);
                   context.Response.CompleteAsync();
                   throw new UnauthorizedAccessException(message);
               }
               else
               {
                   throw new UnauthorizedAccessException("The caller does not meet the authentication  bar to carry our this operation. The service cannot allow this operation");
               }
           }
       }
   }
   

   Obs!

   Formatet för claims challenge beskrivs i artikeln Claims Challenge i Microsofts identitetsplattform.

3. I klientprogrammet kan du fånga upp en anspråksutmaning och omdirigera användaren tillbaka till Microsoft Entra ID för ytterligare principutvärdering. Kodfragmentet som följer är från kodexemplet, Använd autentiseringskontexten för villkorsstyrd åtkomst för att utföra step-up-autentisering.

   internal static string ExtractHeaderValues(WebApiMsalUiRequiredException response)
   {
       if (response.StatusCode == System.Net.HttpStatusCode.Unauthorized && response.Headers.WwwAuthenticate.Any())
       {
           AuthenticationHeaderValue bearer = response.Headers.WwwAuthenticate.First(v => v.Scheme == "Bearer");
           IEnumerable<string> parameters = bearer.Parameter.Split(',').Select(v => v.Trim()).ToList();
           var errorValue = GetParameterValue(parameters, "error");
   
           try
           {
               // read the header and checks if it contains error with insufficient_claims value.
               if (null != errorValue && "insufficient_claims" == errorValue)
               {
                   var claimChallengeParameter = GetParameterValue(parameters, "claims");
                   if (null != claimChallengeParameter)
                   {
                       var claimChallenge = ConvertBase64String(claimChallengeParameter);
   
                       return claimChallenge;
                   }
               }
           }
           catch (Exception ex)
           {
               throw ex;
           }
       }
       return null;
   }
   

   Hantera undantag i anropet till webb-API:et. Om en claims challenge visas omdirigerar du användaren tillbaka till Microsoft Entra ID för vidare bearbetning.

   try
   {
       // Call the API
       await _todoListService.AddAsync(todo);
   }
   catch (WebApiMsalUiRequiredException hex)
   {
       // Challenges the user if exception is thrown from Web API.
       try
       {
           var claimChallenge =ExtractHeaderValues(hex);
           _consentHandler.ChallengeUser(new string[] { "user.read" }, claimChallenge);
   
           return new EmptyResult();
       }
       catch (Exception ex)
       {
           _consentHandler.HandleException(ex);
       }
   
       Console.WriteLine(hex.Message);
   }
   return RedirectToAction("Index");
   

4. (Valfritt) Deklarera klientkapacitet. Klientfunktioner hjälper resursproviders (RP) som vårt webb-API att identifiera om klientprogrammet förstår anspråksutmaningen och sedan kan anpassa sitt svar i enlighet med detta. Den här funktionen kan vara användbar om inte alla API-klienter kan hantera claim-utmaningar och vissa äldre fortfarande förväntar sig ett annat svar. Mer information finns i avsnittet Klientfunktioner.

Varningar och rekommendationer

Hårdkoda inte autentiseringskontextvärden i din app. Appar bör läsa och tillämpa autentiseringskontext med hjälp av MS Graph-anrop. Den här metoden är avgörande för multitenant-applikationer. Autentiseringskontextvärdena varierar mellan Microsoft Entra-klienter och är inte tillgängliga i Microsoft Entra ID Free Edition. Mer information om hur en app ska fråga, ställa in och använda autentiseringskontext i koden finns i kodexemplet , Använd autentiseringskontexten för villkorsstyrd åtkomst för att utföra stegvis autentisering.

Använd inte autentiseringskontext där själva appen kommer att vara ett mål för principer för villkorsstyrd åtkomst. Funktionen fungerar bäst när delar av programmet kräver att användaren uppfyller högre autentiseringskrav.

Kodexempel

• Använd autentiseringskontexten för villkorlig åtkomst för att utföra stegvis autentisering för åtgärder med hög behörighet i en webbapp
• Använd autentiseringskontexten för villkorlig åtkomst för att utföra stegvis autentisering för åtgärder med hög behörighet i ett webb-API
• Använd autentiseringskontexten för villkorsstyrd åtkomst för att utföra stegvis autentisering för åtgärder med höga privilegier i ett React-program på en sida och ett Express-webb-API

Förväntat beteende för autentiseringskontext [ACRs] i villkorsstyrd åtkomst

Uppfyllande av explicit autentiseringskontext i förfrågningar

En klient kan uttryckligen be om en token med Auth Context (ACRS) via claims i request body. Om en ACRS har begärts, tillåter villkorsstyrd åtkomst att token utfärdas med den angivna ACRS om alla utmaningar är slutförda.

Förväntat beteende när en autentiseringskontext inte skyddas av villkorlig åtkomst i klientorganisationen

Villkorsstyrd åtkomst kan utfärda en ACRS i en tokens anspråk när alla policyer för villkorsstyrd åtkomst som har tilldelats till ACRS-värdet är uppfyllda. Om ingen princip för villkorlig åtkomst har tilldelats ett ACRS-värde kan anspråket fortfarande utfärdas eftersom alla principkrav är uppfyllda.

Sammanfattningstabell för förväntat beteende när ACRS uttryckligen begärs

Implicit uppfyllande av autentiseringskontext genom opportunistisk utvärdering

En resursprovider kan välja att använda det valfria "acrs"-claimet. Villkorsstyrd åtkomst försöker lägga till ACRS i tokenanspråken opportunistiskt för att undvika tur och retur för att hämta nya token till Microsoft Entra-ID. I den utvärderingen kontrollerar Villkorsstyrd åtkomst om principerna som skyddar Auth Context-utmaningar redan är uppfyllda och lägger till ACRS i tokenanspråken i token i så fall.

Förväntat beteende med autentiseringskontext och sessionskontroller för implicit ACRS-opportunistisk utvärdering

Inloggningsfrekvens efter intervall

Villkorlig åtkomst anser att "inloggningsfrekvens per intervall" är uppfyllt för opportunistisk ACRS-utvärdering när alla aktuella autentiseringsfaktorers autentiseringstidpunkter ligger inom intervallet för inloggningsfrekvens. Om någon av autentiseringsfaktorerna är inaktuell uppfylls inte inloggningsfrekvensen efter intervall, och ACRS kommer inte att opportunistiskt utfärdas i token.

Cloud App Security (CAS)

Villkorsstyrd åtkomst betraktar CAS-sessionskontrollen som uppfylld för opportunistisk ACRS-utvärdering när en CAS-session upprättades under denna förfrågan. Till exempel, när en begäran kommer in och en princip för villkorsstyrd åtkomst tillämpas och framtvingar en CAS-session, och dessutom finns det en princip för villkorsstyrd åtkomst som också kräver en CAS-session. Eftersom CAS-sessionen kommer att tillämpas, uppfylls CAS-sessionskontrollen för den opportunistiska utvärderingen.

Förväntat beteende när en klientorganisation innehåller principer för villkorlig åtkomst som skyddar autentiseringskontexten

Tabellen nedan visar alla hörnfall där ACRS läggs till i tokens anspråk efter opportunistisk utvärdering.

Policy A: Kräv MFA från alla användare, exklusive användaren "Ariel", vid begäran om "c1"-acrs. Policy B: Blockera alla användare, exklusive användaren "Jay", när du frågar efter "c2" eller "c3" acrs.

Nästa steg

• Detaljerad villkorlig åtkomst för känsliga data och åtgärder (blogg)
• Zero Trust med Microsofts identitetsplattform
• Bygg Nulová dôvera (Zero Trust)-redo appar med Microsofts identitetsplattform
• Autentiseringskontext för villkorsstyrd åtkomst
• resurstypen authenticationContextClassReference - MS Graph
• Claims challenge, claims request och klientfunktioner i Microsofts identitetsplattform
• Använda autentiseringskontext med Microsoft Purview Information Protection och SharePoint
• Så här använder du API:er för kontinuerlig åtkomstutvärdering i dina program