Ustawienia wpisu konfiguracji logowania do systemu dla usługi Java Authentication and Authorization Service

Za pomocą tej strony można określić listę konfiguracji logowania do systemu dla usługi JAAS (Java Authentication and Authorization Service).

Aby wyświetlić tę stronę Konsoli administracyjnej, wykonaj następujące czynności:
  1. Kliknij opcję Zabezpieczenia > Zabezpieczenia globalne.
  2. W obszarze Uwierzytelnianie kliknij opcję Usługa uwierzytelniania i autoryzacji Java (JAAS) > Logowanie do systemu.
Przed rozpoczęciem definiowania dodatkowych modułów logowania na potrzeby uwierzytelniania w środowisku wykonawczym zabezpieczeń serwera aplikacji należy zapoznać się z dokumentacją usługi JAAS (Java Authentication and Authorization Service). Nie należy usuwać następujących modułów logowania do systemu:
RMI_INBOUND, WEB_INBOUND, DEFAULT

Przetwarzają przychodzące żądania logowania dla metody RMI (Remote Method Invocation), aplikacji WWW i większości pozostałych protokołów logowania.

RMI_INBOUND
Ta konfiguracja logowania obsługuje przychodzące żądania RMI. Logowania te są żądaniami dostępu uwierzytelnionego do plików EJB (Enterprise JavaBeans). Jeśli używany jest konektor RMI, logowania mogą być żądaniami dla rozszerzeń JMX (Java Management Extensions).
WEB_INBOUND
Te konfiguracje logowania obsługują logowania dla żądań aplikacji WWW, zawierających serwlety i strony JavaServer Pages (JSP). Konfiguracja logowania może współdziałać z danymi wyjściowymi wygenerowanymi przez przechwytywacz powiązania zaufania (TAI), jeśli został skonfigurowany. Temat przekazany do konfiguracji logowania WEB_INBOUND może zawierać obiekty generowane przez przechwytywacz TAI.
DEFAULT
Ta konfiguracja logowania obsługuje logowania dla żądań przychodzących wykonywanych przez większość pozostałych protokołów oraz uwierzytelnień wewnętrznych.

Te trzy konfiguracje logowania przekażą następującą informację wywołania zwrotnego, obsługiwaną przez moduły logowania w tych konfiguracjach. Te wywołania nie są przekazywane w tym samym czasie. Kombinacja tych trzech wywołań określa sposób uwierzytelniania użytkowników przez serwer aplikacji.

Wywołanie zwrotne

callbacks[0] = new javax.security.auth.callback.
NameCallback("Username: ");

Odpowiedzialność
Pobiera nazwę użytkownika dostarczoną podczas logowania. Ta informacja może być nazwą użytkownika dla następujących typów logowań:
  • Logowanie za pomocą nazwy użytkownika, nazywane również uwierzytelnianiem podstawowym.
  • Logowanie tylko za pomocą nazwy użytkownika na potrzeby asercji tożsamości, bez hasła.
Wywołanie zwrotne

callbacks[1] = new javax.security.auth.callback.
PasswordCallback("Password: ", false);

Odpowiedzialność
Zbieranie haseł podawanych w trakcie logowania. Dozwolone jest hasło o wartości NULL, które jest używane do obsługi asercji tożsamości.
Wywołanie zwrotne

callbacks[2] = new com.ibm.websphere.security.auth.callback.
WSCredTokenCallbackImpl("Credential Token: ");

Odpowiedzialność
Pobiera token LTPA (Lightweight Third Party Authentication) lub inny typ tokenu podczas logowania. Ta informacja zwykle zastępuje nazwę użytkownika i hasło, jeśli nie zostały określone.
Wywołanie zwrotne

callbacks[3] = new com.ibm.wsspi.security.auth.callback.
WSTokenHolderCallback("Authz Token List: ");

Odpowiedzialność
Pobiera listę ArrayList obiektów TokenHolder zwracanych z wywołania do metody WSOpaqueTokenHelper. Wywołanie zwrotne używa metody createTokenHolderListFromOpaqueToken z tokenem uwierzytelniania CSIv2 (Common Secure Interoperability version 2) jako źródłem danych wejściowych.
Ograniczenie: To wywołanie zwrotne istnieje tylko w przypadku, gdy uruchomiono opcję Propagacja atrybutu zabezpieczeń, i jest to logowanie propagacji. W logowaniu propagacji odpowiednie atrybuty zabezpieczeń są propagowane z żądaniem, aby zapobiec konieczności uzyskania dostępu do rejestru użytkowników dla dodatkowych atrybutów. Należy uruchomić propagację atrybutu zabezpieczeń dla uwierzytelniania wychodzącego i przychodzącego.
Można włączyć opcję Propagacja atrybutu zabezpieczeń dla uwierzytelniania wychodzącego CSIv2, wykonując następujące kroki:
  1. Kliknij opcję Zabezpieczenia > Zabezpieczenia globalne.
  2. Na karcie Uwierzytelnianie, rozwiń menu Zabezpieczenia RMI/IIOP kliknij opcję Uwierzytelnianie wychodzące CSIv2.
  3. Uruchom opcję Propagacja atrybutu zabezpieczeń.
Można włączyć opcję Propagacja atrybutu zabezpieczeń dla uwierzytelniania przychodzącego CSIv2, wykonując następujące kroki:
  1. Kliknij opcję Zabezpieczenia > Zabezpieczenia globalne.
  2. Na karcie Uwierzytelnianie, rozwiń menu Zabezpieczenia RMI/IIOP kliknij opcję Uwierzytelnianie przychodzące CSIv2.
  3. Uruchom opcję Propagacja atrybutu zabezpieczeń.

W konfiguracjach logowania systemu serwer aplikacji uwierzytelnia użytkownika na podstawie informacji pobranej przez wywołania zwrotne. Niestandardowy moduł logowania nie musi odpowiadać na żadne z tych wywołań zwrotnych. Następująca lista zawiera typowe kombinacje tych wywołań zwrotnych:

  • Tylko wywołanie zwrotne callbacks[0] = new javax.security.auth.callback.NameCallback("Username: ");

    To wywołanie zwrotne występuje w przypadku zapewniania tożsamości protokołu CSIv2, logowania z certyfikatami X509 WWW i CSIv2, logowania starego typu przechwytywacza TAI (Trust Association Interceptor) itd. W logowaniach z certyfikatem WWW i CSIv2 X509 serwer aplikacji odwzorowuje certyfikat na nazwę użytkownika. To wywołanie zwrotne jest używane przez dowolny typ logowania ustanawiający zaufanie tylko z nazwą użytkownika.

  • Wywołanie zwrotne callbacks[0] = new javax.security.auth.callback.NameCallback("Username: "); oraz callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password: ", false);.

    Ta kombinacja wywołań zwrotnych jest typowa dla podstawowych logowań z uwierzytelnianiem. Te dwa wywołania zwrotne są używane przez większość uwierzytelnień.

  • Tylko wywołanie zwrotne callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token: ");
    To wywołanie zwrotne jest używane w celu sprawdzenia poprawności tokenu LDAP (Lightweight Third Party Authentication). To sprawdzenie poprawności odbywa się zwykle podczas logowań pojedynczych (SSO) lub zgodnych. Za każdym razem, gdy żądanie jest wysyłane przez serwer aplikacji, zamiast do prostego klienta token LTPA jest przesyłany do serwera docelowego. Dla logowania pojedynczego (SSO) token LTPA jest odbierany w informacji cookie, a token jest używany dla logowania. Jeśli niestandardowy moduł logowania wymaga nazwy użytkownika od tokenu LTPA, moduł może użyć następującej metody, aby pobrać unikalny identyfikator z tokenu:

    com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
    validateLTPAToken(byte[])

    Po pobraniu unikalnego identyfikatora należy użyć następującej metody, aby pobrać nazwę użytkownika:

    com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
    getUserFromUniqueID(uniqueID)

    Ważne: Za każdym razem, gdy niestandardowy moduł logowania jest podłączony przed modułami logowania serwera aplikacji i zmienia tożsamość za pomocą usługi odwzorowania uwierzytelnień, ważne jest, aby ten moduł logowania sprawdził poprawność tokenu LTPA, jeśli jest on obecny. Wywołanie następującej metody wystarczy, aby sprawdzić poprawność zaufania w tokenie LTPA:

    com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
    validateLTPAToken(byte[])

    Serwer odbierający musi posiadać te same klucze LTPA, co serwer wysyłający, aby sprawdzenie poprawności było możliwe. Jeśli nie wykonano sprawdzenia poprawności tokenu LTPA, istnieje ryzyko naruszenia zabezpieczeń.
  • Kombinacja dowolnych poprzednio wymienionych wywołań zwrotnych i wywołania zwrotnego callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List: "); callback.
    To wywołanie zwrotne wskazuje, że niektóre propagowane atrybuty zostały dostarczone do serwera. Propagowane atrybuty wciąż wymagają jednej z następujących metod uwierzytelniania:
    • callbacks[0] = new javax.security.auth.callback.
      NameCallback("Username: ");

    • callbacks[1] = new javax.security.auth.callback.
      PasswordCallback("Password: ", false);

    • callbacks[2] = new com.ibm.websphere.security.auth.callback.
      WSCredTokenCallbackImpl("Credential Token: ");

    Jeśli atrybuty zostaną dodane do Tematu przez prostego klienta, wywołania zwrotne NameCallback oraz PasswordCallback uwierzytelniają informacje i obiekty, które zostały przekształcone do postaci cyfrowej w elemencie tokenu zostaną dodane do uwierzytelnionego Tematu.

    Jeśli włączono asercję tożsamości i propagację, serwer aplikacji użyje wywołania zwrotnego NameCallback oraz elementu tokenu zawierającego wszystkie propagowane atrybuty w celu przekształcenia większości obiektów z postaci cyfrowej. Serwer aplikacji używa wywołania zwrotnego NameCallback z powodu ustanowienia zaufania z serwerami wskazanymi na liście serwerów zaufanych CSIv2. Aby określić zaufane serwery, wykonaj następujące kroki:
    1. Kliknij opcję Zabezpieczenia > Zabezpieczenia globalne.
    2. Na karcie Uwierzytelnianie kliknij opcję Uwierzytelnianie danych przychodzących CSIv2.

    Niestandardowy moduł logowania musi obsługiwać niestandardową metodę przekształcania do postaci szeregowej. Dodatkowe informacje zawiera sekcja "Propagowanie atrybutu zabezpieczeń" w centrum informacyjnym.

Oprócz poprzednio zdefiniowanych wywołań, konfiguracja logowania WEB_INBOUND może zawierać tylko następujące dodatkowe wywołania zwrotne:
Wywołanie zwrotne

callbacks[4] = new com.ibm.websphere.security.auth.callback.
WSServletRequestCallback("HttpServletRequest: ");

Odpowiedzialność
Pobiera obiekty żądań serwletu HTTP, jeśli istnieją. To wywołanie zwrotne umożliwia modułom logowania pobranie informacji z żądania HTTP w celu wykorzystania podczas logowania.
Wywołanie zwrotne

callbacks[5] = new com.ibm.websphere.security.auth.callback.
WSServletResponseCallback("HttpServletResponse: ");

Odpowiedzialność
Pobiera obiekty odpowiedzi serwletu HTTP, jeśli istnieją. To wywołanie zwrotne umożliwia modułom logowania dodanie informacji do odpowiedzi HTTP jako wynik logowania. Na przykład, moduły logowania mogą dodać informację cookie SingleSignonCookie do odpowiedzi.
Wywołanie zwrotne

callbacks[6] = new com.ibm.websphere.security.auth.callback.
WSAppContextCallback("ApplicationContextCallback: ");

Odpowiedzialność
Pobiera kontekst aplikacji WWW używany podczas logowania. To wywołanie zwrotne składa się z tabeli mieszającej, która (jeśli istnieje) zawiera nazwę aplikacji i przekierowany adres WWW.
Wywołanie zwrotne

callbacks[7] = new WSRealmNameCallbackImpl("Realm Name: ",
<dziedzina_domyślna>);

Odpowiedzialność
Pobierz nazwę dziedziny dla informacji logowania. Informacja dziedziny nie musi być zawsze dostarczona i powinna być uznawana jako dziedzina bieżąca, jeśli jej nie dostarczono.
Wywołanie zwrotne

callbacks[8] = new WSX509CertificateChainCallback("X509Certificate[]: ");

Odpowiedzialność
Jeśli źródło logowania to certyfikat X509Certificate pobrany z uwierzytelniania klienta SSL, to wywołanie zwrotne zawiera certyfikat sprawdzony przez SSL. Moduł ltpaLoginModule wywołuje te same funkcje odwzorowania, co w poprzednich wydaniach. Po przekazaniu do logowania, dostarcza on moduł logowania niestandardowego z możliwością odwzorowania certyfikatu w niestandardowy sposób. Następnie uruchamiane jest logowanie tabeli mieszającej (przykład logowania tabeli mieszającej można znaleźć w temacie Moduł logowania niestandardowego dla odwzorowania przychodzącego).
Jeśli zaistniała potrzeba użycia propagacji atrybutu zabezpieczeń za pomocą konfiguracji logowania WEB_INBOUND, można uruchomić opcję Propagacja atrybutu zabezpieczeń przychodzących WWW w panelu Pojedyncze logowanie.
  1. Kliknij opcję Zabezpieczenia > Zabezpieczenia globalne.
  2. Na karcie Uwierzytelnianie rozwiń menu Zabezpieczenia WWW i kliknij opcję Logowanie pojedyncze (SSO).
  3. Zaznacz opcję Propagacja atrybutu zabezpieczeń przychodzących WWW.
Następujące moduły logowania zostały zdefiniowane fabrycznie dla konfiguracji logowania do systemu RMI_INBOUND, WEB_INBOUND i DEFAULT. Można dodać niestandardowe moduły logowania przed, między lub po modułach logowania, ale nie można usunąć tych zdefiniowanych fabrycznie modułów:
  • com.ibm.ws.security.server.lm.ltpaLoginModule
    Uruchamia logowanie podstawowe, jeśli propagacja atrybutu jest włączona lub wyłączona. Logowanie podstawowe używa zwykłych informacji uwierzytelniania, jak np. identyfikator użytkownika i hasło, token LTPA lub przechwytywacz powiązania zaufań (TAI) oraz nazwę wyróżniającą certyfikatu. Jeśli którykolwiek z następujących scenariuszy jest prawdziwy, ten moduł logowania nie zostanie użyty, a moduł the.com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule wykonuje logowanie podstawowe:
    • Obiekt java.util.Hashtable zawierający wymagane atrybuty użytkownika jest zawarty w Temacie.
    • Obiekt java.util.Hashtable wraz z wymaganymi atrybutami użytkownika jest obecny w atrybucie sharedState HashMap obiektu LoginContext.
    • Wywołanie zwrotne WSTokenHolderCallback istnieje bez określonego hasła. Jeśli nazwa użytkownika i hasło są obecne w wywołaniu zwrotnym WSTokenHolderCallback, który wskazuje propagowane informacje, żądanie jest wysyłanym z prostego klienta lub serwera z innej dziedziny, która odwzorowała istniejącą tożsamość na użytkownika i hasło.
  • com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule
    Ten moduł logowania wykonuje logowanie za pomocą zwykłej informacji uwierzytelniania, jeśli dowolny z poniższych warunków jest prawdziwy:
    • Obiekt java.util.Hashtable z wymaganymi atrybutami użytkownika jest zawarty w Temacie.
    • Obiekt java.util.Hashtable z wymaganymi atrybutami użytkownika jest zawarty w obiekcie sharedState HashMap kontekstu LoginContext.
    • Wywołanie zwrotne WSTokenHolderCallback istnieje bez wywołania PasswordCallback.

    Jeśli obiekt java.util.Hashtable istnieje, moduł logowania odwzorowuje atrybuty obiektu do poprawnego Tematu. Jeśli wywołanie WSTokenHolderCallback jest obecne, moduł logowania przekształca obiekt tokenu bajtowego z postaci cyfrowej i ponownie generuje treść Tematu przekształconego do postaci cyfrowej. Tabela mieszająca java.util.Hashtable ma znaczenie rozstrzygające przed wszystkimi pozostałymi formami logowania. Należy pamiętać, aby zapobiec duplikacji nadpisania danych propagowanych poprzednio przez serwer aplikacji.

    Poprzez określenie tabeli mieszającej java.util.Hashtable, aby miała znaczenie rozstrzygające przed informacją uwierzytelniania, niestandardowy moduł logowania sprawdził poprawność tokenu LTPA (jeśli istnieje), aby ustanowić wystarczające zaufanie. Niestandardowy moduł logowania może użyć metody com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validationLTPAToken(byte[]) w celu sprawdzenia poprawności tokenu LTPA zawartego w wywołaniu zwrotnym WSCredTokenCallback. Niepowodzenie podczas sprawdzania poprawności tokenu LTPA oznacza zagrożenie zabezpieczeń.

    Dodatkowe informacje dotyczące dodawania tabeli mieszającej, która zawiera ogólnie znane i utworzone atrybuty używane przez serwer aplikacji jako wystarczające informacje logowania zawiera sekcja "Konfigurowanie odwzorowania tożsamości przychodzącej" w centrum informacyjnym.

RMI_OUTBOUND

Przetwarza żądania RMI (Remote Method Invocation) wysyłane na zewnątrz do innego serwera, jeśli właściwości com.ibm.CSI.rmiOutboundLoginEnabled lub the com.ibm.CSIOutboundPropagationEnabled posiadają wartość true.

Te właściwości są ustawiane w panelu uwierzytelniania CSIv2. Aby otworzyć panel, wykonaj następujące kroki:
  1. Kliknij opcję Zabezpieczenia > Zabezpieczenia globalne.
  2. Na karcie Uwierzytelnianie, rozwiń menu Zabezpieczenia RMI/IIOP kliknij opcję Uwierzytelnianie wychodzące CSIv2.
Aby ustawić właściwość com.ibm.CSI.rmiOutboundLoginEnabled wybierz opcję Niestandardowe odwzorowanie przychodzące. Aby ustawić właściwość com.ibm.CSIOutboundPropagationEnabled, kliknij opcję Propagacja atrybutu zabezpieczeń.

Ta konfiguracja logowania określa możliwości konfiguracyjne serwera docelowego i jego domeny zabezpieczeń. Jeśli na przykład serwer aplikacji w wersji 5.1.1 lub nowszej (lub 5.1.0.2 dla platformy z/OS) komunikuje się z serwerem aplikacji w wersji 5.x, serwer aplikacji 5.1.1 wysyła tylko informacje uwierzytelniania do serwera aplikacji za pomocą znacznika LTPA. Jeśli jednak serwer WebSphere Application Server 5.1.1 lub nowszy komunikuje się z serwerem aplikacji w wersji 5.1.x, informacje uwierzytelniania i autoryzacji są przesyłane do odbierającego je serwera aplikacji, jeśli propagacja zostanie włączona na serwerze wysyłającym i odbierającym. Jeśli serwer aplikacji wysyła informacje uwierzytelniania i autoryzacji do serwera zgodnie z kierunkiem przesyłania, serwer aplikacji umożliwia pominięcie kolejnego uzyskania dostępu do bazy danych i wyszukanie atrybutów zabezpieczeń użytkownika dla celów autoryzacji. Dodatkowo, dowolne obiekty niestandardowe, które zostały dodane w serwerze wysyłającym są obecne w Temacie serwera.

Następujące wywołanie zwrotne jest dostępne w konfiguracji logowania RMI_OUTBOUND. Można użyć strategii obiektu com.ibm.wsspi.security.csiv2.CSIv2PerformPolicy zwracanego przez własne wywołanie zwrotne w celu wysłania zapytania strategii zabezpieczeń dla danego żądania wychodzącego. To zapytanie może pomóc w określeniu, czy dziedzina docelowa jest inna niż dziedzina bieżąca, co oznacz konieczność odwzorowania dziedziny. Dodatkowe informacje zawiera sekcja "Konfigurowanie odwzorowania wychodzącego do innej dziedziny docelowej" w centrum informacyjnym.

Wywołanie zwrotne
callbacks[0] = new WSProtocolPolicyCallback("Protocol Policy Callback: ");
Odpowiedzialność

Udostępnia specyficzną dla protokołu informację strategii dla modułów logowania w tym wywołaniu wychodzącym. Ta informacja jest używana w celu określenia poziomu zabezpieczeń, łącznie z dziedziną docelową oraz docelowymi i połączonymi wymaganiami zabezpieczeń.

Następująca metoda pobiera strategię CSIv2PerformPolicy z tego specyficznego modułu logowania:

csiv2PerformPolicy = (CSIv2PerformPolicy)
((WSProtocolPolicyCallback)callbacks[0]).getProtocolPolicy();

Protokół inny niż RMI może posiadać inny typ obiektu strategii.

Następujący moduł logowania został zdefiniowany fabrycznie w konfiguracji logowania RMI_OUTBOUND. Można dodać niestandardowe moduły logowania przed, między lub po modułach logowania, ale nie można usunąć zdefiniowanych fabrycznie modułów.
com.ibm.ws.security.lm.wsMapCSIv2OutboundLoginModule
Pobiera następujące tokeny i obiekty przed utworzeniem przysłaniającego bajtu, który zostanie wysłany do innego serwera za pomocą warstwy tokenu autoryzacji Common Secure Interoperability Version 2 (CSIv2):
  • Implementacje com.ibm.wsspi.security.token.Token zawarte w Temacie
  • Niestandardowe obiekty tematu z możliwością serializacji
  • Tokeny propagacji z wątku

Można użyć niestandardowego modułu logowania przed tym modułem logowania, aby odwzorować uwierzytelnianie. Jest jednak zalecane, aby moduł logowania zmienił treść Tematu przekazanego podczas fazy logowania. Jeśli to zalecenie zostanie spełnione, moduły logowania zostaną przetworzone po zmodyfikowaniu nowej treści Tematu przez ten moduł logowania.

Dodatkowe informacje zawiera sekcja "Konfigurowanie odwzorowania wychodzącego do innej dziedziny docelowej" w centrum informacyjnym.

SWAM [AIX Solaris HP-UX Linux Windows] [iSeries]

Przetwarza żądania logowania w środowisku pojedynczego serwera, jeśli mechanizm SWAM (Simple WebSphere Authentication Mechanism) jest używany jako metoda uwierzytelniania.

Mechanizm SWAM nie obsługuje uwierzytelnień z możliwością przekierowania. Jeśli SWAM jest metodą uwierzytelniania, serwer aplikacji nie może przesyłać żądań z serwera na serwer. W tym przypadku należy użyć LTPA.
Uwaga: Konfiguracja logowania SWAM jest nieaktualna i zostanie usunięta w kolejnych wydaniach.
[z/OS] Uwaga: Mechanizm SWAM jest nieaktualny dla serwera aplikacji 7.0 i zostanie usunięty w kolejnej wersji.
wssecurity.IDAssertion [Tylko wersja 5]

Przetwarza żądania konfiguracji logowania dla zabezpieczeń usług WWW za pomocą asercji tożsamości.

Ta konfiguracja logowania jest przeznaczona dla aplikacji JAX-RPC (wersja 5.x) WS-Security (wersja robocza numer 13). Dodatkowe informacje zawiera sekcja "Metoda uwierzytelniania asercji tożsamości" w centrum informacyjnym.

wssecurity.IDAssertionUsernameToken [Tylko wersja 6]

Przetwarza żądania konfiguracji logowania dla zabezpieczeń usług WWW za pomocą asercji tożsamości.

Ta konfiguracja logowania jest przeznaczona dla aplikacji JAX-RPC WS-Security w wersji 1.0.

Dla modułu logowania JAAS IDAssertionUsernameToken można skonfigurować właściwość niestandardową com.ibm.wsspi.wssecurity.auth.module.IDAssertionLoginModule.disableUserRegistryCheck. Właściwość ta stanowi opcję dla modułu logowania JAAS asercji tożsamości zabezpieczeń usług WWW o nazwie wssecurity.IDAssertionUsernameToken. Wskazuje ona, że moduł logowania nie ma wykonywać sprawdzania rejestru użytkowników podczas przetwarzania przychodzącego znacznika tożsamości.

wssecurity.PKCS7

Weryfikuje certyfikat X.509 za pomocą listy odwołań certyfikatów w obiekcie PKCS7 (Public Key Cryptography Standards #7).

Ta konfiguracja logowania jest przeznaczona dla systemów wersji 6.0.x.

wssecurity.PkiPath

Weryfikuje certyfikat X.509 za pomocą ścieżki infrastruktury kluczy publicznych (PKI).

Ta konfiguracja logowania jest przeznaczona dla systemów wersji 6.0.x.

wssecurity.signature

Przetwarza żądania konfiguracji logowania dla zabezpieczeń usług WWW, sprawdzając poprawność podpisu cyfrowego.

Ta konfiguracja logowania jest używana przez systemy wersji 5.x.

wssecurity.UsernameToken

Sprawdza poprawność uwierzytelniania podstawowego (nazwa użytkownika i hasła).

Jeśli używane jest środowisko wykonawcze JAX-RPC, dla modułu logowania JAAS UsernameToken można skonfigurować następujące właściwości niestandardowe:

Dla modułu logowania JAAS UsernameToken można skonfigurować właściwość niestandardową com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule.disableUserRegistryCheck. Właściwość ta stanowi opcję dla modułu logowania JAAS UsernameToken zabezpieczeń usług WWW o nazwie com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule. Wskazuje ona, że moduł logowania nie ma wykonywać sprawdzania rejestru użytkowników podczas przetwarzania przychodzącego znacznika nazwy użytkownika.

wssecurity.X509BST

Sprawdza poprawność binarnego tokenu zabezpieczeń (BST) dla certyfikatu X.509, weryfikując ważność certyfikatu i ścieżki certyfikatu.

Ta konfiguracja logowania jest przeznaczona dla systemów wersji 6.0.x.

LTPA_WEB

Przetwarza żądania logowania dla komponentów w kontenerach WWW, jak np. serwlety i pliki stron JavaServer (JSP).

Moduł logowania com.ibm.ws.security.web.AuthenLoginModule został fabrycznie zdefiniowany w konfiguracji logowania LTPA. Można dodać niestandardowe moduły logowania przed lub po tym module w konfiguracji logowania LTPA_WEB.

Konfiguracja logowania LTPA_WEB może przetwarzać obiekt HttpServletRequest, HttpServletResponse oraz nazwę aplikacji WWW, które przekazano za pomocą programu obsługi wywołania zwrotnego. Dodatkowe informacje zawiera sekcja Przykład: Dostosowywanie uwierzytelniania JAAS (Java Authentication and Authorization Service) oraz konfiguracji logowania w Centrum informacyjnym.

LTPA

Przetwarza żądania logowania, które nie zostały obsłużone przez konfigurację logowania LTPA_WEB.

Ta konfiguracja logowania jest używana przez serwer WebSphere Application Server 5.1 i poprzednie wersje.

Moduł logowania com.ibm.ws.security.server.lm.ltpaLoginModule został fabrycznie zdefiniowany w konfiguracji logowania LTPA. Można dodać niestandardowe moduły logowania przed lub po tym module w konfiguracji logowania LTPA. Dodatkowe informacje zawiera sekcja Przykład: Dostosowywanie uwierzytelniania JAAS (Java Authentication and Authorization Service) oraz konfiguracji logowania w Centrum informacyjnym.




Zaznaczone odsyłacze (online) wymagają dostępu do Internetu.

Pojęcia pokrewne
Zadania pokrewne
Odsyłacze pokrewne
Ustawienia pozycji konfiguracji dla usługi Java Authentication and Authorization Service (JAAS)


Nazwa pliku: usec_sysjaas.html