Zabezpieczanie aplikacji Java WebSphere przy użyciu ról aplikacji i oświadczeń ról

Artykuł
10/05/2024

W tym artykule przedstawiono aplikację Java WebSphere korzystającą z programu OpenID Connect do logowania użytkowników i ról aplikacji identyfikatora entra firmy Microsoft (ról aplikacji) na potrzeby autoryzacji.

Ta aplikacja implementuje kontrolę dostępu opartą na rolach (RBAC) przy użyciu ról aplikacji i oświadczeń ról identyfikatora Firmy Microsoft. Innym podejściem jest użycie grup identyfikatorów i oświadczeń grup firmy Microsoft. Grupy identyfikatorów i role aplikacji firmy Microsoft nie wykluczają się wzajemnie. Można ich użyć do zapewnienia szczegółowej kontroli dostępu.

Funkcję RBAC można również używać z rolami aplikacji i oświadczeniami ról, aby bezpiecznie wymuszać zasady autoryzacji.

Aby zapoznać się z filmem wideo, który obejmuje ten scenariusz i ten przykład, zobacz Implementowanie autoryzacji w aplikacjach przy użyciu ról aplikacji, grup zabezpieczeń, zakresów i ról katalogu.

Aby uzyskać więcej informacji o sposobie działania protokołów w tym scenariuszu i innych scenariuszach, zobacz Uwierzytelnianie a autoryzacja.

Ta aplikacja używa biblioteki MSAL dla języka Java (MSAL4J) do logowania użytkownika i uzyskiwania tokenu identyfikatora z identyfikatora Entra firmy Microsoft.

W tym przykładzie najpierw użyto biblioteki MSAL dla języka Java (MSAL4J) do zalogowania użytkownika. Na stronie głównej wyświetla użytkownikowi opcję wyświetlania oświadczeń w tokenach identyfikatorów. Ta aplikacja umożliwia również użytkownikom wyświetlanie uprzywilejowanej strony administratora lub strony zwykłego użytkownika w zależności od przypisanej przez nich roli aplikacji. Chodzi o przedstawienie przykładu sposobu, w jaki w aplikacji dostęp do niektórych funkcji lub stron jest ograniczony do podzbiorów użytkowników w zależności od roli, do której należą.

Tego rodzaju autoryzacja jest implementowana przy użyciu kontroli dostępu opartej na rolach. W przypadku kontroli dostępu opartej na rolach administrator udziela uprawnień do ról, a nie poszczególnym użytkownikom ani grupom. Administrator może następnie przypisywać role do różnych użytkowników i grup, aby kontrolować, kto ma dostęp do określonej zawartości i funkcji.

Ta przykładowa aplikacja definiuje następujące dwie role aplikacji:

PrivilegedAdmin: Autoryzowany do uzyskiwania dostępu tylko do administratorów i stron Użytkownicy regularni.
RegularUser: autoryzowany do uzyskiwania dostępu do strony Użytkownicy regularni .

Te role aplikacji są definiowane w witrynie Azure Portal w manifeście rejestracji aplikacji. Gdy użytkownik loguje się do aplikacji, identyfikator Entra firmy Microsoft emituje oświadczenie ról dla każdej roli przyznanej indywidualnie użytkownikowi w formie członkostwa w rolach.

Użytkownicy i grupy można przypisywać do ról za pośrednictwem witryny Azure Portal.

Uwaga

Oświadczenia ról nie są obecne dla użytkowników-gości w dzierżawie, jeśli https://login.microsoftonline.com/common/ punkt końcowy jest używany jako urząd do logowania użytkowników. Musisz zalogować użytkownika do punktu końcowego dzierżawy, takiego jak https://login.microsoftonline.com/tenantid.

Wymagania wstępne

Zestaw JDK w wersji 8 lub nowszej
Maven 3
Dzierżawa identyfikatora entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz How to get a Microsoft Entra ID tenant (Jak uzyskać dzierżawę identyfikatora entra firmy Microsoft).
Konto użytkownika we własnej dzierżawie microsoft Entra ID, jeśli chcesz pracować tylko z kontami w katalogu organizacyjnym — czyli w trybie pojedynczej dzierżawy. Jeśli konto użytkownika nie zostało jeszcze utworzone w dzierżawie, przed kontynuowaniem należy to zrobić. Aby uzyskać więcej informacji, zobacz Jak tworzyć, zapraszać i usuwać użytkowników.

Zalecenia

Znajomość serwletów Java/Dżakarta.
Pewna znajomość terminalu systemu Linux/OSX.
jwt.ms na potrzeby inspekcji tokenów.
Program Fiddler do monitorowania aktywności sieci i rozwiązywania problemów.
Postępuj zgodnie z blogiem Microsoft Entra ID, aby być na bieżąco z najnowszymi wydarzeniami.

Konfigurowanie przykładu

W poniższych sekcjach pokazano, jak skonfigurować przykładową aplikację.

Klonowanie lub pobieranie przykładowego repozytorium

Aby sklonować przykład, otwórz okno powłoki Bash i użyj następującego polecenia:

git clone https://github.com/Azure-Samples/ms-identity-msal-java-samples.git
cd 3-java-servlet-web-app/3-Authorization-II/roles

Alternatywnie przejdź do repozytorium ms-identity-msal-java-samples , a następnie pobierz go jako plik .zip i wyodrębnij go na dysk twardy.

Ważne

Aby uniknąć ograniczeń długości ścieżki pliku w systemie Windows, sklonuj lub wyodrębnij repozytorium do katalogu w pobliżu katalogu głównego dysku twardego.

Rejestrowanie przykładowej aplikacji w dzierżawie identyfikatora entra firmy Microsoft

W tym przykładzie istnieje jeden projekt. W poniższych sekcjach pokazano, jak zarejestrować aplikację przy użyciu witryny Azure Portal.

Wybierz dzierżawę microsoft Entra ID, w której chcesz utworzyć aplikacje

Aby wybrać dzierżawę, wykonaj następujące kroki:

Zaloguj się w witrynie Azure Portal.
Jeśli Twoje konto znajduje się w więcej niż jednej dzierżawie identyfikatora entra firmy Microsoft, wybierz swój profil w rogu witryny Azure Portal, a następnie wybierz pozycję Przełącz katalog , aby zmienić sesję na żądaną dzierżawę identyfikatora Entra firmy Microsoft.

Rejestrowanie aplikacji (java-servlet-webapp-roles)

Najpierw zarejestruj nową aplikację w witrynie Azure Portal, postępując zgodnie z instrukcjami w przewodniku Szybki start: rejestrowanie aplikacji przy użyciu Platforma tożsamości Microsoft.

Następnie wykonaj następujące kroki, aby ukończyć rejestrację:

Przejdź do strony Platforma tożsamości Microsoft dla deweloperów Rejestracje aplikacji.
Wybierz opcjęNowa rejestracja.
Na wyświetlonej stronie Rejestrowanie aplikacji wprowadź następujące informacje o rejestracji aplikacji:
- W sekcji Nazwa wprowadź zrozumiałą nazwę aplikacji do wyświetlania użytkownikom aplikacji — na przykład java-servlet-webapp-roles.
- W obszarze Obsługiwane typy kont wybierz jedną z następujących opcji:
  - Wybierz pozycję Konta w tym katalogu organizacyjnym tylko wtedy, gdy tworzysz aplikację do użycia tylko przez użytkowników w dzierżawie — czyli aplikacji z jedną dzierżawą.
- W sekcji Identyfikator URI przekierowania wybierz pozycję Sieć Web w polu kombi i wprowadź następujący identyfikator URI przekierowania: http://localhost:8080/msal4j-servlet-roles/auth/redirect.
Wybierz pozycję Zarejestruj, aby utworzyć aplikację.
Na stronie rejestracji aplikacji znajdź i skopiuj wartość Identyfikator aplikacji (klienta), aby użyć jej później. Ta wartość jest używana w pliku konfiguracji aplikacji lub plikach.
Wybierz Zapisz, aby zapisać zmiany.
Na stronie rejestracji aplikacji wybierz pozycję Certyfikaty i wpisy tajne w okienku nawigacji, aby otworzyć stronę, na której można wygenerować wpisy tajne i przekazać certyfikaty.
W sekcji Klucze tajne klienta wybierz pozycję Nowy klucz tajny klienta.
Wpisz opis — na przykład wpis tajny aplikacji.
Wybierz jeden z dostępnych czasów trwania: W ciągu 1 roku w ciągu 2 lat lub Nigdy nie wygasa.
Wybierz Dodaj. Zostanie wyświetlona wygenerowana wartość.
Skopiuj i zapisz wygenerowaną wartość do użycia w kolejnych krokach. Ta wartość jest potrzebna dla plików konfiguracji kodu. Ta wartość nie jest ponownie wyświetlana i nie można jej pobrać w żaden inny sposób. Dlatego przed przejściem do innego ekranu lub okienka pamiętaj, aby zapisać go w witrynie Azure Portal.

Definiowanie ról aplikacji

Aby zdefiniować role aplikacji, wykonaj następujące kroki:

Nadal w tej samej rejestracji aplikacji wybierz pozycję Role aplikacji w okienku nawigacji.
Wybierz pozycję Utwórz rolę aplikacji, a następnie wprowadź następujące wartości:
- W polu Nazwa wyświetlana wprowadź odpowiednią nazwę — na przykład PrivilegedAdmin.
- W obszarze Dozwolone typy elementów członkowskich wybierz pozycję Użytkownik.
- W polu Wartość wprowadź wartość PrivilegedAdmin.
- W polu Opis wprowadź wartość PrivilegedAdmins, którzy mogą wyświetlić stronę administratora.
Wybierz pozycję Utwórz rolę aplikacji, a następnie wprowadź następujące wartości:
- W polu Nazwa wyświetlana wprowadź odpowiednią nazwę — na przykład RegularUser.
- W obszarze Dozwolone typy elementów członkowskich wybierz pozycję Użytkownik.
- W polu Wartość wprowadź wartość RegularUser.
- W polu Opis wprowadź wartość RegularUsers, którzy mogą wyświetlić stronę użytkownika.
Wybierz pozycję Zastosuj, aby zapisać zmiany.

Przypisywanie użytkowników do ról aplikacji

Aby dodać użytkowników do zdefiniowanej wcześniej roli aplikacji, postępuj zgodnie z wytycznymi w tym miejscu: Przypisywanie użytkowników i grup do ról.

Konfigurowanie aplikacji (java-servlet-webapp-roles) w celu korzystania z rejestracji aplikacji

Aby skonfigurować aplikację, wykonaj następujące kroki:

Uwaga

W poniższych krokach ClientID jest to samo co Application ID lub AppId.

Otwórz projekt w środowisku IDE.
Otwórz plik authentication.properties.
Znajdź ciąg {enter-your-tenant-id-here}. Zastąp istniejącą wartość identyfikatorem dzierżawy microsoft Entra ID.
Znajdź ciąg {enter-your-client-id-here} i zastąp istniejącą wartość identyfikatorem aplikacji lub clientId java-servlet-webapp-call-graph aplikacją skopiowaną z witryny Azure Portal.
Znajdź ciąg {enter-your-client-secret-here} i zastąp istniejącą wartość wartością zapisaną podczas tworzenia java-servlet-webapp-roles aplikacji w witrynie Azure Portal.
app.roles Znajdź właściwość i upewnij się, że wartość jest ustawiona na app.roles=admin PrivilegedAdmin, user RegularUser, lub zastąp nazwy określonych ról.

Tworzenie przykładu

Aby skompilować przykład przy użyciu narzędzia Maven, przejdź do katalogu zawierającego plik pom.xml dla przykładu, a następnie uruchom następujące polecenie:

mvn clean package

To polecenie generuje plik war , który można uruchomić na różnych serwerach aplikacji.

Uruchamianie aplikacji przykładowej

W tych instrukcjach przyjęto założenie, że zainstalowano aplikację WebSphere i skonfigurowano serwer. Wskazówki można uzyskać w temacie Deploy WebSphere Application Server (traditional) Cluster on Azure Virtual Machines for a basic server setup (Wdrażanie klastra webSphere Application Server (tradycyjny) na maszynach wirtualnych platformy Azure na potrzeby podstawowej konfiguracji serwera.

Przed wdrożeniem w usłudze WebSphere wykonaj następujące kroki, aby wprowadzić pewne zmiany konfiguracji w samym przykładzie, a następnie skompilować lub ponownie skompilować pakiet:

Przejdź do pliku authentication.properties aplikacji i zmień wartość app.homePage adresu URL serwera i numer portu, którego planujesz użyć, jak pokazano w poniższym przykładzie:

# 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/

Po zapisaniu tego pliku użyj następującego polecenia, aby ponownie skompilować aplikację:
```
mvn clean package
```
Po zakończeniu tworzenia kodu skopiuj plik war do systemu plików serwera docelowego.

Musisz również wprowadzić tę samą zmianę w rejestracji aplikacji platformy Azure, w której ustawisz ją w witrynie Azure Portal jako wartość Identyfikator URI przekierowania na karcie Uwierzytelnianie .

Przejdź do strony Platforma tożsamości Microsoft dla deweloperów Rejestracje aplikacji.
Użyj pola wyszukiwania, aby wyszukać rejestrację aplikacji — na przykład java-servlet-webapp-authentication.
Otwórz rejestrację aplikacji, wybierając jej nazwę.
Wybierz Uwierzytelnianie z menu poleceń.
W sekcji Identyfikatory URI przekierowania sieci Web - wybierz pozycję Dodaj identyfikator URI.
Wypełnij identyfikator URI aplikacji, dołączając ciąg /auth/redirect — na przykład https://<server-url>:<port-number>/auth/redirect.
Wybierz pozycję Zapisz.

Wykonaj następujące kroki, aby wdrożyć przykład przy użyciu konsoli zintegrowanych rozwiązań WebSphere:

Na karcie Aplikacje wybierz pozycję Nowa aplikacja, a następnie pozycję Nowa aplikacja dla przedsiębiorstw.
Wybierz skompilowany plik war , a następnie wybierz przycisk Dalej , aż do kroku instalacji katalogów głównych kontekstu mapy dla modułów sieci Web. Inne ustawienia domyślne powinny być poprawne.
Dla katalogu głównego kontekstu ustaw tę samą wartość co po numerze portu w identyfikatorze URI przekierowania ustawionym w przykładowej konfiguracji/rejestracji aplikacji platformy Azure. Oznacza to, że jeśli identyfikator URI przekierowania to http://<server-url>:9080/msal4j-servlet-auth/, katalog główny kontekstu powinien mieć wartość msal4j-servlet-auth.
Wybierz Zakończ.
Po zakończeniu instalowania aplikacji przejdź do sekcji Aplikacje dla przedsiębiorstw WebSphere na karcie Aplikacje .
Wybierz zainstalowany plik war z listy aplikacji, a następnie wybierz pozycję Rozpocznij, aby wdrożyć.
Po zakończeniu wdrażania przejdź do http://<server-url>:9080/{whatever you set as the context root} strony i powinna być widoczna aplikacja.

Eksplorowanie przykładu

Aby zapoznać się z przykładem, wykonaj następujące czynności:

Zwróć uwagę na stan logowania lub wylogowania wyświetlany na środku ekranu.
Wybierz przycisk kontekstowy w rogu. Ten przycisk odczytuje pozycję Zaloguj po pierwszym uruchomieniu aplikacji.
Na następnej stronie postępuj zgodnie z instrukcjami i zaloguj się przy użyciu konta w dzierżawie Microsoft Entra ID.
Na ekranie zgody zwróć uwagę na żądane zakresy.
Zwróć uwagę, że przycisk kontekstowy zawiera teraz pozycję Wyloguj się i wyświetla swoją nazwę użytkownika.
Wybierz pozycję Szczegóły tokenu identyfikatora, aby wyświetlić niektóre zdekodowane oświadczenia tokenu identyfikatora.
Wybierz pozycję Tylko administratorzy, aby wyświetlić /admin_only stronę. Tylko użytkownicy z rolą PrivilegedAdmin aplikacji mogą wyświetlać tę stronę. W przeciwnym razie zostanie wyświetlony komunikat o niepowodzeniu autoryzacji.
Wybierz pozycję Regular Users (Regular Users ), aby wyświetlić /regular_user stronę. Tylko użytkownicy z rolą RegularUser aplikacji lub PrivilegedAdmin mogą wyświetlać tę stronę. W przeciwnym razie zostanie wyświetlony komunikat o niepowodzeniu autoryzacji.
Użyj przycisku w rogu, aby się wylogować.

Informacje o kodzie

W tym przykładzie użyto biblioteki MSAL dla języka Java (MSAL4J), aby zalogować użytkownika i uzyskać token identyfikatora, który może zawierać oświadczenie ról. Na podstawie obecnych oświadczeń ról zalogowany użytkownik może uzyskać dostęp do żadnego, jednego lub obu chronionych stron Admins Only i Regular Users.

Jeśli chcesz replikować zachowanie tego przykładu, możesz skopiować plik pom.xml i zawartość folderów pomocników i authservlets w folderze src/main/java/com/microsoft/azuresamples/msal4j . Potrzebny jest również plik authentication.properties . Te klasy i pliki zawierają kod ogólny, którego można użyć w szerokiej gamie aplikacji. Możesz również skopiować resztę przykładu, ale inne klasy i pliki są kompilowane specjalnie w celu rozwiązania tego przykładu celu.

Zawartość

W poniższej tabeli przedstawiono zawartość przykładowego folderu projektu:

Plik/folder	opis
src/main/java/com/microsoft/azuresamples/msal4j/roles/	Ten katalog zawiera klasy definiujące logikę biznesową zaplecza aplikacji.
src/main/java/com/microsoft/azuresamples/msal4j/authservlets/	Ten katalog zawiera klasy używane do logowania i wylogowyywania punktów końcowych.
____Servlet.java	Wszystkie dostępne punkty końcowe są definiowane w klasach .java kończących się na ____Servlet.java.
src/main/java/com/microsoft/azuresamples/msal4j/helpers/	Klasy pomocnika na potrzeby uwierzytelniania.
AuthenticationFilter.java	Przekierowuje nieuwierzytelnione żądania do chronionych punktów końcowych do strony 401.
src/main/resources/authentication.properties	Microsoft Entra ID i konfiguracja programu.
src/main/webapp/	Ten katalog zawiera szablony interfejsu użytkownika — JSP
CHANGELOG.md	Lista zmian w przykładzie.
CONTRIBUTING.md	Wskazówki dotyczące współtworzenia przykładu.
LICENCJA	Licencja dla przykładu.

Przetwarzanie oświadczenia ról w tokenie identyfikatora

Oświadczenie ról tokenu zawiera nazwy ról przypisanych do zalogowanego użytkownika, jak pokazano w poniższym przykładzie:

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

ConfidentialClientApplication

Wystąpienie ConfidentialClientApplication jest tworzone w pliku AuthHelper.java , jak pokazano w poniższym przykładzie. Ten obiekt pomaga utworzyć adres URL autoryzacji entra firmy Microsoft, a także ułatwia wymianę tokenu uwierzytelniania dla tokenu dostępu.

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

Następujące parametry są używane do tworzenia wystąpień:

Identyfikator klienta aplikacji.
Wpis tajny klienta, który jest wymagany w przypadku poufnych aplikacji klienckich.
Urząd Microsoft Entra ID, który zawiera identyfikator dzierżawy firmy Microsoft Entra.

W tym przykładzie te wartości są odczytywane z pliku authentication.properties przy użyciu czytnika właściwości w pliku Config.java .

Przewodnik krok po kroku

Poniższe kroki zawierają przewodnik po funkcjonalności aplikacji:

Pierwszym krokiem procesu logowania jest wysłanie żądania do /authorize punktu końcowego dla dzierżawy microsoft Entra ID. Wystąpienie MSAL4J ConfidentialClientApplication służy do konstruowania adresu URL żądania autoryzacji. Aplikacja przekierowuje przeglądarkę do tego adresu URL, w którym loguje się użytkownik.
```
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);
```
Poniższa lista zawiera opis funkcji tego kodu:
- AuthorizationRequestUrlParameters: parametry, które należy ustawić w celu utworzenia elementu AuthorizationRequestUrl.
- REDIRECT_URI: Gdzie identyfikator Entra firmy Microsoft przekierowuje przeglądarkę — wraz z kodem uwierzytelniania — po zebraniu poświadczeń użytkownika. Musi być zgodny z identyfikatorem URI przekierowania w rejestracji aplikacji Microsoft Entra ID w witrynie Azure Portal.
- SCOPES: Zakresy są uprawnieniami żądanymi przez aplikację.
  - Zwykle trzy zakresy openid profile offline_access są wystarczające do otrzymania odpowiedzi tokenu identyfikatora.
  - Pełną listę zakresów żądanych przez aplikację można znaleźć w pliku authentication.properties . Możesz dodać więcej zakresów, takich jak User.Read.
Użytkownik jest wyświetlany z monitem logowania przez microsoft Entra ID. Jeśli próba logowania zakończy się pomyślnie, przeglądarka użytkownika zostanie przekierowana do punktu końcowego przekierowania aplikacji. Prawidłowe żądanie do tego punktu końcowego zawiera kod autoryzacji.
Następnie ConfidentialClientApplication wystąpienie wymienia ten kod autoryzacji dla tokenu identyfikatora i tokenu dostępu z identyfikatora entra firmy Microsoft.
```
// 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();
```
Poniższa lista zawiera opis funkcji tego kodu:
- AuthorizationCodeParameters: Parametry, które należy ustawić w celu wymiany kodu autoryzacji dla identyfikatora i/lub tokenu dostępu.
- authCode: kod autoryzacji, który został odebrany w punkcie końcowym przekierowania.
- REDIRECT_URI: Identyfikator URI przekierowania użyty w poprzednim kroku musi zostać ponownie przekazany.
- SCOPES: zakresy używane w poprzednim kroku muszą zostać ponownie przekazane.

W przypadku acquireToken pomyślnego wyodrębnienia oświadczeń tokenu. Jeśli sprawdzanie nie jest sprawdzane, wyniki są umieszczane w context — wystąpieniu IdentityContextData — i zapisywane w sesji. Następnie aplikacja może utworzyć wystąpienie IdentityContextData z sesji za pomocą wystąpienia IdentityContextAdapterServlet zawsze, gdy potrzebuje dostępu do niej, jak pokazano w poniższym kodzie:

// 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());

Ochrona tras

Aby uzyskać informacje na temat sposobu filtrowania dostępu do tras przez przykładową aplikację, zobacz AuthenticationFilter.java. W pliku authentication.properties właściwość zawiera rozdzielane przecinkami trasy, app.protect.authenticated do których mogą uzyskiwać dostęp tylko uwierzytelnieni użytkownicy, jak pokazano w poniższym przykładzie:

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

Wszystkie trasy wymienione w zestawach app.protect.roles reguł rozdzielanych przecinkami są również poza limitami dla nieuwierzytelnionego uwierzytelnionego użytkownika, jak pokazano w poniższym przykładzie. Jednak te trasy zawierają również rozdzielaną spacjami listę członkostwa w rolach aplikacji: tylko użytkownicy mający co najmniej jedną z odpowiednich ról mogą uzyskiwać dostęp do tych tras po uwierzytelnieniu.

# 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

Zakresy

Zakresy informują microsoft Entra ID o poziomie dostępu, którego żąda aplikacja.

Na podstawie żądanych zakresów identyfikator Entra firmy Microsoft przedstawia użytkownikowi okno dialogowe zgody po zalogowaniu. Jeśli użytkownik wyraża zgodę na co najmniej jeden zakres i uzyskuje token, wyrażenie zgody zakresów zostanie zakodowane w wynikowym access_tokenobiekcie .

Aby uzyskać zakresy żądane przez aplikację, zobacz authentication.properties. Te trzy zakresy są domyślnie żądane przez bibliotekę MSAL i podane przez identyfikator Entra firmy Microsoft.

Więcej informacji

Następny krok

Wdrażanie aplikacji Java WebSphere w tradycyjnej aplikacji WebSphere na maszynach wirtualnych platformy Azure

Udostępnij za pośrednictwem