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 administrativní konzoly, postupujte podle následujícího postupu:

Klepněte na volbu Zabezpečení > Globální zabezpečení.
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). Neodebírejte následující systémové přihlašovací moduly:

RMI_INBOUND
WEB_INBOUND
DEFAULT
RMI_OUTBOUND
SWAM
SWAM
wssecurity.IDAssertion
wssecurity.signature
wssecurity.PKCS7
wssecurity.PkiPath
wssecurity.UsernameToken
wssecurity.X509BST
LTPA
LTPA_WEB
Poznámka: Moduly LTPA_WEB a WEB_INBOUND provádějí podobné funkce. Doporučuje se používat modul WEB_INBOUND, protože se jedná o novější ze systémových přihlašovacích modulů.
DESERIALIZE_ASYNCH_CONTEXT

ICSF

Zpracovává žádosti o přihlášení při použití mechanizmu ověřování ICSF (Integrated Cryptographic Services Facility).

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 povolena 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é povolit funkci šíření atributů zabezpečení.

Volbu Šíření atributu zabezpečení pro odchozí ověřování CSIv2 lze povolit provedením dvou následujících kroků:

Klepněte na volbu Zabezpečení > Globální zabezpečení.
V části Ověřování rozbalte položku Zabezpečení RMI/IIOP a klepněte na volbu Odchozí ověřování CSIv2.
Povolte volbu Šíření atributu zabezpečení.

Volbu Šíření atributu zabezpečení pro příchozí ověřování CSIv2 lze povolit provedením dvou následujících kroků:

Klepněte na volbu Zabezpečení > Globální zabezpečení.
V části Ověřování rozbalte položku Zabezpečení RMI/IIOP a klepněte na volbu Příchozí ověřování CSIv2.
Povolte 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í:

Pouze 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:"); callback 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 povolena 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í postup:
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 sféry pro informace o přihlášení. Informace o sféře nemusí být k dispozici vždy; nejsou-li k dispozici, mělo by se předpokládat použití aktuální sféry.
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 povolit volbu Šíření příchozích webových atributů zabezpečení na panelu Jednotné přihlášení.

Klepněte na volbu Zabezpečení > Globální zabezpečení.
V části Ověřování rozbalte položku Webové zabezpečení a klepněte položku Jednotné přihlášení (SSO).
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 povolené nebo zakázané 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ího postupu:

Klepněte na volbu Zabezpečení > Globální zabezpečení.
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 aplikační server odešle ověřovací a autorizační údaje na další servery po směru zpracování, je pro aplikační servery eliminová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

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 mechanizmus SWAM (Simple WebSphere Authentication Mechanizm).

Mechanizmus SWAM nepodporuje údaje pověření s možností dalšího předávání. Pokud je jako metoda ověřování použit mechanizmus SWAM, nemůže aplikační server odesílat požadavky ze serveru na server. V tomto případě je nutné použít mechanizmus ověřování LTPA.

Poznámka: Konfigurace přihlašování SWAM je zamítnutá a v některém z následujících vydání bude odebrána.

Poznámka: Mechanizmus SWAM je na aplikačním serveru Verze 8.5 zamítnutý a bude v budoucí verzi odebrán.

SWAM

Tato konfigurace přihlašování umožňuje mapovat jméno (ID) v registru uživatelů LDAP (Lightweight Directory Access Protocol) na jméno (ID) uživatele prostředku SAF (System Authorization Facility).

Poznámka: Mechanizmus SWAM je na aplikačním serveru Verze 8.5 zamítnutý a bude v budoucí verzi odebrán.

wssecurity.IDAssertion

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

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 zrušený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ého prostředí 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 obslužné rutině 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 6.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.

LTPA_WEB

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

DESERIALIZE_ASYNCH_CONTEXT

Zpracování požadavků na přihlášení pro asynchronní objekty bean.

Konfigurace DESERIALIZE_ASYNCH_CONTEXT se používá pouze pro asynchronní objekty bean. Plánovač používá správce výstrah asynchronních objektů bean pro odložené spuštění, které umožňuje serializaci a deserializaci kontextu J2EE. Tato konfigurace přihlášení se využívá pro práci s asynchronními objekty bean, plánovači a časovači EJB.

POZOR:

Konfigurace přihlášení DESERIALIZE_ASYNCH_CONTEXT má omezení. Veškeré operace, které vyžadují ověření tokenů v modulu lognModules konfigurovaném v nastavení přihlášení DESERIALIZE_ASYNC_CONTEXT, mohou mít za následek, že rozhraní API bude opakovaně generovat výjimku TokenExpiredException.

Název souboru: usec_sysjaas.html