Nastavení položek konfigurace přihlašování k systému pro službu JAAS (Java Authentication and Authorization Service)

Na této stránce můžete zadat seznam konfigurací služby JAAS (Java Authentication and Authorization Service) pro přihlášení k systému.

Chcete-li zobrazit tuto stránku konzoly pro správu, postupujte podle následujících kroků:
  1. Klepněte na volbu Zabezpečení > Globální zabezpečení.
  2. V části Ověřování klepněte na volbu Služba JAAS (Java Authentication and Authorization Service) > Přihlášení k systému.
Před definováním dalších přihlašovacích modulů s ověřováním pro běhový modul zabezpečení aplikačního serveru se seznamte s dokumentací ke službě JAAS (Java Authentication and Authorization Service). Neodstraňujte následující systémové přihlašovací moduly:
RMI_INBOUND, WEB_INBOUND, DEFAULT

Zpracovává příchozí žádosti o přihlášení pro službu RMI (Remote Method Invocation), webové aplikace a většinu dalších přihlašovacích protokolů.

RMI_INBOUND
Tato konfigurace přihlašování zpracovává přihlašování pro příchozí žádosti služby RMI. Obvykle se při těchto přihlášeních jedná o žádosti o ověřený přístup k souborům EJB (Enterprise JavaBeans). Při použití konektoru RMI se u těchto přihlášení může jednat o žádosti o rozšíření JMX (Java Management Extensions).
WEB_INBOUND
Tato konfigurace přihlašování zpracovává přihlášení pro požadavky webové aplikace včetně servletů a souborů JSP (JavaServer Pages). Tato konfigurace přihlášení může komunikovat s výstupem generovaným modulem TAI, pokud je nainstalován. Subjekt předávaný do konfigurace přihlášení WEB_INBOUND může obsahovat objekty generované modulem TAI.
DEFAULT
Tato konfigurace přihlašování zpracovává přihlášení pro příchozí žádosti, které mohou být vytvořeny s použitím většiny ostatních protokolů a interních ověření.

Tyto tři konfigurace přihlašování budou předávat následující údaje zpětného volání, které jsou zpracovávány přihlašovacími moduly v rámci těchto konfigurací. Tato zpětná volání nejsou předávána zároveň. Avšak kombinace těchto zpětných volání určuje způsob, jakým aplikační server ověřuje uživatele.

Zpětné volání

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

Odpovědnost
Získá jméno uživatele zadané při přihlašování. Tato informace může být použita jako jméno uživatele pro následující typy přihlášení:
  • Přihlášení pomocí jména uživatele a hesla (označováno výrazem základní ověřování).
  • Jméno uživatele pouze pro deklaraci identity bez hesla.
Zpětné volání

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

Odpovědnost
Získá heslo zadané při přihlašování. Heslo s hodnotou Null je povoleno a používáno k podpoře deklarace identity.
Zpětné volání

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

Odpovědnost
Shromažďuje údaje tokenu LTPA (Lightweight Third Party Authentication) nebo jiného typu tokenu v průběhu procesu přihlášení. Obvykle jsou tyto údaje k dispozici, pokud není dostupné jméno a heslo uživatele.
Zpětné volání

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

Odpovědnost
Shromažďuje údaje seznamu ArrayList objektů TokenHolder, které jsou navráceny z volání do modulu WSOpaqueTokenHelper. Při zpětném volání je použita metoda createTokenHolderListFromOpaqueToken s tokenem ověření CSIv2 (Common Secure Interoperability verze 2) na vstupu.
Omezení: Toto zpětné volání je k dispozici pouze v případě, že je aktivována volba Šíření atributu zabezpečení a že tyto přihlašovací údaje jsou přihlášením pro šíření. V případě přihlašovacích údajů pro šíření je s žádostí šířen dostatečný počet atributů zabezpečení, čímž je odstraněna nutnost přístupu do registru s cílem získání dalších atributů. Pro příchozí i odchozí ověřování je nutné aktivovat funkci šíření atributů zabezpečení.
Volbu Šíření atributu zabezpečení pro odchozí ověřování CSIv2 lze aktivovat provedením dvou následujících kroků:
  1. Klepněte na volbu Zabezpečení > Globální zabezpečení.
  2. V části Ověřování rozbalte položku Zabezpečení RMI/IIOP a klepněte na volbu Odchozí ověřování CSIv2.
  3. Aktivujte volbu Šíření atributu zabezpečení.
Volbu Šíření atributu zabezpečení pro příchozí ověřování CSIv2 lze aktivovat provedením dvou následujících kroků:
  1. Klepněte na volbu Zabezpečení > Globální zabezpečení.
  2. V části Ověřování rozbalte položku Zabezpečení RMI/IIOP a klepněte na volbu Příchozí ověřování CSIv2.
  3. Aktivujte volbu Šíření atributu zabezpečení.

V konfiguracích přihlášení k systému je uživatel aplikačním serverem ověřován na základě údajů shromážděných prostřednictvím zpětných volání. Modul vlastního přihlašování však nemusí jednat podle žádného z těchto zpětných volání. V následujícím seznamu jsou uvedeny obvyklé kombinace těchto zpětných volání:

  • Pize zpětné volání callbacks[0] = new javax.security.auth.callback.NameCallback("Username: ");

    Toto zpětné volání se používá pro deklaraci identity CSIv2, pro webová přihlášení nebo přihlášení CSIv2 s certifikátem X509, pro přihlášení s použitím modulu TAI staršího typu atd. Při webových přihlášeních a přihlášeních CSIv2 s certifikátem X509 aplikační server mapuje certifikát na jméno uživatele. Toto zpětné volání je používáno pro kterékoli typy přihlášení, které vytvářejí vztah důvěryhodnosti pouze prostřednictvím jména uživatele.

  • Zpětná volání callbacks[0] = new javax.security.auth.callback.NameCallback("Username: "); i callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password: ", false);

    Tato kombinace zpětných volání je typická pro přihlašování se základním ověřováním. Většina ověřování uživatelů je prováděna s použitím těchto dvou zpětných volání.

  • Pouze zpětné volání callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token: ");
    Toto zpětné volání slouží k ověření tokenu LTPA (Lightweight Third Party Authentication). Tento typ ověření se obvykle používá při jednotném přihlašování (SSO) nebo při přihlašování po směru zpracování. Na každou žádost pocházející z aplikačního serveru je namísto vlastního tokenu klienta předán do cílového serveru token LTPA. V případě jednotného přihlašování (SSO) je token LTPA přijat v souboru cookie a tento token je použit pro přihlášení. Pokud vlastní modul přihlašování potřebuje z tokenu LTPA získat jméno uživatele, může tento modul načíst jedinečný identifikátor (ID) z tokenu pomocí následující metody:

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

    Po načtení jedinečného identifikátoru (ID) můžete získat jméno uživatele pomocí následující metody:

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

    Důležité: Pokud je před přihlašovacími moduly aplikačního serveru připojen vlastní přihlašovací modul, který mění identitu prostřednictvím služby mapování údajů pověření, je důležité, aby tento přihlašovací modul ověřil token LTPA (pokud je přítomen). K ověření důvěryhodnosti v tokenu LTPA stačí volání následující metody:

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

    Aby toto ověření bylo úspěšné, musí mít přijímající server k dispozici stejné klíče LTPA jako odesílající server. Pokud není tento token LTPA ověřen (pokud je přítomen), může vzniknout bezpečnostní riziko.
  • Kombinace některých z uvedených zpětných volání spolu se zpětným voláním callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List: ");
    Toto zpětné volání indikuje, že server obdržel některé šířené atributy. Tyto šířené atributy stále vyžadují ověření některou z následujících metod:
    • 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: ");

    Pokud jsou atributy přidány do subjektu přímo z klienta, budou tyto informace ověřeny prostřednictvím zpětného volání NameCallback a PasswordCallback a objekty serializované v držiteli tokenu budou přidány do ověřeného subjektu.

    Pokud je aktivována deklarace identity CSIv2 i funkce šíření, aplikační server provede pomocí zpětného volání NameCallback a držitele tokenu, který obsahuje šířené atributy, deserializaci většiny objektů. Aplikační server používá zpětné volání NameCallback, protože je navazován vztah důvěry se servery, které jsou označeny v seznamu důvěryhodných serverů CSIv2. Chcete-li specifikovat důvěryhodné servery, proveďte následující kroky:
    1. Klepněte na volbu Zabezpečení > Globální zabezpečení.
    2. V části Ověřování klepněte na volbu Příchozí ověřování CSIv2.

    Vlastní serializace musí být zpracována vlastním přihlašovacím modulem. Další informace najdete v informačním centru v části Šíření atributů zabezpečení.

Kromě dříve definovaných zpětných volání může konfigurace přihlášení WEB_INBOUND obsahovat pouze tato další zpětná volání:
Zpětné volání

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

Odpovědnost
Shromažďuje údaje objektu požadavku servletu HTTP (pokud existuje). Toto zpětné volání umožňuje přihlašovacím modulům načíst informace z požadavků HTTP, které mají být při přihlášení použity.
Zpětné volání

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

Odpovědnost
Shromažďuje údaje objektu odpovědi servletu HTTP (pokud existuje). Toto zpětné volání umožňuje přihlašovacím modulům přidat informace do odpovědi HTTP jako výsledek přihlášení. Přihlašovací moduly mohou například do odpovědi přidat soubor cookie SingleSignonCookie.
Zpětné volání

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

Odpovědnost
Shromažďuje údaje kontextu webové aplikace používaného při přihlášení. Toto zpětné volání sestává z hašovací tabulky, která obsahuje (pokud existuje) název aplikace a přesměrovanou webovou adresu.
Zpětné volání

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

Odpovědnost
Shromažďuje název oblasti pro informace o přihlášení. Informace o oblasti nemusí být k dispozici vždy; nejsou-li k dispozici, mělo by se předpokládat použití aktuální oblasti.
Zpětné volání

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

Odpovědnost
Pokud je zdrojem přihlášení objekt X509Certificate z ověřování klienta prostřednictvím protokolu SSL, toto zpětné volání obsahuje certifikát ověřený prostřednictvím protokolu SSL. Modul ltpaLoginModule volá stejné funkce mapování jako v předchozích verzích. Po předání do komponenty pro přihlášení poskytuje vlastní přihlašovací modul s příležitostí k mapování certifikátu vlastním způsobem. Poté provede přihlášení s použitím hašovací tabulky (příklad přihlášení s použitím hašovací tabulky naleznete prostřednictvím souvisejícího odkazu Vlastní přihlašovací modul pro příchozí mapování).
Pokud chcete použít pro konfiguraci přihlášení WEB_INBOUND funkci šíření atributů zabezpečení, můžete aktivovat volbu Šíření příchozích webových atributů zabezpečení na panelu Jednotné přihlášení.
  1. Klepněte na volbu Zabezpečení > Globální zabezpečení.
  2. V části Ověřování rozbalte položku Webové zabezpečení a klepněte položku Jednotné přihlášení (SSO).
  3. Vyberte volbu Šíření příchozích webových atributů zabezpečení.
V následujícím seznamu jsou uvedeny předdefinované přihlašovací moduly pro konfigurace přihlášení k systému RMI_INBOUND, WEB_INBOUND a DEFAULT. Před tyto přihlašovací moduly, mezi ně nebo za ně můžete přidat vlastní přihlašovací moduly. Tyto předdefinované přihlašovací moduly však nelze odebrat:
  • com.ibm.ws.security.server.lm.ltpaLoginModule
    Provádí primární přihlášení při aktivované nebo deaktivované funkci šíření atributů. Při primárním přihlášení jsou používány běžné ověřovací údaje, jako je například jméno a heslo uživatele, token LTPA nebo modul TAI či rozlišující název (DN) certifikátu. Pokud platí některý z následujících scénářů, není tento přihlašovací modul použit a primární přihlášení je provedeno pomocí přihlašovacího modulu com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule.
    • Subjekt obsahuje objekt java.util.Hashtable s požadovanými atributy uživatele.
    • Tabulka sharedState HashMap objektu LoginContext obsahuje objekt java.util.Hashtable s požadovanými atributy uživatele.
    • Existuje zpětné volání WSTokenHolderCallback bez zadaného hesla. Pokud existuje jméno a heslo uživatele pro zpětné volání WSTokenHolderCallback s indikací šíření informací, pochází tento požadavek pravděpodobně přímo z klienta nebo ze serveru z jiné sféry, pro který byla existující identita mapována na jméno a heslo uživatele.
  • com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule
    Tento přihlašovací modul provádí primární přihlášení s použitím běžných údajů ověřování, pokud je splněna některá z následujících podmínek:
    • Některý subjekt obsahuje objekt java.util.Hashtable s požadovanými atributy uživatele.
    • Tabulka sharedState HashMap objektu LoginContext obsahuje objekt java.util.Hashtable s požadovanými atributy uživatele.
    • Existuje zpětné volání WSTokenHolderCallback bez zpětného volání PasswordCallback.

    Pokud existuje objekt java.util.Hashtable, přihlašovací modul mapuje atributy objektu do platného subjektu. Pokud existuje zpětné volání WSTokenHolderCallback, přihlašovací modul deserializuje bajtové objekty tokenu a znovu vygeneruje serializovaný obsah subjektu. Hašovací tabulka java.util.Hashtable má přednost před všemi ostatními formami přihlašování. Přitom je třeba zachovávat obezřetnost, aby nedošlo k duplikování nebo přepsání údajů, které mohly být aplikačním serverem šířeny dříve.

    Vzhledem ke specifikaci hašovací tabulky java.util.Hashtable, která má přednost před ostatními ověřovacími údaji, již muselo proběhnout ověření tokenu LTPA (pokud existuje) vlastním přihlašovacím modulem s cílem navázání dostatečně důvěryhodného vztahu. Vlastní přihlašovací modul může použít metodu com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validationLTPAToken(byte[]) pro ověření tokenu LTPA, který existuje v rámci zpětného volání WSCredTokenCallback. Neúspěšné ověření tokenu LTPA představuje bezpečnostní riziko.

    Další informace o přidání hašovací tabulky obsahující známé a správně vytvořené atributy, které jsou aplikačním serverem používány jako dostatečné informace pro přihlášení, najdete v informačním centru v části Konfigurování mapování příchozí identity.

RMI_OUTBOUND

Zpracovává požadavky RMI (Remote Method Invocation) odeslané na jiný server, je-li pro vlastnost com.ibm.CSI.rmiOutboundLoginEnabled nebo com.ibm.CSIOutboundPropagationEnabled nastavena hodnota true.

Tyto vlastnosti se nastavují na panelu ověřování CSIv2. Chcete-li k panelu přistupovat, postupujte podle následujících kroků:
  1. Klepněte na volbu Zabezpečení > Globální zabezpečení.
  2. V části Ověřování rozbalte položku Zabezpečení RMI/IIOP a klepněte na volbu Odchozí ověřování CSIv2.
Chcete-li nastavit vlastnost com.ibm.CSI.rmiOutboundLoginEnabled, vyberte volbu Vlastní odchozí mapování. Chcete-li nastavit vlastnost com.ibm.CSIOutboundPropagationEnabled, vyberte volbu Šíření atributu zabezpečení.

Tato konfigurace přihlašování určuje funkce zabezpečení cílového serveru a příslušné domény zabezpečení. Pokud například server Application Server verze 5.1.1 nebo novější (nebo 5.1.0.2 pro systém z/OS) komunikuje se serverem Application Server verze 5.x, odesílá server Application Server verze 5.1.1 ověřovací údaje pouze do serveru Application Server verze 5.x s použitím tokenu LTPA. Pokud však server WebSphere Application Server verze 5.1.1 nebo novější komunikuje se serverem Application Server verze 5.1.x, jsou ověřovací a autorizační údaje odeslány do přijímajícího aplikačního serveru tehdy, pokud je aktivována funkce šíření u obou serverů (odesílajícího i přijímajícího). Pokud aplikační server odešle ověřovací a autorizační údaje na další servery po směru zpracování, je pro aplikační servery odstraněna nutnost znovu přistupovat do registru uživatelů a vyhledávat atributy zabezpečení daného uživatele pro účely zabezpečení. Kromě toho jsou v subjektu na serveru nacházejícím se po směru zpracování obsaženy všechny vlastní objekty, které do něj byly přidány na odesílajícím serveru.

V konfiguraci přihlašování RMI_OUTBOUND je k dispozici následující zpětné volání. Chcete-li v zásadě zabezpečení vyhledat tento konkrétní odchozí požadavek, můžete použít objekt com.ibm.wsspi.security.csiv2.CSIv2PerformPolicy navrácený tímto zpětným voláním. Tento dotaz umožňuje určit, zda se cílová sféra liší od aktuální sféry a zda musí být daná sféra mapována aplikačním serverem. Další informace najdete v informačním centru v části Konfigurace odchozího mapování na jinou cílovou sféru.

Zpětné volání
callbacks[0] = new WSProtocolPolicyCallback("Protocol Policy Callback: ");
Odpovědnost

Poskytuje informace zásad (závislé na protokolu) pro přihlašovací moduly pro toto odchozí volání. Tyto informace jsou použity při určení úrovně zabezpečení, včetně cílové sféry, požadavků na zabezpečení pro cíl a souhrnných požadavků na zabezpečení.

Následující metoda obdrží zásadu CSIv2PerformPolicy z tohoto specifického přihlašovacího modulu:

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

Jinému protokolu než RMI může odpovídat jiný typ objektu zásady.

V konfiguraci přihlašování RMI_OUTBOUND je předdefinován následující přihlašovací modul. Před tyto přihlašovací moduly, mezi ně nebo za ně můžete přidat vlastní přihlašovací moduly. Tyto předdefinované přihlašovací moduly však nelze odebrat.
com.ibm.ws.security.lm.wsMapCSIv2OutboundLoginModule
Před vytvořením neprůhledného bajtu, který je odeslán do jiného serveru prostřednictvím vrstvy tokenů pro autorizaci CSIv2 (Common Secure Interoperability verze 2), načte následující tokeny a objekty.
  • Implementace com.ibm.wsspi.security.token.Token ze subjektu s možností předávání
  • Vlastní objekty ze subjektu s možností serializace
  • Tokeny šíření z podprocesu

Chcete-li provést mapování údajů pověření, můžete před tento přihlašovací modul zařadit vlastní přihlašovací modul. Doporučuje se však zajistit, aby daný přihlašovací modul změnil obsah subjektu předávaného během přihlašovací fáze. Pokud je toto doporučení dodrženo, budou ostatní přihlašovací moduly zpracovány až poté, co tento přihlašovací modul zpracuje nový obsah subjektu.

Další informace najdete v informačním centru v části Konfigurace odchozího mapování na jinou cílovou sféru.

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

Zpracovává požadavky na přihlášení v prostředí s jedním serverem, přičemž jako ověřovací metoda je použit mechanismus SWAM (Simple WebSphere Authentication Mechanism).

Mechanismus SWAM nepodporuje údaje pověření s možností dalšího předávání. Pokud je jako metoda ověřování použit mechanismus SWAM, nemůže aplikační server odesílat požadavky ze serveru na server. V tomto případě je nutné použít mechanismus ověřování LTPA.
Poznámka: Konfigurace přihlašování SWAM je zastaralá a v některém z následujících vydání bude odstraněna.
[z/OS] Poznámka: Mechanismus SWAM je na aplikačním serveru Verze 7.0 zastaralý a bude v budoucí verzi odstraněn.
wssecurity.IDAssertion [Pouze verze 5]

Ověřuje požadavky na konfiguraci přihlášení pro zabezpečení webových služeb s použitím deklarace identity.

Tato konfigurace přihlášení je určena pro aplikace vytvořené podle konceptu zabezpečení webových služeb JAX-RPC 13 (verze 5.x). Další informace najdete v informačním centru v části Metoda ověřování deklarace identity.

wssecurity.IDAssertionUsernameToken [Pouze verze 6]

Ověřuje požadavky na konfiguraci přihlášení pro zabezpečení webových služeb s použitím deklarace identity.

Tato konfigurace přihlášení je určena pro aplikace standardu zabezpečení webových služeb JAX-RPC verze 1.0.

Pro přihlašovací modul JAAS IDAssertionUsernameToken lze nastavit přizpůsobenou vlastnost com.ibm.wsspi.wssecurity.auth.module.IDAssertionLoginModule.disableUserRegistryCheck. Tato vlastnost představuje volbu přihlašovacího modulu JAAS deklarace identity zabezpečení webových služeb wssecurity.IDAssertionUsernameToken. Určuje, že přihlašovací modul nemá při zpracování příchozího tokenu identity provádět kontrolu registru uživatelů.

wssecurity.PKCS7

Ověřuje certifikát X.509 s použitím seznamu odvolaných certifikátů v objektu PKCS7 (Public Key Cryptography Standards #7).

Tato konfigurace přihlašování je určena pro systémy verze 6.0.x.

wssecurity.PkiPath

Ověřuje certifikát X.509 s cestou infrastruktury veřejného klíče (PKI).

Tato konfigurace přihlašování je určena pro systémy verze 6.0.x.

wssecurity.signature

Ověřuje požadavky na konfiguraci přihlášení pro zabezpečení webových služeb s použitím ověřování digitálního podpisu.

Tato konfigurace přihlašování je určena pro systémy verze 5.x.

wssecurity.UsernameToken

Ověřuje základní ověřování (jméno uživatele a heslo).

Při použití běhové komponenty JAX-RPC lze pro přihlašovací modul JAAS UsernameToken nastavit následující přizpůsobené vlastnosti:

Pro přihlašovací modul JAAS UsernameToken lze nastavit přizpůsobenou vlastnost com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule.disableUserRegistryCheck. Tato vlastnost představuje volbu přihlašovacího modulu JAAS UsernameToken zabezpečení webových služeb com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule. Určuje, že přihlašovací modul nemá při zpracování příchozího tokenu jména uživatele provádět kontrolu registru uživatelů.

wssecurity.X509BST

Ověřením platnosti certifikátu a cesty certifikátu ověřuje binární token zabezpečení X.509.

Tato konfigurace přihlašování je určena pro systémy verze 6.0.x.

LTPA_WEB

Zpracovává požadavky na komponenty ve webovém kontejneru, například servlety a soubory JSP (JavaServer Pages).

Pro konfiguraci přihlašování LTPA je předdefinován přihlašovací modul com.ibm.ws.security.web.AuthenLoginModule. Před tento přihlašovací modul nebo za něj můžete v konfiguraci přihlášení LTPA_WEB přidat vlastní přihlašovací moduly.

Konfigurace přihlašování LTPA_WEB může zpracovat objekt HttpServletRequest, objekt HttpServletResponse a název webové aplikace, které jsou předány manipulátorem zpětného volání. Další informace najdete v informačním centru v části Příklad: Přizpůsobení konfigurace přihlašování a ověřování službou JAAS (Java Authentication and Authorization Service) na straně serveru.

LTPA

Zpracovává požadavky na přihlášení, které nejsou zpracovány v rámci konfigurace přihlašování LTPA_WEB.

Tato konfigurace přihlašování je používána produktem WebSphere Application Server verze 5.1 nebo dřívější.

Pro konfiguraci přihlašování LTPA je předdefinován přihlašovací modul com.ibm.ws.security.server.lm.ltpaLoginModule. Před tento přihlašovací modul nebo za něj můžete v konfiguraci přihlašování LTPA přidat vlastní přihlašovací moduly. Další informace najdete v informačním centru v části Příklad: Přizpůsobení konfigurace přihlašování a ověřování službou JAAS (Java Authentication and Authorization Service) na straně serveru.




Odkazy s označením (online) vyžadují přístup k Internetu.

Související pojmy
Související úlohy
Související odkazy
Nastavení položek konfigurace pro službu JAAS (Java Authentication and Authorization Service)


Název souboru: usec_sysjaas.html