Freigeben über

Sichern von Java Tomcat-Apps mithilfe von Rollen und Rollenansprüchen

  • Artikel

In diesem Artikel wird eine Java Tomcat-App veranschaulicht, die OpenID-Verbinden zum Anmelden von Benutzern und Microsoft Entra ID-Anwendungsrollen (App-Rollen) für die Autorisierung verwendet.

Diese Anwendung implementiert die rollenbasierte Zugriffssteuerung (RBAC) mithilfe der Anwendungsrollen und Rollenansprüche-Funktion von Microsoft Entra ID. Ein weiterer Ansatz besteht darin, Microsoft Entra-ID-Gruppen und Gruppenansprüche zu verwenden. Microsoft Entra-ID-Gruppen und Anwendungsrollen schließen sich nicht gegenseitig aus. Sie können beide verwenden, um eine feinkörnige Zugriffssteuerung bereitzustellen.

Sie können auch RBAC mit Anwendungsrollen und Rollenansprüchen verwenden, um Autorisierungsrichtlinien sicher zu erzwingen.

Ein Video, das dieses Szenario und dieses Beispiel behandelt, finden Sie unter Implementieren der Autorisierung in Ihren Anwendungen mithilfe von App-Rollen, Sicherheitsgruppen, Bereichen und Verzeichnisrollen.

Weitere Informationen dazu, wie die Protokolle in diesem Szenario und in anderen Szenarien funktionieren, finden Sie unter Authentifizierung und Autorisierung.

Diese Anwendung verwendet MSAL für Java (MSAL4J), um sich bei einem Benutzer anzumelden und ein ID-Token von Microsoft Entra ID abzurufen.

In diesem Beispiel wird zunächst msAL für Java (MSAL4J) verwendet, um sich beim Benutzer anzumelden. Auf der Startseite wird eine Option angezeigt, mit der der Benutzer die Ansprüche in ihren ID-Token anzeigen kann. Diese Anwendung ermöglicht es den Benutzern auch, je nach app-Rolle, der sie zugewiesen wurden, eine privilegierte Administratorseite oder eine normale Benutzerseite anzuzeigen. Die Idee besteht darin, ein Beispiel dafür bereitzustellen, wie der Zugriff auf bestimmte Funktionen oder Seiten innerhalb einer Anwendung auf Teilmengen von Benutzern beschränkt ist, je nachdem, zu welcher Rolle sie gehören.

Diese Art von Autorisierung wird mithilfe von RBAC implementiert. Mit RBAC gewährt ein Administrator Berechtigungen für Rollen, nicht für einzelne Benutzer oder Gruppen. Der Administrator kann dann verschiedenen Benutzern und Gruppen Rollen zuweisen, um zu steuern, wer Zugriff auf bestimmte Inhalte und Funktionen hat.

Diese Beispielanwendung definiert die folgenden beiden Anwendungsrollen:

  • PrivilegedAdmin: Autorisiert für den Zugriff auf die Seiten "Nur Administratoren" und " Reguläre Benutzer ".
  • RegularUser: Autorisiert für den Zugriff auf die Seite "Reguläre Benutzer ".

Diese Anwendungsrollen werden im Azure-Portal im Registrierungsmanifest der Anwendung definiert. Wenn sich ein Benutzer bei der Anwendung anmeldet, gibt die Microsoft Entra-ID einen Rollenanspruch für jede Rolle aus, die dem Benutzer einzeln in Form der Rollenmitgliedschaft gewährt wird.

Sie können Benutzern und Gruppen Rollen über die Azure-Portal oder programmgesteuert mithilfe von Microsoft Graph und Microsoft Azure AD PowerShell zuweisen. In diesem Artikel werden beide Techniken beschrieben.

Hinweis

Rollenansprüche sind für Gastbenutzer in einem Mandanten nicht vorhanden, wenn der https://login.microsoftonline.com/common/ Endpunkt als Autorität zum Anmelden von Benutzern verwendet wird. Sie müssen sich bei einem Mandantenendpunkt wie https://login.microsoftonline.com/tenantidz. B. bei einem Benutzer anmelden.

Voraussetzungen

Empfehlungen

  • Einige Kenntnisse mit den Java / Jakarta Servlets.
  • Vertrautheit mit Linux/OSX-Terminal oder Windows PowerShell.
  • jwt.ms zum Überprüfen Ihrer Token.
  • Fiddler zur Überwachung Ihrer Netzwerkaktivität und Problembehandlung.
  • Folgen Sie dem Microsoft Entra ID-Blog , um mit den neuesten Entwicklungen auf dem neuesten Stand zu bleiben.

Einrichten des Beispiels

In den folgenden Abschnitten wird gezeigt, wie Sie die Beispielanwendung einrichten.

Klonen oder Herunterladen des Beispiel-Repositorys

Um das Beispiel zu klonen, öffnen Sie ein Bash-Fenster, und verwenden Sie den folgenden Befehl:

git clone https://github.com/Azure-Samples/ms-identity-java-servlet-webapp-authentication.git
cd 3-Authorization-II/roles

Navigieren Sie alternativ zum Repository "ms-identity-java-servlet-webapp-authentication ", und laden Sie sie dann als .zip Datei herunter, und extrahieren Sie sie auf Ihre Festplatte.

Wichtig

Um Dateipfadlängenbeschränkungen für Windows zu vermeiden, klonen Oder extrahieren Sie das Repository in ein Verzeichnis in der Nähe des Stammverzeichnisses Ihrer Festplatte.

Registrieren der Beispielanwendung bei Ihrem Microsoft Entra ID-Mandanten

In diesem Beispiel gibt es ein Projekt. Um die App auf dem Azure-Portal zu registrieren, können Sie entweder manuelle Konfigurationsschritte ausführen oder ein PowerShell-Skript verwenden. Das Skript führt folgende Aufgaben aus:

  • Erstellt die Microsoft Entra-ID-Anwendungen und verwandte Objekte, z. B. Kennwörter, Berechtigungen und Abhängigkeiten.
  • Ändert die Projektkonfigurationsdateien.
  • Richten Sie standardmäßig eine Anwendung ein, die nur mit Konten in Ihrem Organisationsverzeichnis funktioniert.

Führen Sie die folgenden Schritte aus, um das PowerShell-Skript auszuführen:

  1. Öffnen Sie unter Windows PowerShell, und navigieren Sie zum Stammverzeichnis des geklonten Verzeichnisses.

  2. Verwenden Sie den folgenden Befehl, um die Ausführungsrichtlinie für PowerShell festzulegen:

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process -Force

  3. Verwenden Sie die folgenden Befehle, um das Konfigurationsskript auszuführen:

    cd .\AppCreationScripts\
.\Configure.ps1

    Hinweis

    Weitere Methoden zum Ausführen der Skripts werden in App-Erstellungsskripts beschrieben. Die Skripts bieten auch einen Leitfaden zur automatisierten Anwendungsregistrierung, Konfiguration und Entfernung, die in Ihren CI/CD-Szenarien hilfreich sein kann.

Konfigurieren der App (java-servlet-webapp-roles) für die Verwendung Ihrer App-Registrierung

Führen Sie die folgenden Schritte aus, um die App zu konfigurieren:

Hinweis

In den folgenden Schritten ClientID ist identisch mit Application ID oder AppId.

  1. Öffnen Sie das Projekt in Ihrer IDE.

  2. Öffnen Sie die Datei "authentication.properties ".

  3. Suchen Sie die Zeichenfolge {enter-your-tenant-id-here}. Ersetzen Sie den vorhandenen Wert durch Ihre Microsoft Entra ID-Mandanten-ID.

  4. Suchen Sie die Zeichenfolge{enter-your-client-id-here}, und ersetzen Sie den vorhandenen Wert durch die Anwendungs-ID oder clientId die Anwendung, die java-servlet-webapp-call-graph aus der Azure-Portal kopiert wurde.

  5. Suchen Sie die Zeichenfolge{enter-your-client-secret-here}, und ersetzen Sie den vorhandenen Wert durch den Wert, den Sie während der Erstellung der java-servlet-webapp-roles App gespeichert haben, im Azure-Portal.

  6. Suchen Sie die app.roles Eigenschaft, und stellen Sie sicher, dass der Wert auf app.roles=admin PrivilegedAdmin, user RegularUser" festgelegt" ist, oder ersetzen Sie die Namen Ihrer spezifischen Rollen.

Erstellen des Beispiels

Um das Beispiel mit Maven zu erstellen, navigieren Sie zu dem Verzeichnis, das die pom.xml Datei für das Beispiel enthält, und führen Sie dann den folgenden Befehl aus:

mvn clean package

Dieser Befehl generiert eine WAR-Datei , die Sie auf einer Vielzahl von Anwendungsservern ausführen können.

Ausführen des Beispiels

In den folgenden Abschnitten wird gezeigt, wie Sie das Beispiel für Azure-App Dienst bereitstellen.

Voraussetzungen

Konfigurieren des Maven-Plug-Ins

Wenn Sie die Bereitstellung für Azure-App Dienst bereitstellen, verwendet die Bereitstellung automatisch Ihre Azure-Anmeldeinformationen aus der Azure CLI. Wenn die Azure CLI nicht lokal installiert ist, führt das Maven-Plug-In die Authentifizierung über OAuth oder die Geräteanmeldung durch. Weitere Informationen finden Sie unter Authentifizierung mit Maven-Plug-Ins.

Führen Sie die folgenden Schritte aus, um das Plug-In zu konfigurieren:

  1. Führen Sie den folgenden Befehl aus, um die Bereitstellung zu konfigurieren. Mit diesem Befehl können Sie das Azure-App Dienstbetriebssystem, die Java-Version und die Tomcat-Version einrichten.

    mvn com.microsoft.azure:azure-webapp-maven-plugin:2.12.0:config

  2. Drücken Sie für die Konfiguration "Neue Ausführung erstellen" Y, und drücken Sie dann die EINGABETASTE.

  3. Drücken Sie zum Definieren des Werts für das Betriebssystem 1 für Windows oder 2 für Linux, und drücken Sie dann die EINGABETASTE.

  4. Drücken Sie für "Define value for javaVersion" 2 für Java 11, und drücken Sie dann die EINGABETASTE.

  5. Drücken Sie für "Wert definieren" für "webContainer" 4 für Tomcat 9.0, und drücken Sie dann die EINGABETASTE.

  6. Drücken Sie zum Definieren des Werts für "pricingTier" die EINGABETASTE, um die standardebene P1v2 auszuwählen.

  7. Drücken Sie für "Bestätigen" Y, und drücken Sie dann die EINGABETASTE.

Das folgende Beispiel zeigt die Ausgabe des Bereitstellungsprozesses:

Please confirm webapp properties
AppName : msal4j-servlet-auth-1707209552268
ResourceGroup : msal4j-servlet-auth-1707209552268-rg
Region : centralus
PricingTier : P1v2
OS : Linux
Java Version: Java 11
Web server stack: Tomcat 9.0
Deploy to slot : false
Confirm (Y/N) [Y]: [INFO] Saving configuration to pom.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  37.112 s
[INFO] Finished at: 2024-02-06T08:53:02Z
[INFO] ------------------------------------------------------------------------

Nachdem Sie Ihre Auswahl bestätigt haben, fügt das Plug-In das erforderliche Plug-In-Element und die Einstellungen zur pom.xml Datei Ihres Projekts hinzu, um Ihre App so zu konfigurieren, dass sie in Azure-App Dienst ausgeführt wird.

Der relevante Teil der pom.xml Datei sollte dem folgenden Beispiel ähneln:

<build>
    <plugins>
        <plugin>
            <groupId>com.microsoft.azure</groupId>
            <artifactId>>azure-webapp-maven-plugin</artifactId>
            <version>x.xx.x</version>
            <configuration>
                <schemaVersion>v2</schemaVersion>
                <resourceGroup>your-resourcegroup-name</resourceGroup>
                <appName>your-app-name</appName>
            ...
            </configuration>
        </plugin>
    </plugins>
</build>

Sie können die Konfigurationen für App Service direkt in Ihrem pom.xml ändern. Einige gängige Konfigurationen sind in der folgenden Tabelle aufgeführt:

Eigenschaft Erforderlich Beschreibung
subscriptionId false Die Abonnement-ID.
resourceGroup true Die Azure-Ressourcengruppe für Ihre App.
appName true Der Name Ihrer App.
region false Die Region, in der Ihre App gehostet werden soll. Der Standardwert ist centralus. Gültige Regionen finden Sie unter "Unterstützte Regionen".
pricingTier false Das Preisniveau für Ihre App. Der Standardwert ist P1v2 für eine Produktionsauslastung. Der empfohlene Mindestwert für die Java-Entwicklung und -Tests ist B2. Weitere Informationen finden Sie unter App Service Pricing.
runtime false Die Laufzeitumgebungskonfiguration. Weitere Informationen finden Sie unter Konfigurationsdetails.
deployment false Die Bereitstellungskonfiguration. Weitere Informationen finden Sie unter Konfigurationsdetails.

Eine vollständige Liste der Konfigurationen finden Sie in der Dokumentation zur Plug-In-Referenz. Alle Azure Maven-Plug-Ins teilen einen gemeinsamen Satz von Konfigurationen. Informationen zu diesen Konfigurationen finden Sie unter "Allgemeine Konfigurationen". Konfigurationen, die für Azure-App Dienst spezifisch sind, finden Sie unter Azure-App: Konfigurationsdetails.

Achten Sie darauf, die Werte für resourceGroup die appName spätere Verwendung beiseite zu speichern.

Vorbereiten der App für die Bereitstellung

Wenn Sie Ihre Anwendung im App-Dienst bereitstellen, ändert sich ihre Umleitungs-URL in die Umleitungs-URL Ihrer bereitgestellten App-Instanz. Führen Sie die folgenden Schritte aus, um diese Einstellungen in der Eigenschaftendatei zu ändern:

  1. Navigieren Sie zur Datei "authentication.properties" Ihrer App, und ändern Sie den Wert der app.homePage bereitgestellten App Standard Name, wie im folgenden Beispiel gezeigt. Wenn Sie z. B. im vorherigen Schritt den App-Namen ausgewählt habenexample-domain, müssen Sie jetzt den app.homePage Wert verwendenhttps://example-domain.azurewebsites.net. Stellen Sie sicher, dass Sie das Protokoll auch von "in httphttps" geändert haben.

    # app.homePage is by default set to dev server address and app context path on the server
# for apps deployed to azure, use https://your-sub-domain.azurewebsites.net
app.homePage=https://<your-app-name>.azurewebsites.net

  2. Verwenden Sie nach dem Speichern dieser Datei den folgenden Befehl, um Ihre App neu zu erstellen:

    mvn clean package

Wichtig

In derselben Datei "authentication.properties " haben Sie eine Einstellung für Ihre aad.secret. Es empfiehlt sich nicht, diesen Wert für App Service bereitzustellen. Ebenso wenig ist es eine bewährte Methode, diesen Wert in Ihrem Code zu belassen und ihn möglicherweise an Ihr Git-Repository zu übertragen. Wenn Sie diesen geheimen Wert aus Ihrem Code entfernen möchten, finden Sie ausführlichere Anleitungen im Abschnitt "Deploy to App Service – Remove secret ". Diese Anleitung fügt zusätzliche Schritte zum Pushen des geheimen Werts an Key Vault und zum Verwenden von Key Vault-Verweisen hinzu.

Aktualisieren Ihrer Microsoft Entra ID-App-Registrierung

Da sich der Umleitungs-URI an Ihre bereitgestellte App in Azure-App Dienst ändert, müssen Sie auch den Umleitungs-URI in Ihrer Microsoft Entra ID-App-Registrierung ändern. Durchlaufen Sie folgende Schritte, um diese Änderung wirksam zu machen:

  1. Navigieren Sie zur Seite App-Registrierungen von Microsoft Identity Platform für Entwickler.

  2. Verwenden Sie das Suchfeld, um nach Ihrer App-Registrierung zu suchen , java-servlet-webapp-authenticationz. B. .

  3. Öffnen Sie die App-Registrierung, indem Sie den Namen auswählen.

  4. Wählen Sie im oberen Menü Authentifizierung aus.

  5. Wählen Sie im Abschnitt "Webumleitungs-URIs - " die Option "URI hinzufügen" aus.

  6. Füllen Sie den URI Ihrer App aus, https://<your-app-name>.azurewebsites.net/auth/redirectz. B. anfügen /auth/redirect .

  7. Wählen Sie Speichern.

Bereitstellen der App

Sie können Ihre App jetzt für Azure-App Dienst bereitstellen. Verwenden Sie den folgenden Befehl, um sicherzustellen, dass Sie bei Ihrer Azure-Umgebung angemeldet sind, um die Bereitstellung auszuführen:

az login

Wenn alle Konfigurationen in Ihrer pom.xml-Datei bereit sind, können Sie jetzt den folgenden Befehl verwenden, um Ihre Java-App in Azure bereitzustellen:

mvn package azure-webapp:deploy

Nach Abschluss der Bereitstellung ist Ihre Anwendung bereit unter http://<your-app-name>.azurewebsites.net/. Öffnen Sie die URL mit Ihrem lokalen Webbrowser, in dem die Startseite der msal4j-servlet-auth Anwendung angezeigt werden soll.

Untersuchen des Beispiels

Führen Sie die folgenden Schritte aus, um das Beispiel zu erkunden:

  1. Beachten Sie den angemeldeten oder abgemeldeten Status, der in der Mitte des Bildschirms angezeigt wird.
  2. Wählen Sie in der Ecke die Schaltfläche "Kontextsensitiv" aus. Diese Schaltfläche liest die Anmeldung , wenn Sie die App zum ersten Mal ausführen.
  3. Folgen Sie auf der nächsten Seite den Anweisungen, und melden Sie sich mit einem Konto im Microsoft Entra ID-Mandanten an.
  4. Beachten Sie auf dem Zustimmungsbildschirm die bereiche, die angefordert werden.
  5. Beachten Sie, dass die Kontextsensitive Schaltfläche jetzt "Abmelden" anzeigt und Ihren Benutzernamen anzeigt.
  6. Wählen Sie ID-Tokendetails aus, um einige der decodierten Ansprüche des ID-Tokens anzuzeigen.
  7. Wählen Sie " Nur Administratoren" aus, um die /admin_only Seite anzuzeigen. Nur Benutzer mit App-Rolle PrivilegedAdmin können diese Seite anzeigen. Andernfalls wird eine Meldung zu Autorisierungsfehlern angezeigt.
  8. Wählen Sie "Reguläre Benutzer " aus, um die /regular_user Seite anzuzeigen. Nur Benutzer mit App-Rolle RegularUser oder PrivilegedAdmin können diese Seite anzeigen. Andernfalls wird eine Meldung zu Autorisierungsfehlern angezeigt.
  9. Verwenden Sie die Schaltfläche in der Ecke, um sich abzumelden.

Informationen zum Code

In diesem Beispiel wird MSAL für Java (MSAL4J) verwendet, um einen Benutzer anzumelden und ein ID-Token abzurufen, das den Rollenanspruch enthalten kann. Basierend auf dem vorhandenen Rollenanspruch kann der angemeldete Benutzer auf keine, eine oder beide der geschützten Seiten Admins Only zugreifen und Regular Users.

Wenn Sie das Verhalten dieses Beispiels replizieren möchten, können Sie die pom.xml Datei und den Inhalt der Hilfs- und Authentifizierungsordner im Ordner "src/Standard/java/com/microsoft/azuresamples/msal4j" kopieren. Außerdem benötigen Sie die Datei "authentication.properties ". Diese Klassen und Dateien enthalten generischen Code, den Sie in einer breiten Palette von Anwendungen verwenden können. Sie können auch den Rest des Beispiels kopieren, aber die anderen Klassen und Dateien werden speziell für das Ziel dieses Beispiels erstellt.

Contents

Die folgende Tabelle zeigt den Inhalt des Beispielprojektordners:

Datei/Ordner Beschreibung
AppCreationScripts/ Skripts zum automatischen Konfigurieren von Microsoft Entra ID-App-Registrierungen.
src/Standard/java/com/microsoft/azuresamples/msal4j/roles/ Dieses Verzeichnis enthält die Klassen, die die Back-End-Geschäftslogik der App definieren.
src/Standard/java/com/microsoft/azuresamples/msal4j/authservlets/ Dieses Verzeichnis enthält die Klassen, die für Anmelde- und Abmeldeendpunkte verwendet werden.
____Servlet.java Alle verfügbaren Endpunkte werden in .java Klassen definiert, die auf ____Servlet.java enden.
src/Standard/java/com/microsoft/azuresamples/msal4j/helpers/ Hilfsklassen für die Authentifizierung.
AuthenticationFilter.java Leitet nicht authentifizierte Anforderungen an geschützte Endpunkte auf eine 401-Seite um.
src/Standard/resources/authentication.properties Microsoft Entra ID und Programmkonfiguration.
src/Standard/webapp/ Dieses Verzeichnis enthält die Benutzeroberfläche – JSP-Vorlagen
CHANGELOG.md Liste der Änderungen am Beispiel.
CONTRIBUTING.md Richtlinien für einen Beitrag zur Stichprobe.
LIZENZ Die Lizenz für das Beispiel.

Verarbeiten eines Rollenanspruchs im ID-Token

Der Rollenanspruch des Tokens enthält die Namen der Rollen, denen der angemeldete Benutzer zugewiesen ist, wie im folgenden Beispiel gezeigt:

{
  ...
  "roles": [
    "Role1",
    "Role2",]
  ...
}

ConfidentialClientApplication

Eine ConfidentialClientApplication Instanz wird in der datei AuthHelper.java erstellt, wie im folgenden Beispiel gezeigt. Dieses Objekt hilft beim Erstellen der Microsoft Entra-Autorisierungs-URL und hilft auch beim Austauschen des Authentifizierungstokens für ein Zugriffstoken.

// getConfidentialClientInstance method
IClientSecret secret = ClientCredentialFactory.createFromSecret(SECRET);
confClientInstance = ConfidentialClientApplication
                     .builder(CLIENT_ID, secret)
                     .authority(AUTHORITY)
                     .build();

Die folgenden Parameter werden für die Instanziierung verwendet:

  • Die Client-ID der App.
  • Der geheime Clientschlüssel, der eine Anforderung für vertrauliche Clientanwendungen ist.
  • Die Microsoft Entra ID Authority, die Ihre Microsoft Entra-Mandanten-ID enthält.

In diesem Beispiel werden diese Werte aus der Datei "authentication.properties " mithilfe eines Eigenschaftenlesers in der datei Config.java gelesen.

Ausführliche exemplarische Vorgehensweise

Die folgenden Schritte bieten eine exemplarische Vorgehensweise für die Funktionalität der App:

  1. Der erste Schritt des Anmeldevorgangs besteht darin, eine Anforderung an den /authorize Endpunkt für Ihren Microsoft Entra ID-Mandanten zu senden. Die MSAL4J-Instanz ConfidentialClientApplication wird verwendet, um eine Autorisierungsanforderungs-URL zu erstellen. Die App leitet den Browser zu dieser URL um, wo sich der Benutzer anmeldet.

    final ConfidentialClientApplication client = getConfidentialClientInstance();
AuthorizationRequestUrlParameters parameters = AuthorizationRequestUrlParameters.builder(Config.REDIRECT_URI, Collections.singleton(Config.SCOPES))
        .responseMode(ResponseMode.QUERY).prompt(Prompt.SELECT_ACCOUNT).state(state).nonce(nonce).build();

final String authorizeUrl = client.getAuthorizationRequestUrl(parameters).toString();
contextAdapter.redirectUser(authorizeUrl);

    In der folgenden Liste werden die Features dieses Codes beschrieben:

    • AuthorizationRequestUrlParameters: Parameter, die festgelegt werden müssen, um eine AuthorizationRequestUrl zu erstellen.
    • REDIRECT_URI: Wo die Microsoft Entra-ID den Browser umleitet – zusammen mit dem Authentifizierungscode – nach dem Sammeln von Benutzeranmeldeinformationen. Sie muss mit dem Umleitungs-URI in der Microsoft Entra ID-App-Registrierung im Azure-Portal übereinstimmen.
    • SCOPES: Bereiche sind Berechtigungen, die von der Anwendung angefordert werden.
      • Normalerweise reichen die drei Bereiche openid profile offline_access für den Empfang einer ID-Tokenantwort aus.
      • Vollständige Liste der von der App angeforderten Bereiche finden Sie in der Datei "authentication.properties ". Sie können weitere Bereiche wie User.Read usw. hinzufügen.

  2. Microsoft Entra ID zeigt der*dem Benutzer*in eine Anmeldeeingabeaufforderung an. Wenn der Anmeldeversuch erfolgreich ist, wird der Browser des Benutzers an den Umleitungsendpunkt der App umgeleitet. Eine gültige Anforderung an diesen Endpunkt enthält einen Autorisierungscode.

  3. Anschließend wechselt die ConfidentialClientApplication Instanz diesen Autorisierungscode für ein ID-Token und Zugriffstoken aus der Microsoft Entra-ID.

    // First, validate the state, then parse any error codes in response, then extract the authCode. Then:
// build the auth code params:
final AuthorizationCodeParameters authParams = AuthorizationCodeParameters
        .builder(authCode, new URI(Config.REDIRECT_URI)).scopes(Collections.singleton(Config.SCOPES)).build();

// Get a client instance and leverage it to acquire the token:
final ConfidentialClientApplication client = AuthHelper.getConfidentialClientInstance();
final IAuthenticationResult result = client.acquireToken(authParams).get();

    In der folgenden Liste werden die Features dieses Codes beschrieben:

    • AuthorizationCodeParameters: Parameter, die festgelegt werden müssen, um den Autorisierungscode für eine ID und/oder ein Zugriffstoken auszutauschen.
    • authCode: Der Autorisierungscode, der am Umleitungsendpunkt empfangen wurde.
    • REDIRECT_URI: Der im vorherigen Schritt verwendete Umleitungs-URI muss erneut übergeben werden.
    • SCOPES: Die im vorherigen Schritt verwendeten Bereiche müssen erneut übergeben werden.

  4. Wenn acquireToken erfolgreich ausgeführt wird, werden die Tokenansprüche extrahiert. Wenn die Nonce-Prüfung erfolgreich ist, werden die Ergebnisse - context eine Instanz von IdentityContextData - in der Sitzung gespeichert. Die Anwendung kann die Anwendung dann über eine Instanz IdentityContextAdapterServlet instanziierenIdentityContextData, wenn sie darauf zugreifen muss, wie im folgenden Code gezeigt:

    // parse IdToken claims from the IAuthenticationResult:
// (the next step - validateNonce - requires parsed claims)
context.setIdTokenClaims(result.idToken());

// if nonce is invalid, stop immediately! this could be a token replay!
// if validation fails, throws exception and cancels auth:
validateNonce(context);

// set user to authenticated:
context.setAuthResult(result, client.tokenCache().serialize());

Schützen der Routen

Informationen dazu, wie die Beispiel-App den Zugriff auf Routen filtert, finden Sie unter AuthenticationFilter.java. In der Datei "authentication.properties " enthält die app.protect.authenticated Eigenschaft die durch Trennzeichen getrennten Routen, auf die nur authentifizierte Benutzer zugreifen können, wie im folgenden Beispiel gezeigt:

# for example, /token_details requires any user to be signed in and does not require special roles claim(s)
app.protect.authenticated=/token_details

Alle routen, die in den durch Trennzeichen getrennten Regelsätzen app.protect.roles aufgelistet sind, sind auch für nicht authentifizierte authentifizierte Benutzer außer Grenzen, wie im folgenden Beispiel gezeigt. Diese Routen enthalten jedoch auch eine durch Leerzeichen getrennte Liste der App-Rollenmitgliedschaften: Nach der Authentifizierung können nur Benutzer mit mindestens einer der entsprechenden Rollen auf diese Routen zugreifen.

# local short names for app roles - for example, sets admin to mean PrivilegedAdmin (useful for long rule sets defined in the next key, app.protect.roles)
app.roles=admin PrivilegedAdmin, user RegularUser

# A route and its corresponding <space-separated> role(s) that can access it; the start of the next route & its role(s) is delimited by a <comma-and-space-separator>
# this says: /admins_only can be accessed by PrivilegedAdmin, /regular_user can be accessed by PrivilegedAdmin role and the RegularUser role
app.protect.roles=/admin_only admin, /regular_user admin user

Bereiche

Bereiche teilen Microsoft Entra-ID mit, welche Zugriffsebene die Anwendung anfordert.

Basierend auf den angeforderten Bereichen stellt die Microsoft Entra-ID dem Benutzer bei der Anmeldung einen Zustimmungsdialog vor. Wenn der Benutzer einem oder mehreren Bereichen zustimmt und ein Token abruft, werden die Bereiche, die zugestimmt haben, in das resultierende access_tokencodiert.

Die von der Anwendung angeforderten Bereiche finden Sie unter "authentication.properties". Diese drei Bereiche werden von MSAL angefordert und standardmäßig von Microsoft Entra ID angegeben.

Weitere Informationen