Sichern von Java WebSphere-Apps mit App-Rollen und Rollenansprüchen

Artikel
10/14/2024

In diesem Artikel wird eine Java WebSphere-App veranschaulicht, die OpenID Connect 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. Eine andere Herangehensweise besteht in der Verwendung von Microsoft Entra ID-Gruppen und -Gruppenansprüchen. Microsoft Entra-ID-Gruppen und Anwendungsrollen schließen sich nicht gegenseitig aus. Sie können beide verwenden, um eine differenzierte 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 ist, ein Beispiel dafür zu geben, wie innerhalb einer Anwendung der Zugriff auf bestimmte Funktionen oder Seiten auf Untergruppen von Benutzern beschränkt wird, je nachdem, welcher Rolle sie angehören.

Diese Art von Autorisierung wird mithilfe von RBAC implementiert. Bei der Verwendung der RBAC gewährt ein Administrator Berechtigungen für Rollen und nicht für einzelne Benutzer oder Gruppen. Der Administrator kann anschließend verschiedenen Benutzern und Gruppen Rollen zuweisen, um zu steuern, wer auf bestimmte Inhalte und Funktionen zugreifen kann.

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 Microsoft Entra ID für jede Rolle, die dem Benutzer einzeln in Form einer Rollenmitgliedschaft gewährt wird, einen Rollenanspruch aus.

Sie können Benutzern und Gruppen über das Azure-Portal Rollen zuweisen.

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 einen Benutzer bei einem Endpunkt mit Mandanten anmelden, z. B. https://login.microsoftonline.com/tenantid.

Voraussetzungen

JDK Version 8 oder höher
Maven 3
Microsoft Entra ID-Mandant. Weitere Informationen finden Sie unter So erhalten Sie einen Microsoft Entra ID-Mandanten.
Ein Benutzerkonto in Ihrem eigenen Microsoft Entra ID-Mandanten, wenn Sie nur mit Konten in Ihrem Organisationsverzeichnis arbeiten möchten, d. h. im Einzelmandantenmodus. Wenn Sie noch kein Benutzerkonto in Ihrem Mandanten erstellt haben, sollten Sie dies tun, bevor Sie fortfahren. Weitere Informationen finden Sie unter Erstellen, Einladen und Löschen von Benutzern.

Empfehlungen

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

Einrichten des Beispiels

Die folgenden Abschnitte zeigen Ihnen, wie der Beispielcode für die Anwendung eingerichtet wird.

Klonen oder Herunterladen des Beispielrepositorys

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-msal-java-samples.git
cd 3-java-servlet-web-app/3-Authorization-II/roles

Wechseln Sie alternativ zum Repository ms-identity-msal-java-samples, laden Sie es dann als .zip-Datei herunter, und extrahieren Sie diese auf Ihre Festplatte.

Wichtig

Um Längenbeschränkungen für Dateipfade unter Windows zu vermeiden, klonen oder extrahieren Sie das Repository in ein Verzeichnis in der Nähe des Stamms Ihrer Festplatte.

Registrieren der Beispielanwendung bei Ihrem Microsoft Entra ID-Mandanten

Dieses Beispiel enthält ein einzelnes Projekt. In den folgenden Abschnitten wird gezeigt, wie Sie die App mithilfe des Azure-Portals registrieren.

Auswählen des Microsoft Entra ID-Mandanten, in dem Sie Ihre Anwendungen erstellen möchten

Verwenden Sie die folgenden Schritte, um den Mandanten auszuwählen:

Melden Sie sich beim Azure-Portal an.
Gehen Sie wie folgt vor, wenn Ihr Konto in mehr als einem Microsoft Entra ID-Mandanten vorhanden ist: Wählen Sie Ihr Profil in der Ecke des Azure-Portals und anschließend die Option Verzeichnis wechseln aus, um für Ihre Portalsitzung zum gewünschten Microsoft Entra ID-Mandanten zu wechseln.

Registrieren der App (java-servlet-webapp-roles)

Registrieren Sie zunächst eine neue App im Azure-Portal, indem Sie die Anweisungen unter Schnellstart: Registrieren einer Anwendung bei Microsoft Identity Platform befolgen.

Führen Sie anschließend die folgenden Schritte zum Abschließen der Registrierung aus:

Navigieren Sie zur Seite App-Registrierungen von Microsoft Identity Platform für Entwickler.
Wählen Sie Neue Registrierung aus.
Geben Sie auf der daraufhin angezeigten Seite Anwendung registrieren die folgenden Registrierungsinformationen Ihrer App ein:
- Geben Sie im Abschnitt Name einen aussagekräftigen Anwendungsnamen ein, der den Benutzern der App angezeigt wird (beispielsweise java-servlet-webapp-roles).
- Wählen Sie unter Unterstützte Kontotypen eine der folgenden Optionen aus:
  - Wählen Sie Nur Konten in diesem Organisationsverzeichnis aus, wenn Sie eine Anwendung erstellen, die nur von Benutzern im Organisationsmandanten (einzelner Mandant) verwendet werden soll.
- Wählen Sie im Abschnitt Umleitungs-URI (optional) im Kombinationsfeld die Option Web aus, und geben Sie die folgenden Umleitungs-URIs ein: http://localhost:8080/msal4j-servlet-roles/auth/redirect
Wählen Sie Registrieren aus, um die Anwendung zu erstellen.
Suchen Sie auf der Registrierungsseite der App den Wert Anwendungsclient-ID, und notieren Sie ihn zur späteren Verwendung. Sie verwenden diesen Wert in den Konfigurationsdateien Ihrer App.
Wählen Sie Speichern aus, um Ihre Änderungen zu speichern.
Wählen Sie auf der Registrierungsseite der App Zertifikate & Geheimnisse aus, um die Seite zu öffnen, in dem Sie Geheimnisse generieren und Zertifikate hochladen können.
Wählen Sie im Abschnitt Geheime Clientschlüssel die Option Neuer geheimer Clientschlüssel aus.
Geben Sie eine Beschreibung ein (z. B. App-Geheimnis).
Wählen Sie eine der verfügbaren Laufzeiten aus: In 1 Jahr, In 2 Jahren oder Läuft nie ab.
Wählen Sie Hinzufügen. Der generierte Wert wird angezeigt.
Kopieren und speichern Sie den generierten Wert zur Verwendung in späteren Schritten. Sie benötigen diesen Wert für die Konfigurationsdateien des Codes. Dieser Schlüsselwert wird nicht erneut angezeigt, und Sie können ihn auch nicht auf andere Weise abrufen. Achten Sie daher darauf, ihn aus dem Azure-Portal zu speichern, bevor Sie zu einem anderen Bildschirm oder Bereich navigieren.

Definieren der Anwendungsrollen

Befolgen Sie zum Definieren der App-Rollen die folgenden Schritte aus:

Wählen Sie weiterhin in derselben App-Registrierung Im Navigationsbereich App-Rollen aus.
Wählen Sie App-Rolle erstellen aus, und geben Sie dann die folgenden Werte ein:
- Geben Sie für den Anzeigenamen einen geeigneten Namen ein, z. B. PrivilegedAdmin.
- Wählen Sie für Zulässige Membertypen die Option Benutzer.
- Geben Sie für Wert die Option PrivilegedAdmin ein.
- Geben Sie für Beschreibung die Option PrivilegedAdmins, die die Administratorseite anzeigen können ein.
Wählen Sie App-Rolle erstellen aus, und geben Sie dann die folgenden Werte ein:
- Geben Sie für den Anzeigenamen einen geeigneten Namen ein, z. B. RegularUser.
- Wählen Sie für Zulässige Membertypen die Option Benutzer.
- Geben Sie für Wert die Option RegularUser ein.
- Geben Sie für Beschreibung die Option RegularUsers, die die Benutzerseite anzeigen können ein.
Wählen Sie Übernehmen aus, um die Änderungen zu speichern.

Zuweisen von Benutzern zu Anwendungsrollen

Wenn Sie der zuvor definierten App-Rolle Benutzer hinzufügen möchten, befolgen Sie die hier aufgeführten Richtlinien: Zuweisen von Benutzern und Gruppen zu Rollen.

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 ist ClientID identisch mit Application ID oder AppId.

Öffnen Sie das Projekt in Ihrem IDE.
Öffnen Sie die Datei authentication.properties.
Suchen Sie die Zeichenfolge {enter-your-tenant-id-here}. Ersetzen Sie den vorhandenen Wert durch Ihre Microsoft Entra ID-Mandanten-ID.
Suchen Sie die Zeichenfolge {enter-your-client-id-here}, und ersetzen Sie den vorhandenen Wert durch die Anwendungs-ID clientId der java-servlet-webapp-call-graph-Anwendung, die Sie aus dem Azure-Portal kopiert haben.
Suchen Sie die Zeichenfolge {enter-your-client-secret-here}, und ersetzen Sie den vorhandenen Wert durch den Wert, den Sie beim Erstellen derjava-servlet-webapp-roles-App im Azure-Portal gespeichert haben.
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 verschiedenen Anwendungsservern ausführen können.

Ausführen des Beispiels

Bei diesen Anweisungen wird davon ausgegangen, dass Sie WebSphere installiert und einen Server eingerichtet haben. Sie können die Anleitungen unter Bereitstellen des (herkömmlichen )WebSphere Application Server Clusters auf virtuellen Azure-Computern für eine einfache Servereinrichtung verwenden.

Bevor Sie in WebSphere bereitstellen können, führen Sie die folgenden Schritte aus, um einige Konfigurationsänderungen im Beispiel selbst vorzunehmen und dann das Paket zu erstellen oder neu zu erstellen:

Navigieren Sie zur Datei authentication.properties, und ändern Sie den Wert von app.homePage in die Server-URL und Portnummer, die Sie verwenden möchten, wie im folgenden Beispiel gezeigt:

# 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://<server-url>:<port-number>/msal4j-servlet-auth/

Verwenden Sie nach dem Speichern dieser Datei den folgenden Befehl, um Ihre App neu zu erstellen:
```
mvn clean package
```
Nachdem der Code die Erstellung abgeschlossen hat, kopieren Sie die .war-Datei auf das Dateisystem des Zielservers.

Außerdem müssen Sie dieselbe Änderung in der Azure-App-Registrierung vornehmen, bei der Sie sie im Azure-Portal als Umleitungs-URI-Wert auf der Registerkarte Authentifizierung festlegen.

Navigieren Sie zur Seite App-Registrierungen von Microsoft Identity Platform für Entwickler.
Verwenden Sie das Suchfeld, um nach Ihrer App-Registrierung zu suchen. Beispiel: java-servlet-webapp-authentication.
Öffnen Sie die App-Registrierung, indem Sie den Namen auswählen.
Wählen Sie im oberen Menü Authentifizierung aus.
Wählen Sie unter Web - Umleitungs-URIs die Option URI hinzufügen aus.
Füllen Sie den URI Ihrer App aus, indem Sie /auth/redirect anfügen, Beispiel: https://<server-url>:<port-number>/auth/redirect.
Wählen Sie Speichern.

Führen Sie die folgenden Schritte aus, um das Beispiel mithilfe der Integrated Solutions Console von WebSphere bereitzustellen:

Wählen Sie auf der Registerkarte Anwendungen die Option Neue Anwendung und dann Neue Unternehmensanwendung aus.
Wählen Sie die von Ihnen erstellte .war-Datei und dann Weiter aus, bis Sie zum Installationsschritt Zuordnen von Kontextstämmen für Webmodule gelangen. Die anderen Standardeinstellungen sollten so belassen werden.
Legen Sie für den Kontextstamm denselben Wert wie nach der Portnummer im „Umleitungs-URI“ fest, den Sie in der Beispielkonfiguration/Azure-App-Registrierung festgelegt haben. Das heißt, wenn der Umleitungs-URI http://<server-url>:9080/msal4j-servlet-auth/ lautet, sollte msal4j-servlet-auth der Kontextstamm sein.
Wählen Sie Fertig stellenaus.
Wechseln Sie nach Abschluss der Installation der Anwendung zum Abschnitt WebSphere-Unternehmensanwendungen auf der Registerkarte Anwendungen.
Wählen Sie die .war-Datei aus der Liste der Anwendungen und dann Start für die Bereitstellung aus.
Navigieren Sie nach Abschluss der Bereitstellung zu http://<server-url>:9080/{whatever you set as the context root}, und die Anwendung sollte nun angezeigt werden.

Untersuchen des Beispiels

Gehen Sie folgendermaßen vor, um das Beispiel zu erkunden:

Beachten Sie den angemeldeten oder abgemeldeten Status, der in der Mitte des Bildschirms angezeigt wird.
Wählen Sie in der Ecke die Schaltfläche „Kontextsensitiv“ aus. Diese Schaltfläche lautet Anmelden, wenn Sie die App zum ersten Mal ausführen.
Folgen Sie auf der nächsten Seite den Anweisungen, und melden Sie sich mit einem Konto im Microsoft Entra ID-Mandanten an.
Beachten Sie auf dem Einwilligungsbildschirm die angeforderten Bereiche.
Beachten Sie, dass die kontextsensitive Schaltfläche jetzt Abmelden lautet und Ihren Benutzernamen anzeigt.
Klicken Sie auf ID-Tokendetails, um die decodierten Ansprüche des ID-Tokens anzuzeigen.
Wählen Sie Nur Administratoren aus, um die /admin_only-Seite anzuzeigen. Nur Benutzer mit der App-Rolle PrivilegedAdmin können diese Seite anzeigen. Andernfalls wird eine Meldung zu Autorisierungsfehlern angezeigt.
Wählen Sie Reguläre Benutzer aus, um die /regular_user-Seite anzuzeigen. Nur Benutzer mit der App-Rolle RegularUser oder PrivilegedAdmin können diese Seite anzeigen. Andernfalls wird eine Meldung zu Autorisierungsfehlern angezeigt.
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 und Regular Users zugreifen.

Wenn Sie das Verhalten dieses Beispiels replizieren möchten, können Sie die pom.xml-Datei und den Inhalt der Hilfs- und authservlets--Ordner im Ordner src/main/java/com/microsoft/azuresamples/msal4j kopieren. Außerdem benötigen Sie die authentication.properties-Datei. 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.

Die folgende Tabelle zeigt den Inhalt des Beispielprojektordners:

Datei/Ordner	Beschreibung
src/main/java/com/microsoft/azuresamples/msal4j/roles/	Dieses Verzeichnis enthält die Klassen, die die Back-End-Geschäftslogik der App definieren.
src/main/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/main/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/main/resources/authentication.properties	Microsoft Entra ID und Programmkonfiguration.
src/main/webapp/	Dieses Verzeichnis enthält die Benutzeroberfläche – JSP-Vorlagen
CHANGELOG.md	Liste der Änderungen am Beispiel.
CONTRIBUTING.md	Richtlinien für einen Beitrag zum Beispiel.
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 AuthHelper.java-Datei erstellt, wie im folgenden Beispiel gezeigt. Dieses Objekt hilft beim Erstellen der Microsoft Entra-Autorisierungs-URL und 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();

Es werden die folgenden Parameter 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 Config.java-Datei gelesen.

Ausführliche exemplarische Vorgehensweise

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

Der erste Schritt des Anmeldeprozesses besteht darin, eine Anforderung an den /authorize-Endpunkt des Microsoft Entra ID-Mandanten zu senden. Die ConfidentialClientApplication-Instanz von MSAL4J wird verwendet, um eine Autorisierungsanforderungs-URL zu erstellen. Die App leitet den Browser an diese URL um, über die der Benutzer sich dann 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: Diese Parameter müssen zum Erstellen einer AuthorizationRequestUrl-Klasse festgelegt werden.
- REDIRECT_URI: Wo Microsoft Entra ID den Browser - zusammen mit dem Authentifizierungscode - umleitet, nachdem Benutzeranmeldeinformationen gesammelt wurden. Er muss mit dem Umleitungs-URI in der Microsoft Entra ID-App-Registrierung im Azure-Portal übereinstimmen.
- SCOPES: Bereiche stellen die Berechtigungen dar, die von der Anwendung angefordert wurden.
  - Normalerweise reichen die drei Bereiche openid profile offline_access aus, um eine ID-Token-Antwort zu erhalten.
  - Vollständige Liste der von der App angeforderten Bereiche finden Sie in der Datei authentication.properties. Sie können weitere Bereiche hinzufügen, Beispiel: User.Read.
Microsoft Entra ID zeigt der*dem Benutzer*in eine Anmeldeeingabeaufforderung an. Wenn der Anmeldeversuch erfolgreich ist, wird der Browser des Benutzers zum Umleitungsendpunkt dieser App umgeleitet. Eine erfolgreiche Anforderung an diesen Endpunkt enthält einen Autorisierungscode.
Die ConfidentialClientApplication-Instanz tauscht diesen Autorisierungscode dann für ein ID-Token und ein Zugriffstoken von Microsoft Entra ID aus.
```
// 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: Diese Parameter müssen festgelegt werden, damit der Autorisierungscode für ein ID- und/oder ein Zugriffstoken ausgetauscht werden kann.
- authCode: Hierbei handelt es sich um den Autorisierungscode, der am Umleitungsendpunkt empfangen wurde.
- REDIRECT_URI: Der im vorherigen Schritt verwendete Umleitungs-URI muss noch mal übergeben werden.
- SCOPES: Die im vorherigen Schritt verwendeten Bereiche müssen noch einmal übergeben werden.
Wenn acquireToken erfolgreich ausgeführt wird, werden die Tokenansprüche extrahiert. Wenn die Nonce-Überprüfung erfolgreich ist, werden die Ergebnisse in context (eine Instanz von IdentityContextData) platziert und in der Sitzung gespeichert. Die Anwendung kann IdentityContextData dann aus der Sitzung (mithilfe einer IdentityContextAdapterServlet-Instanz) instanziieren, wenn sie Zugriff benötigt, 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 Eigenschaft app.protect.authenticated 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 unter app.protect.roles aufgelistet sind, sind auch für nicht authentifizierte Benutzer nicht verwendbar, 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 die Zugriffsebene mit, die die Anwendung anfordert.

Auf Grundlage der angeforderten Bereiche zeigt Microsoft Entra ID dem Benutzer bei der Anmeldung ein Einwilligungsdialogfeld an. Wenn der Benutzer in einen oder mehrere Bereiche einwilligt und ein Token erhält, werden die Bereiche in das resultierende access_token codiert.

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

Nächster Schritt

Bereitstellen von Java WebSphere-Apps auf herkömmlichem WebSphere auf virtuellen Azure-Computern

Freigeben über