Anleitung für Entwickler zum Authentifizierungskontext für bedingten Zugriff

  • Artikel

Bedingter Zugriff ist die Zero Trust-Steuerungsebene, mit der Sie Richtlinien für den Zugriff auf all Ihre Apps festlegen können – alt oder neu, privat oder öffentlich, lokal oder in mehreren Clouds. Mit Authentifizierungskontext für bedingten Zugriff können Sie innerhalb dieser Apps verschiedene Richtlinien anwenden.

Mit Authentifizierungskontext für bedingten Zugriff (Authentifizierungskontext) können Sie differenzierte Richtlinien auf vertrauliche Daten und Aktionen anwenden, anstatt nur auf Anwendungsebene. Sie können Zero Trust-Richtlinien für den Zugriff mit den geringsten Rechten genauer festlegen und gleichzeitig Benutzerkonflikte minimieren, die Produktivität der Benutzer erhöhen und die Sicherheit von Ressourcen optimieren. Heute wird der Authentifizierungskontext von Anwendungen verwendet, bei denen OpenID Connect für Authentifizierungsfunktionen eingesetzt wird, die Ihr Unternehmen entwickelt hat, um vertrauliche Ressourcen zu schützen, z. B. für hochwertige Transaktionen oder die Anzeige personenbezogener Daten von Mitarbeitern.

Verwenden Sie das neue Feature „Authentifizierungskontext“ der Microsoft Entra-Engine für bedingten Zugriff, um eine Step-up-Authentifizierung aus Anwendungen und Diensten heraus auszulösen. Entwickler haben jetzt die Möglichkeit, in ihren Anwendungen selektiv eine verbesserte, sicherere Authentifizierung, z. B. mehrstufige Authentifizierung, von den Endbenutzern zu verlangen. Mit diesem Feature können Entwickler für den Großteil ihrer Anwendung die Benutzerfreundlichkeit optimieren, während der Zugriff auf Vorgänge und Daten, die größere Sicherheit erfordern, durch strengere Authentifizierungssteuerungen abgesichert wird.

Problembeschreibung

IT-Administratoren und aufsichtsführende Stellen haben oft Schwierigkeiten, einen Ausgleich bei der Authentifizierung von Benutzern zu schaffen, also Benutzern einerseits nicht zu häufig zusätzliche Authentifizierungsstufen abzuverlangen, andererseits aber ein ausreichendes Sicherheitsniveau und die angemessene Einhaltung von Richtlinien für Anwendungen und Dienste zu gewährleisten, die in Teilen vertrauliche Daten und Vorgänge beinhalten. Die Entscheidung fällt hier gegebenenfalls zwischen einer sicheren Richtlinie, durch die die Produktivität der Benutzer*innen beim Zugriff auf den Großteil der Daten und Aktionen eingeschränkt wird, und einer Richtlinie, die für vertrauliche Ressourcen nicht sicher genug ist.

Was wäre, wenn bei Anwendungen beides kombiniert werden könnte? Soll heißen: Anwendungen funktionieren für die meisten Benutzer und Vorgänge mit einem im Vergleich niedrigeren Sicherheitsniveau und weniger häufigen Eingabeaufforderungen, die Sicherheitsanforderungen werden aber bedingungsbasiert strikter, wenn Benutzer auf vertraulichere Teile zugreifen.

Gängige Szenarios

Beispiel: Benutzer können sich mithilfe der Multi-Faktor-Authentifizierung bei SharePoint anmelden, aber für den Zugriff auf die Websitesammlung in SharePoint, die vertrauliche Dokumente enthält, kann zur Bedingung gemacht werden, dass ein kompatibles Gerät verwendet wird und der Zugriff nur über vertrauenswürdige IP-Adressbereiche erfolgt.

Voraussetzungen

Erstens sollte die App über die OpenID Connect/ OAuth 2.0-Protokolle zur Authentifizierung und Autorisierung in die Microsoft Identity Platform integriert werden. Es empfiehlt sich, die Microsoft Identity Platform-Authentifizierungsbibliotheken zu verwenden, um Ihre Anwendung in Microsoft Entra ID zu integrieren und dort abzusichern. Die Microsoft Identity Platform-Dokumentation ist ein guter Ausgangspunkt, wenn Sie sich damit vertraut machen möchten, wie Sie Anwendungen in die Microsoft Identity Platform integrieren. Die Unterstützung von Authentifizierungskontext für bedingten Zugriff basiert auf Protokollerweiterungen, die vom Branchenstandardprotokoll OpenID Connect bereitgestellt werden. Entwickler verwenden einen für bedingten Zugriff genutzten Authentifizierungskontextverweis-Wert mit dem Anspruchsanforderungsparameter, um für Anwendungen eine Möglichkeit verfügbar zu machen, Richtlinien auszulösen und zu erfüllen.

Zweitens ist für den bedingten Zugriff eine Microsoft Entra ID P1-Lizenz erforderlich. Weitere Informationen zur Lizenzierung finden Sie auf der Seite Microsoft Entra – Preise.

Drittens ist zu beachten, dass er nur für Anwendungen verfügbar ist, bei denen sich Benutzer*innen anmelden. Anwendungen, die sich selbst authentifizieren, werden nicht unterstützt. Verwenden Sie den Leitfaden für Authentifizierungsflows und Anwendungsszenarien, um mehr über die unterstützten App-Typen und Flows zur Authentifizierung in der Microsoft Identity Platform zu erfahren.

Schritte für die Integration

Sobald die Anwendung mithilfe der unterstützten Authentifizierungsprotokolle integriert und in einem Microsoft Entra-Mandanten registriert ist, in dem das Feature für bedingten Zugriff verfügbar ist, können Sie den Prozess starten, um dieses Feature in Anwendungen zu integrieren, bei denen sich Benutzer*innen anmelden.

Hinweis

Eine ausführliche exemplarische Vorgehensweise zu diesem Feature finden Sie auch als aufgezeichnete Sitzung unter Verwenden von Authentifizierungskontext für bedingten Zugriff zum Zweck der Step-up-Authentifizierung in Anwendungen (Englisch).

Erstens: Deklarieren Sie die Authentifizierungskontexte, und machen Sie diese im Mandanten verfügbar. Weitere Informationen finden Sie unter Konfigurieren von Authentifizierungskontexten.

Die Werte C1–C99 sind für die Verwendung als Authentifizierungskontext-IDs in einem Mandanten verfügbar. Beispiele für Authentifizierungskontext:

  • C1: Sichere Authentifizierung erforderlich
  • C2: Kompatible Geräte erforderlich
  • C3: Vertrauenswürdige Standorte erforderlich

Erstellen oder ändern Sie Richtlinien für bedingten Zugriff, um Authentifizierungskontexte für bedingten Zugriff zu verwenden. Mögliche Beispiele für Richtlinien:

  • Alle Benutzer, die sich bei dieser Webanwendung anmelden, müssen die zweistufige Authentifizierung für die Authentifizierungskontext-ID C1 erfolgreich abgeschlossen haben.
  • Alle Benutzer, die sich bei dieser Webanwendung anmelden, müssen die zweistufige Authentifizierung erfolgreich abgeschlossen haben und auch über einen bestimmten IP-Adressbereich für die Authentifizierungskontext-ID C3 auf die Web-App zugreifen.

Hinweis

Die Authentifizierungskontextwerte für bedingten Zugriff werden separat von Anwendungen deklariert und verwaltet. Es ist nicht ratsam, dass Anwendungen eine harte Abhängigkeit von Authentifizierungskontext-IDs aufweisen. Die Richtlinien für bedingten Zugriff werden in der Regel von IT-Administratoren erstellt, da sie über ein besseres Verständnis der Ressourcen verfügen, auf die Richtlinien angewendet werden können. Bei einem Microsoft Entra-Mandanten wissen IT-Administrator*innen beispielsweise, wie viele Benutzer*innen des Mandanten über die Möglichkeit verfügen, die Zwei-Faktor-Authentifizierung (2FA) für MFA-Prozesse zu verwenden. So können sie sicherstellen, dass Richtlinien für bedingten Zugriff, die 2FA erfordern, auf die entsprechend ausgestatteten Benutzer*innen beschränkt werden. Ganz ähnlich gilt: Wenn die Anwendung in mehreren Mandanten verwendet wird, können sich die verwendeten Authentifizierungskontext-IDs unterscheiden und sind in einigen Fällen möglicherweise überhaupt nicht verfügbar.

Zweitens: Den Entwicklern einer Anwendung, die die Verwendung von Authentifizierungskontext für bedingten Zugriff planen, wird empfohlen, zunächst den Anwendungsadministratoren oder IT-Administratoren eine Möglichkeit bereitzustellen, potenzielle vertrauliche Aktionen den Authentifizierungskontext-IDs zuzuordnen. Die entsprechenden Schritte sehen in etwa wie folgt aus:

  1. Identifizieren Sie Aktionen im Code, die zur Zuordnung zu Authentifizierungskontext-IDs verfügbar gemacht werden können.
  2. Erstellen Sie einen Bildschirm im Verwaltungsportal der Anwendung (oder eine entsprechende Funktionalität), die IT-Administratoren verwenden können, um vertrauliche Aktionen einer verfügbaren Authentifizierungskontext-ID zuzuordnen.
  3. Das Codebeispiel unter Verwenden von Authentifizierungskontext für den bedingten Zugriff zum Ausführen einer Step-up-Authentifizierung veranschaulicht die Vorgehensweise.

Diese Schritte entsprechen den Änderungen, die Sie in der Codebasis vornehmen müssen. Die Schritte umfassen im Großen und Ganzen Folgendes:

  • Fragen Sie MS Graph ab, um alle verfügbaren Authentifizierungskontexte aufzulisten.
  • Lassen Sie zu, dass IT-Administratoren vertrauliche Vorgänge bzw. Vorgänge, die umfangreiche Berechtigungen erfordern, auswählen und sie mithilfe von Richtlinien für bedingten Zugriff den verfügbaren Authentifizierungskontexten zuweisen können.
  • Speichern Sie diese Zuordnungsinformationen in Ihrer Datenbank bzw. ihrem lokalen Speicher.

Setupflow zum Erstellen von Authentifizierungskontext

Drittens: Ihre Anwendung (in diesem Beispiel gehen wir von einer Web-API aus) muss dann Aufrufe anhand der gespeicherten Zuordnung auswerten und entsprechende Anspruchsaufforderungen für die zugehörigen Client-Apps auslösen. Zur Vorbereitung auf diese Aktion müssen die folgenden Schritte ausgeführt werden:

  1. Werten Sie in einem vertraulichen und durch Authentifizierungskontext geschützten Vorgang die Werte im acrs-Anspruch anhand der zuvor gespeicherten Zuordnungen der Authentifizierungskontext-IDs aus, und erstellen Sie eine Anspruchsaufforderung, wie im Codeschnipsel unten angegeben.

  2. Die folgende Abbildung zeigt die Interaktion zwischen dem Benutzer, der Clientanwendung und der Web-API.

    Diagramm: Interaktion zwischen Benutzer*in, Web-App, API und Microsoft Entra ID

    Der folgende Codeausschnitt stammt aus dem Codebeispiel unter Verwenden von Authentifizierungskontext für bedingten Zugriff zum Ausführen einer Step-up-Authentifizierung (Englisch). Mit der ersten Methode (CheckForRequiredAuthContext()) in der API

    • Wird überprüft, ob die aufgerufene Aktion der Anwendung eine Step-up-Authentifizierung erfordert. Dies geschieht, indem die Datenbank auf eine gespeicherte Zuordnung für diese Methode überprüft wird.
    • Wenn diese Aktion tatsächlich Authentifizierungskontext mit erhöhten Rechten erfordert, wird der acrs-Anspruch auf eine vorhandene, übereinstimmende Authentifizierungskontext-ID überprüft.
    • Ist keine übereinstimmende Authentifizierungskontext-ID ermittelbar, wird eine Anspruchsaufforderung ausgelöst.
    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");
            }
        }
    }
}

    Hinweis

    Das Format der Anspruchsaufforderung wird im Artikel zur Anspruchsaufforderung in der Microsoft Identity Platform beschrieben.

  3. Fangen Sie die Anspruchsaufforderung in der Clientanwendung ab, und leiten Sie die Benutzer*innen zur weiteren Richtlinienauswertung zurück zu Microsoft Entra ID. Der folgende Codeausschnitt stammt aus dem Codebeispiel unter Verwenden von Authentifizierungskontext für bedingten Zugriff zum Ausführen einer Step-up-Authentifizierung (Englisch).

    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;
}

    Behandeln Sie die Ausnahme im Aufruf der Web-API: Wenn eine Anspruchsaufforderung übermittelt wird, wird der Benutzer bzw. die Benutzerin zur weiteren Verarbeitung zurück an Microsoft Entra ID geleitet.

    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. (Optional) Deklarieren Sie die Clientfunktion. Clientfunktionen helfen Ressourcenanbietern (Resource Provider, RP) wie der obigen Web-API, zu erkennen, ob die aufrufende Clientanwendung die Anspruchsaufforderung versteht und dann ihre Antwort entsprechend anpassen kann. Diese Funktion kann nützlich sein, wenn nicht alle API-Clients Anspruchsaufforderungen bewältigen können und einige ältere Clients weiterhin eine andere Antwort erwarten. Weitere Informationen finden Sie im Abschnitt Clientfunktionen.

Auflagen und Empfehlungen

Verwenden Sie keine Hartcodierung für die Werte des Authentifizierungskontexts in Ihrer App. Authentifizierungskontexte sollten von Apps mithilfe von MS Graph-Aufrufen gelesen und angewendet werden. Diese Vorgehensweise ist für mehrinstanzenfähige Anwendungen von entscheidender Bedeutung. Die Werte des Authentifizierungskontexts variieren zwischen den verschiedenen Microsoft Entra-Mandanten und sind in der kostenlosen Edition von Microsoft Entra ID nicht verfügbar. Weitere Informationen dazu, wie Authentifizierungskontext von Apps in ihrem Code abgefragt, festgelegt und verwendet werden soll, finden Sie im Codebeispiel unter Verwenden von Authentifizierungskontext für bedingten Zugriff zum Ausführen einer Step-up-Authentifizierung (Englisch).

Verwenden Sie keinen Authentifizierungskontext, wenn die Richtlinien für bedingten Zugriff auf die App selbst angewendet werden sollen. Das Feature funktioniert am besten, wenn Teile der Anwendung erfordern, dass der Benutzer striktere Authentifizierungsanforderungen erfüllt.

Codebeispiele

Erwartetes Verhalten bei Authentifizierungskontext (ACRS) mit bedingtem Zugriff

Explizite Erfüllung des Authentifizierungskontexts in Anforderungen

Ein Client kann explizit ein Token mit einem Authentifizierungskontext (ACRS) über die Ansprüche im Anforderungstext anfordern. Wenn ein ACRS angefordert wurde, ermöglicht der bedingte Zugriff das Ausstellen des Tokens mit dem angeforderten ACRS, sobald alle Herausforderungen abgeschlossen wurden.

Erwartetes Verhalten, wenn ein Authentifizierungskontext nicht durch bedingten Zugriff im Mandanten geschützt ist

Der bedingte Zugriff kann einen ACRS in den Ansprüchen eines Tokens ausgeben, wenn alle dem ACRS-Wert zugewiesenen Richtlinien für bedingten Zugriff erfüllt wurden. Wenn einem ACRS-Wert keine Richtlinie für bedingten Zugriff zugewiesen ist, kann der Anspruch möglicherweise dennoch ausgegeben werden, da alle Richtlinienanforderungen erfüllt wurden.

Zusammenfassungstabelle für das erwartete Verhalten, wenn ACRS explizit angefordert wird

ACRS angefordert Richtlinie angewendet Steuerung erfüllt ACRS zu Ansprüchen hinzugefügt
Ja Keine Ja Ja
Ja Ja Nr. Nein
Ja Ja Ja Ja
Ja Keine Richtlinien mit ACRS konfiguriert Ja Ja

Implizite Erfüllung des Authentifizierungskontexts durch opportunistische Auswertung

Ein Ressourcenanbieter kann sich für den optionalen Anspruch „acrs“ entscheiden. Beim bedingten Zugriff wird versucht, den Tokenansprüchen opportunistisch ACRS-Werte hinzuzufügen, um Roundtrips zum Abrufen neuer Token für Microsoft Entra ID zu vermeiden. Bei dieser Auswertung wird durch bedingten Zugriff überprüft, ob die Richtlinien zum Schützen des Authentifizierungskontexts bereits erfüllt sind, und ACRS wird den Tokenansprüchen hinzugefügt, falls dies der Fall ist.

Hinweis

Jeder Tokentyp muss einzeln aktiviert werden (ID-Token, Zugriffstoken).

Wenn sich ein Ressourcenanbieter nicht für den optionalen Anspruch „acrs“ entscheidet, können Sie nur über eine explizite Tokenanforderung einen ACRS für das Token erhalten. Das Token erhält so die Vorteile der opportunistischen Auswertung nicht. Daher fordert der Ressourcenanbieter den Client jedes Mal auf, ein neues Token mit ACRS in den Ansprüchen abzurufen, wenn der erforderliche ACRS in den Tokenansprüchen fehlt.

Erwartetes Verhalten mit Authentifizierungskontext und Sitzungssteuerungen für die opportunistische Auswertung eines impliziten ACRS

Anmeldehäufigkeit nach Intervall

Der bedingte Zugriff betrachtet „Anmeldehäufigkeit nach Intervall“ für die opportunistische ACRS-Auswertung als erfüllt, wenn alle aktuellen Authentifizierungsfaktoren im Anmeldehäufigkeitsintervall liegen. Falls die erste Authentifizierungsinstanz veraltet ist oder der zweite Faktor (MFA) vorhanden ist und seine Authentifizierungsinstanz veraltet ist, wird die Anmeldehäufigkeit nach Intervall nicht erfüllt, und der ACRS wird nicht opportunistisch im Token ausgegeben.

Cloud App Security (CAS)

Der bedingte Zugriff betrachtet die CAS-Sitzungssteuerung für die opportunistische ACRS-Auswertung als erfüllt, wenn während dieser Anforderung eine CAS-Sitzung eingerichtet wurde. Wenn beispielsweise eine Anforderung eingeht und eine Richtlinie für bedingten Zugriff angewendet und eine CAS-Sitzung erzwungen wird, und zusätzlich eine Richtlinie für bedingten Zugriff vorhanden ist, die ebenfalls eine CAS-Sitzung erfordert, ist die CAS-Sitzungssteuerung für die opportunistische Auswertung erfüllt, da eine CAS-Sitzung erzwungen wird.

Erwartetes Verhalten, wenn ein Mandant Richtlinien für bedingten Zugriff zum Schützen des Authentifizierungskontexts enthält

Die folgende Tabelle zeigt alle Einzelfälle, in denen ACRS den Ansprüchen des Tokens durch opportunistische Auswertung hinzugefügt wird.

Richtlinie A: Fordern Sie die MFA von allen Benutzer*innen mit Ausnahme von „Ariel“ an, wenn Sie den ACRS „c1“ anfordern. Richtlinie B: Blockieren Sie alle Benutzer*innen mit Ausnahme von „Jay“, wenn Sie die ACRS „c2“ oder „c3“ anfordern.

Flow ACRS angefordert Richtlinie angewendet Steuerung erfüllt ACRS zu Ansprüchen hinzugefügt
Ariel-Anforderungen für ein Zugriffstoken „c1“ Keine Ja für „c1“. Nein für „c2“ und „c3“ „c1“ (angefordert)
Ariel-Anforderungen für ein Zugriffstoken „c2“ Richtlinie B Durch Richtlinie B blockiert Keine
Ariel-Anforderungen für ein Zugriffstoken Keine Keine Ja für „c1“. Nein für „c2“ und „c3“ „c1“ (opportunistisch aus Richtlinie A hinzugefügt)
Jay-Anforderungen für ein Zugriffstoken (ohne MFA) „c1“ Richtlinie A Nein Keine
Jay-Anforderungen für ein Zugriffstoken (mit MFA) „c1“ Richtlinie A Ja „c1“ (angefordert), „c2“ (opportunistisch aus Richtlinie B hinzugefügt), „c3“ (opportunistisch aus Richtlinie B hinzugefügt)
Jay-Anforderungen für ein Zugriffstoken (ohne MFA) „c2“ Keine Ja für „c2“ und „c3“ Nein für „c1“ „c2“ (angefordert), „c3“ (opportunistisch aus Richtlinie B hinzugefügt)
Jay-Anforderungen für ein Zugriffstoken (mit MFA) „c2“ Keine Ja für „c1“, „c2“ und „c3“ „c1“ (beste Leistung von A), „c2“ (angefordert), „c3“ (opportunistisch aus Richtlinie B hinzugefügt)
Jay-Anforderungen für ein Zugriffstoken (mit MFA) Keine Keine Ja für „c1“, „c2“ und „c3“ „c1“, „c2“ und „c3“ opportunistisch hinzugefügt
Jay-Anforderungen für ein Zugriffstoken (ohne MFA) Keine Keine Ja für „c2“ und „c3“ Nein für „c1“ „c2“ und „c3“ opportunistisch hinzugefügt

Nächste Schritte