Utvecklarguide för autentiseringskontext för villkorsstyrd åtkomst

  • Artikel

Villkorsstyrd åtkomst är det Nolltillit kontrollplanet som gör att du kan rikta principer för åtkomst till alla dina appar – gamla eller nya, privata eller offentliga, lokala eller multimoln. Med autentiseringskontexten för villkorsstyrd åtkomst kan du tillämpa olika principer i dessa appar.

Med autentiseringskontexten för villkorsstyrd åtkomst (autentiseringskontext) kan du tillämpa detaljerade principer på känsliga data och åtgärder i stället för bara på appnivå. Du kan förfina dina Nolltillit 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 använder OpenId Anslut för autentisering som utvecklats av ditt företag för att skydda känsliga resurser, till exempel transaktioner med högt värde eller visning av personliga data för anställda.

Om du vill utlösa en stegvis autentisering inifrån dina program och tjänster använder du Microsoft Entra-motorns autentiseringskontextfunktion. Utvecklare har nu kraften att kräva förbättrad starkare autentisering, selektivt, som 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örerna och tillsynsmyndigheterna kämpar ofta mellan att balansera frågor till sina användare med extra autentiseringsfaktorer för ofta och uppnå tillräcklig säkerhet och principefterlevnad för program och tjänster där delar av dem innehåller känsliga data och åtgärder. Det kan vara ett val mellan en stark princip som påverkar användarnas produktivitet när de får åtkomst till de flesta data och åtgärder eller en princip som inte är tillräckligt stark för känsliga resurser.

Så vad händer om appar kunde blanda båda, där de kan fungera med en relativt mindre säkerhet och mindre frekventa uppmaningar för de flesta användare och åtgärder och ändå villkorligt öka säkerhetskravet när användarna har åtkomst till känsligare delar?

Vanliga scenarier

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

Förutsättningar

Först bör din app integreras med Microsofts identitetsplattform med hjälp av OpenID-Anslut/ OAuth 2.0-protokoll för autentisering och auktorisering. Vi rekommenderar att du använder Microsofts identitetsplattform autentiseringsbibliotek 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 villkorlig åtkomst autentiseringskontext bygger på protokolltillägg som tillhandahålls av branschstandarden OpenID Anslut protokoll. Utvecklare använder ett referensvärde för villkorsstyrd åtkomstautentiseringskontext med parametern Anspråksbegäran för att ge appar ett sätt att utlösa och uppfylla principen.

För det andra kräver villkorsstyrd åtkomst 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. Program som autentiseras som sig själva stöds inte. Använd guiden Autentiseringsflöden och programscenarier för att lära dig mer om de typer och flöden för autentiseringsappar som stöds i Microsofts identitetsplattform.

Integreringssteg

När programmet har integrerats med de autentiseringsprotokoll som stöds och registrerats i en Microsoft Entra-klientorganisation som har funktionen villkorlig åtkomst tillgänglig för användning, kan du starta processen för att integrera den här funktionen i dina program som loggar in användare.

Kommentar

En detaljerad genomgång av den här funktionen är också tillgänglig som en inspelad session på Use Conditional Access Auth Context in your app for step-up authentication (Använd villkorsstyrd åtkomstautentiseringskontext i din app för stegvis autentisering).

Deklarera först och gör autentiseringskontexterna tillgängliga i din klientorganisation. 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 kompatibla enheter
  • C3 – Kräv betrodda platser

Skapa eller ändra dina principer för villkorlig åtkomst för att använda autentiseringskontexter för villkorsstyrd åtkomst. Exempelprinciper kan vara:

  • Alla användare som loggar in på det här webbprogrammet bör ha slutfört 2FA för autentiseringskontext-ID C1.
  • Alla användare som loggar in på det här webbprogrammet bör ha slutfört 2FA och även komma åt webbappen från ett visst IP-adressintervall för autentiseringskontext-ID C3.

Kommentar

Kontextvärdena för villkorlig åtkomst deklareras och underhålls separat från program. Det är inte lämpligt att program är beroende av autentiseringskontext-ID:er. Principerna för villkorsstyrd åtkomst skapas vanligtvis av IT-administratörer eftersom de har en bättre förståelse för de resurser som är tillgängliga för att tillämpa principer på. För en Microsoft Entra-klientorganisation skulle IT-administratörer till exempel ha kunskap om hur många av klientorganisationens användare som är utrustade för att använda 2FA för MFA och därmed kan säkerställa att principer för villkorsstyrd åtkomst som kräver 2FA är begränsade till dessa utrustade användare. På samma sätt kan autentiseringskontext-ID:erna som används vara olika och i vissa fall inte tillgängliga alls om programmet används i flera klientorganisationer.

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:

  1. Identitetså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 på hur det går till.

De här stegen är de ändringar som du behöver utföra i din kodbas. Stegen består i stort sett av

  • Fråga MS Graph om du vill 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 mot tillgängliga autentiseringskontexter med hjälp av principer för villkorsstyrd åtkomst.
  • Spara den här mappningsinformationen i databasen/det lokala arkivet.

Installationsflöde för att skapa en autentiseringskontext

För det tredje: Ditt program, och för det här exemplet antar vi att det är ett webb-API, sedan måste utvärdera anrop mot den sparade mappningen och därmed skapa anspråksutmaningar 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 anspråksutmaning enligt följande kodfragment.

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

    Diagram som visar interaktionen mellan användare, webbapp, API och Microsoft Entra-ID

    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 i CheckForRequiredAuthContext() API:et

    • Kontrollerar om programmets åtgärd som anropas kräver stegvis 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 acrs-anspråket efter ett befintligt, matchande Auth-kontext-ID.
    • Om ett matchande Auth-kontext-ID inte hittas genereras en anspråksutmaning.
    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");
            }
        }
    }
}

    Kommentar

    Formatet för anspråksutmaningen beskrivs i artikeln Anspråksutmaning i Microsofts identitetsplattform.

  3. I klientprogrammet kan du fånga upp anspråksutmaningen 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 stegvis 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 anspråksutmaning 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 resursprovidrar (RP) som vårt webb-API ovan att identifiera om det anropande 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:er-klienter kan hantera anspråksutmaningar 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 viktig för program med flera klientorganisationer. Auth Context-värdena varierar mellan Microsoft Entra-klienter och kommer inte att vara 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 kontexten för villkorlig åtkomstautentisering för att utföra stegvis autentisering som hur en app ska fråga, ange och använda autentiseringskontext i koden.

Använd inte autentiseringskontexten 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 ett högre autentiseringsfält.

Kodexempel

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

Explicit autentiseringskontexttillfredsställelse i begäranden

En klient kan uttryckligen be om en token med Auth Context (ACRS) via anspråken i begärandetexten. Om en ACRS begärdes tillåter villkorsstyrd åtkomst utfärdande av token med den begärda ACRS om alla utmaningar har slutförts.

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 principer för villkorsstyrd åtkomst som tilldelats till ACRS-värdet har uppfyllts. Om ingen princip för villkorlig åtkomst har tilldelats till ett ACRS-värde kan anspråket fortfarande utfärdas, eftersom alla principkrav har uppfyllts.

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

ACRS begärdes Princip som tillämpas Kontrollen är uppfylld ACRS har lagts till i anspråk
Ja No Ja Ja
Ja Ja Nej Nej
Ja Ja Ja Ja
Ja Inga principer har konfigurerats med ACRS Ja Ja

Implicit autentiseringskontextnöjdhet efter opportunistisk utvärdering

En resursprovider kan välja det valfria "acrs"-anspråket. 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 så fall.

Kommentar

Varje tokentyp måste vara individuellt anmäld (ID-token, åtkomsttoken).

Om en resursprovider inte väljer det valfria "acrs"-anspråket är det enda sättet att hämta en ACRS i token att uttryckligen be om det i en tokenbegäran. Den får inte fördelarna med den opportunistiska utvärderingen. Varje gång den nödvändiga ACRS saknas i tokenanspråken kommer resursprovidern därför att uppmana klienten att skaffa en ny token som innehåller den i anspråken.

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

Inloggningsfrekvens efter intervall

Villkorsstyrd åtkomst anser att "inloggningsfrekvens efter intervall" är uppfyllt för opportunistisk ACRS-utvärdering när alla nuvarande autentiseringsfaktorer autentiserings instants ligger inom intervallet för inloggningsfrekvens. Om den första faktorautentiseringen är inaktuell, eller om den andra faktorn (MFA) finns och dess autentiserings instant är inaktuell, uppfylls inte inloggningsfrekvensen efter intervall och ACRS utfärdas inte i token opportunistiskt.

Cloud App Security (CAS)

Villkorsstyrd åtkomst kommer att betrakta CAS-sessionskontrollen som uppfylld för opportunistisk ACRS-utvärdering, när en CAS-session upprättades under den begäran. Till exempel när en begäran kommer in och en princip för villkorsstyrd åtkomst tillämpas och framtvingas 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, som uppfyller 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.

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

Flow ACRS begärdes Princip som tillämpas Kontrollen är uppfylld ACRS har lagts till i anspråk
Ariel begär en åtkomsttoken "c1" Ingen Ja för "c1". Nej för "c2" och "c3" "c1" (begärd)
Ariel begär en åtkomsttoken "c2" Policy B Blockerad av princip B Ingen
Ariel begär en åtkomsttoken Ingen Ingen Ja för "c1". Nej för "c2" och "c3" "c1" (opportunistiskt tillagd från princip A)
Jay begär en åtkomsttoken (utan MFA) "c1" Policy A Nej Ingen
Jay begär en åtkomsttoken (med MFA) "c1" Policy A Ja "c1" (begärd), "c2" (opportunistiskt tillagd från princip B), "c3" (opportunistiskt tillagd från princip B)
Jay begär en åtkomsttoken (utan MFA) "c2" Ingen Ja för "c2" och "c3". Nej för "c1" "c2" (begärd), "c3" (opportunistiskt tillagd från princip B)
Jay begär en åtkomsttoken (med MFA) "c2" Ingen Ja för "c1", "c2" och "c3" "c1" (bästa insats från A), "c2" (begärd), "c3" (opportunistiskt tillagd från princip B)
Jay begär en åtkomsttoken (med MFA) Ingen Ingen Ja för "c1", "c2" och "c3" "c1", "c2", "c3" alla opportunistiskt tillagda
Jay begär en åtkomsttoken (utan MFA) Ingen Ingen Ja för "c2" och "c3". Nej för "c1" "c2", "c3" alla opportunistiskt tillagda

Nästa steg