Setările intrării de configurare a logării de sistem pentru Java Authentication and Authorization Service

Utilizaţi această pagină pentru a specifica o listă de configuraţii de logare de sistem Java Authentication and Authorization Service (JAAS).

Pentru a vizualiza această pagină de consolă administrativă, finalizaţi următorii paşi:

Faceţi clic pe Securitate > Securitate globală.
Sub Autentificare, faceţi clic pe Autentificare şi serviciu de autorizare Java > Logări de sistem.

Citiţi documentaţia Java Authentication and Authorization Service înainte de a începe să definiţi module de logare suplimentare pentru autentificarea la runtime-ul de securitate al serverului de aplicaţii. Nu înlăturaţi următoarele module de logare sistem:

RMI_INBOUND
WEB_INBOUND
DEFAULT
RMI_OUTBOUND
SWAM
SWAM
wssecurity.IDAssertion
wssecurity.signature
wssecurity.PKCS7
wssecurity.PkiPath
wssecurity.UsernameToken
wssecurity.X509BST
LTPA
LTPA_WEB
Notă: LTPA_WEB şi WEB_INBOUND realizează funcţii similare. Este recomandabil să folosiţi WEB_INBOUND deoarece este mai nou dintre modulele de logare.
DESERIALIZE_ASYNCH_CONTEXT

ICSF

Procesează cereri de logare când Integrated Cryptographic Services Facility (ICSF) este utilizat ca mecanism de autentificare.

RMI_INBOUND, WEB_INBOUND, DEFAULT

Procesează cereri de logare de intrare pentru RMI (Remote Method Invocation), aplicaţii web şi majoritatea celorlalte protocoluri de logare.

RMI_INBOUND: Această configuraţie de logare tratează logările pentru cererile RMI de intrare. În mod normal, aceste logări sunt cereri pentru acces autentificat la fişiere Enterprise JavaBeans (EJB). Când utilizaţi conectorul RMI, aceste logări ar putea fi cereri pentru Java Management Extensions (JMX).
WEB_INBOUND: Această configuraţie de logare tratează logările pentru cereri de aplicaţii web, care includ servlet-uri şi fişiere JSP (JavaServer Pages). Această configuraţie de logare poate interacţiona cu ieşirea care este generată de la un interceptor de asociere de încredere (TAI), dacă este configurat. Subiectul care este transmis la configuraţia de logare WEB_INBOUND ar putea conţine obiecte care sunt generate de TAI.
DEFAULT: Această configuraţie de logare tratează logările pentru cereri de intrare care sunt făcute de majoritatea celorlaltor protocoluri şi autentificări interne.

Aceste trei configuraţii de logare vor transmite următoarele informaţii de retroapel, care sunt tratate de modulele de logare în aceste configuraţii. Aceste retroapeluri nu sunt transmise în acelaşi timp. Totuşi, combinaţia acestor retroapeluri determină cum autentifică serverul de aplicaţii utilizatorul.

Retroapel

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

Responsabilitate

Colectează numele de utilizator care este furnizat în timpul unei logări. Aceste informaţii pot fi numele de utilizator pentru următoarele tipuri de logări:

Logare cu nume utilizator şi parolă, cunoscută şi ca autentificare de bază.
Doar nume de utilizator pentru aserţiunea identităţii fără parolă.

Retroapel: callbacks[1] = new javax.security.auth.callback.
PasswordCallback("Password:", false);
Responsabilitate: Colectează parola care este furnizată în timpul unei logări. Este permisă parola null şi este utilizată pentru a suporta aserţiunea identităţii.

Retroapel: callbacks[2] = new com.ibm.websphere.security.auth.callback.
WSCredTokenCallbackImpl("Credential Token:");
Responsabilitate: Colectează tokenul Lightweight Third Party Authentication (LTPA) sau alt tip de token în timpul unei logări. În mod normal, aceste informaţii sunt prezente când nu există un nume de utilizator şi o parolă.

Retroapel

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

Responsabilitate

Colectează lista ArrayList de obiecte TokenHolder care sunt returnate de la apel la WSOpaqueTokenHelper. Retroapelul utilizează metoda createTokenHolderListFromOpaqueToken cu jetonul de autorizare Common Secure Interoperability version 2 (CSIv2) ca intrare.

Restricţie: Acest callback este prezent numai când opţiunea Propagare atribut securitate este activată şi această logare este o logare de propagare. Într-o logare de propagarem sunt propagate suficiente atribute de securitate cu cererea pentru a nu fi nevoie să se acceseze registrul de utilizatori pentru atribute suplimentare. Trebuie să activaţi propagarea atributelor de securitate pentru autentificarea de intrare şi pentru cea de ieşire.

Puteţi activa opţiunea Propagare atribut securitate pentru autentificare de ieşire CSIv2 finalizând următorii paşi:

Faceţi clic pe Securitate > Securitate globală.
Sub Autentificare, expandaţi securitatea RMI/IIOP şi apăsaţi pe Autentificare de ieşire CSIv2.
Activaţi opţiunea Propagare atribut securitate.

Puteţi activa opţiunea Propagare atribut securitate pentru autentificare de intrare CSIv2 finalizând următorii paşi:

Faceţi clic pe Securitate > Securitate globală.
Sub Autentificare, expandaţi securitatea RMI/IIOP şi apăsaţi pe Autentificare de intrare CSIv2.
Activaţi opţiunea Propagare atribut securitate.

În configuraţiile de logare sistem, serverul de aplicaţii autentifică utilizatorul pe baza informaţiilor care sunt colectate de către callback-uri. Totuşi, un modul de logare personalizat nu are nevoie să acţioneze asupra vreunuia dintre aceste callback-uri. Următoarea listă explică combinaţiile tipice ale acestor callback-uri:

callbacks[0] = new javax.security.auth.callback.NameCallback("Username:"); doar callback
Acest callback se realizează pentru aserţiunea identităţii CSIv2, logarea certificatelor CSIv2 X509 şi web, logările interceptorului asocierii de încredere în stil vechi, şamd. În logările certificatelor CSIv2 X509 şi web, serverul de aplicaţii mapează certificatul la un nume de utilizator. Acest callback este utilizat de orice tip de logare care stabileşte încrederea cu numele de utilizator doar.
Atât callbacks[0] = new javax.security.auth.callback.NameCallback("Username:"); callback cât şi callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password:", false); callbacks.
Această combinaţie de callback-uri este obişnuită pentru logări de autentificare de bază. Majoritatea celorlalte autentificări se fac utilizând aceste două callback-uri.
callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token:"); only
Acest callback este utilizat pentru a valida un jeton Lightweight Third Party Authentication (LTPA). Această validare de obicei apare în timpul unei semnări unice (SSO) sau logare în aval. Oricând o cerere originează din serverul de aplicaţii, în loc să fie de la un client pur, jetonul LTPA se transmite la serverul ţintă. Pentru semnarea unică (SSO), jetonul LTPA este primit într-un cookie şi jetonul este utilizat pentru logare. Dacă un modul de logare personalizat are nevoie de numele de utilizator de la un jeton LTPA, modulul poate utiliza următoarea metodă pentru a extrage ID-ul unic de la jeton:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
validateLTPAToken(byte[])
După extragerea ID-ului unic, utilizaţi următoarea metodă pentru a obţine numele de utilizator:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
getUserFromUniqueID(uniqueID)

Important: Ori de câte ori un modul de logare personalizat este conectat înaintea modulelor de logare ale serverului de aplicaţii şi schimbă identitatea utilizând un serviciu de mapare a acreditărilor, este important ca acest modul de logare să valideze jetonul LTPA, dacă este prezent. Apelarea următoarei metode este suficientă pentru a valida încrederea în jetonul LTPA:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
validateLTPAToken(byte[])
Serverul receptor trebuie să aibă aceleaşi chei LTPA ca serverul emitent pentru ca această validare să aibă succes. Este posibilă o expunere a securităţii dacă nu validaţi acest jeton LTPA, când este prezent.
A combination of any of the previously mentioned callbacks plus the callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List:"); callback.
Acest callback indică faptul că au ajuns nişte atribute propagate la server. Atributele propagate încă necesită una dintre următoarele metode de autentificare:
- 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:");
Dacă atributele sunt adăugate la subiect de la un client pur, atunci callback-urile NameCallback şi PasswordCallback autentifică informaţiile şi obiectele care sunt serializate în deţinătorul de jetoane sunt adăugate la Subiectul autentificat.
Dacă şi aserţiunea de identitate CSIv2 şi propagarea sunt activate, serverul de aplicaţii utilizează callback-ul NameCallback şi deţinătorul de jetoane, care conţine toate atributele propagate, pentru a deserializa majoritatea obiectelor. Serverul de aplicaţii utilizează callback-ul NameCallback pentru că încrederea este stabilită cu serverele pe care le indicaţi în lista de servere de încredere CSIv2. Pentru a specifica serverele de încredere, finalizaţi următorii paşi:
1. Faceţi clic pe Securitate > Securitate globală.
2. Sub Autentificare, apăsaţi pe Autentificare de intrare CSIv2.
Un modul de logare personalizat trebuie să trateze serializarea personalizată. Pentru informaţii suplimentare, vedeţi "Propagare atribut securitate " în centrul de informare.

În plus faţă de callback-urile care au fost definite anterior, configuraţia de logare WEB_INBOUND poate conţine numai următoarele callback-uri suplimentare:

Retroapel: callbacks[4] = new com.ibm.websphere.security.auth.callback.
WSServletRequestCallback("HttpServletRequest:");
Responsabilitate: Colectează obiectul de cerere servlet HTTP, dacă este prezentat. Acest callback permite modulelor de logare să extragă informaţii de la cererea HTTP de utilizat în timpul unei logări.

Retroapel: callbacks[5] = new com.ibm.websphere.security.auth.callback.
WSServletResponseCallback("HttpServletResponse:");
Responsabilitate: Colectează obiectul de răspuns servlet HTTP, dacă este prezentat. Acest callback permite modulelor de logare să adauge informaţii în răspunsul HTTP ca urmare a logării. De exemplu, modulele de logare ar putea adăuga cookie-ul SingleSignonCookie la răspuns.

Retroapel: callbacks[6] = new com.ibm.websphere.security.auth.callback.
WSAppContextCallback("ApplicationContextCallback:");
Responsabilitate: Colectează contextul aplicaţiei web utilizat în timpul logării. Acest callback constă într-o tabelă hash, care dacă este prezentă, conţine numele aplicaţiei şi adresa web redirecţionată.
Retroapel: callbacks[7] = new WSRealmNameCallbackImpl("Realm Name:", <default_realm>);
Responsabilitate: Colectează numele regiunii pentru informaţiile de logare. Informaţiile regiunii s-ar putea să nu fie furnizate tot timpul şi ar trebui să se presupună că este regiunea curentă dacă nu sunt furnizate.
Retroapel: callbacks[8] = new WSX509CertificateChainCallback("X509Certificate[]:");
Responsabilitate: Dacă sursa de logare este un X509Certificate de la autentificarea de client SSL, acest callback conţin certificatul care a fost validat de SSL. ltpaLoginModule apelează aceleaşi funcţii de mapare ca în ediţiile anterioare. Odată ce este transmis la logare, furnizează un modul de logare personalizat cu oportunitatea de a mapa certificatul într-un mod personalizat. Realizează apoi o logare de tabelă hash (consultaţi legătura înrudită, Logare personalizată pentru maparea de intrare, pentru un exemplu al unei logări de tabelă hash.).

Dacă doriţi să utilizaţi propagarea atributului de securitate cu configuraţia de logare WEB_INBOUND, puteţi activa opţiunea Propagare atribut de securitate de intrare web din panoul SSO (semnare unică).

Faceţi clic pe Securitate > Securitate globală.
Din Autentificare, expandaţi Securitate web şi apăsaţi pe Semnare unică (SSO).
Selectaţi opţiunea Propagare atribut de securitate de intrare web.

Următoarele module de logare sunt predefinite pentru configuraţiile de logare sistem RMI_INBOUND, WEB_INBOUND şi DEFAULT. Puteţi adăuga module de logare personalizate înainte, între sau după oricare dintre aceste module de logare, dar nu puteţi înlătura aceste module de logare predefinite:

com.ibm.ws.security.server.lm.ltpaLoginModule
Realizează logarea primară când propagarea atributelor este fie activată, fie dezactivată. O logare primară utilizează informaţiile de autentificare normale, cum ar fi un ID de utilizator şi parola, un jeton LTPA sau un interceptor de asociere de încredere (TAI) şi un nume distinctiv (DN) de certificat. Dacă vreunul din următoarele scenarii este adevărat, acest modul de logare nu este utilizat şi modulul com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule realizează logarea primară:
- Obiectul java.util.Hashtable cu atributele de utilizator necesare este conţinut în Subiect.
- Obiectul java.util.Hashtable cu atributele de utilizator necesare este prezent în sharedState HashMap a LoginContext.
- Retroapelul WSTokenHolderCallback este prezent fără o parolă specificată. Dacă un nume de utilizator şi o parolă sunt prezente cu un callback WSTokenHolderCallback, care indică informaţi propagate, cererea originează cel mai probabil fie de la un client pur sau un server dintr-o altă regiune care a mapat identitatea existentă la un ID de utilizator şi parolă.
com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule
Acest modul de logare realizează logarea primară utilizând informaţiile de autentificare normală dacă este adevărată vreuna din următoarele condiţii:
- Un obiect java.util.Hashtable cu atributele de utilizator necesare este conţinut în Subiect.
- Un obiect java.util.Hashtable cu atributele de utilizator necesare este prezent în sharedState HashMap a contextului LoginContext.
- Retroapelul WSTokenHolderCallback este prezent fără un callback PasswordCallback.
Când este prezent obiectul java.util.Hashtable, modulul de logare mapează atributele obiectului într-un subiect valid. Când este prezent callback-ul WSTokenHolderCallback, modulul de logare deserializează obiectele jeton de octeţi şi regenerează conţinutul Subiectului serializat. Tabela hash java.util.Hashtable are întâietate faţă de toate celelalte forme de logare. Aveţi grijă să evitaţi duplicarea sau înlocuirea a ce se poate să fi propagat anterior serverul de aplicaţii.

Specificând ca o tabelă hash java.util.Hashtable să aibă întâietate faţă de alte informaţii de autentificare, modulul de logare personalizat trebuie să fi verificat deja jetonul LTPA, dacă este prezent, pentru a stabili încrederea suficientă. Modulul de logare personalizat poate utiliza metoda com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validationLTPAToken(byte[]) pentru a valida jetonul LTPA prezent în callback-ul WSCredTokenCallback. Eşuarea de a valida jetonul LTPA prezintă un risc de securitate.

Pentru informaţii suplimentare despre adăugarea unui hashtable care conţine atribute bine cunoscute şi bine formate utilizate de serverul de aplicaţii ca informaţii de logare suficiente, vedeţi "Configurarea mapării de identitate intrare" în centrul de informare.

RMI_OUTBOUND

Procesează cereri Remote Method Invocation (RMI) care sunt trimise la ieşire la alt server când una din proprietăţile com.ibm.CSI.rmiOutboundLoginEnabled sau com.ibm.CSIOutboundPropagationEnabled este adevărată.

Aceste proprietăţi sunt setate în panoul de autentificare CSIv2. Pentru a accesa panoul, finalizaţi următorii paşi:

Faceţi clic pe Securitate > Securitate globală.
Sub Autentificare, expandaţi securitatea RMI/IIOP şi apăsaţi pe Autentificare de ieşire CSIv2.

Pentru a seta proprietatea com.ibm.CSI.rmiOutboundLoginEnabled, selectaţi Mapare de ieşire personalizată. Pentru a seta proprietatea com.ibm.CSIOutboundPropagationEnabled, selectaţi opţiunea Propagare atribut securitate.

Această configuraţie de logare determină capabilităţile de securitate ale serverului ţintă şi ale domeniului său de securitate. Când serverul de aplicaţii trimite atât informaţiile de autentificare, cât şi de autorizare în aval, serverul de aplicaţii înlătură nevoia de a accesa din nou registrul de utilizatori şi de a căuta atributele de securitate ale utilizatorului în scopuri de autorizare. În plus, toate obiectele personalizate care sunt adăugate la serverul emitent sunt prezente în Subiect la serverul din aval.

Următorul callback este disponibil în configuraţia de logare RMI_OUTBOUND. Puteţi utiliza obiectul com.ibm.wsspi.security.csiv2.CSIv2PerformPolicy care este returnat de acest callback pentru a interoga politica de securitate pentru această cerere de ieşire anume. Această interogare poate ajuta la determinarea dacă regiunea ţintă este diferită de regiunea curentă şi dacă serverul de aplicaţii trebuie să mapeze regiunea. Pentru informaţii suplimentare, vedeţi "Configurarea mapării de ieşire la o regiune ţintă diferită" în centrul de informare.

Retroapel

callbacks[0] = new WSProtocolPolicyCallback("Protocol Policy Callback: ");

Responsabilitate

Furnizează informaţii de politică specifice protocolului pentru modulele de logare din această invocare de ieşire. Aceste informaţii sunt utilizate pentru a determina nivelul securităţii, inclusiv regiunea ţintă, cerinţele de securitate ţintă şi cerinţele de securitate omogene.

Următoarea metodă obţine politica CSIv2PerformPolicy din acest modul de logare anume:

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

Un alt protocol decât RMI ar putea avea un tip diferit de obiect de politică.

Următorul modul de logare este predeifinit în configuraţia de logare RMI_OUTBOUND. Puteţi adăuga module de logare personalizate înainte, între sau după oricare dintre aceste module de logare, dar nu puteţi înlătura aceste module de logare predefinite.

com.ibm.ws.security.lm.wsMapCSIv2OutboundLoginModule

Extrage jetoanele şi obiectele următoare înainte de a crea un octet opac care este trimis la alt server utilizând nivelul de jeton de autorizare CSIv2 (Common Secure Interoperability Versiunea 2):

Implementări com.ibm.wsspi.security.token.Token înaintabile de la Subiect
Obiecte personalizate serializabile de la Subiect
Jetoane de propagare de la firul de execuţie

Puteţi utiliza un modul de logare personalizat înaintea acestui modul de logare pentru a realiza maparea acreditărilor. Totuşi, se recomandă ca modulul de logare să modifice conţinutul Subiectului care este transmis în faza de logare. Dacă se urmează această recomandare, modulele de logare sunt procesate după ce acest modul de logare acţionează pe noul conţinut de subiect.

Pentru informaţii suplimentare, vedeţi "Configurarea mapării ieşire la o regiune ţintă diferită" în centrul de informare.

SWAM

Procesează cererile de logare într-un mediu de server singular când se utilizează Simple WebSphere Authentication Mechanism (SWAM) ca metodă de autentificare.

SWAM nu suportă acreditări înaintabile. Când SWAM este metoda de autentificare, serverul de aplicaţii nu poate trimite cereri de la server la server. În acest caz, trebuie să utilizaţi LTPA.

Notă: Configuraţia de logare SWAM este depreciată şi va fi înlăturată într-o ediţie viitoare.

Notă: SWAM este depreciat în serverul de aplicaţii Versiunea 8.5 şi va fi înlăturat într-o ediţie viitoare.

SWAM

Această configuraţie de logare vă permite să mapaţi un ID într-un registru de utilizatori LDAP (Lightweight Directory Access Protocol) la un ID de utilizator SAF (System Authorization Facility)

Notă: SWAM este depreciat în serverul de aplicaţii Versiunea 8.5 şi va fi înlăturat într-o ediţie viitoare.

wssecurity.IDAssertion

Procesează cereri de configurare a logării pentru Web Services Security utilizând aserţiunea identităţii.

Această configuraţie de logare este pentru aplicaţii Web Services Security Draft 13 JAX-RPC (Versiunea 5.x). Pentru informaţii suplimentare, vedeţi "Metodă de autentificare aserţiune de identitate" în centrul de informare.

wssecurity.IDAssertionUsernameToken

Procesează cereri de configurare a logării pentru Web Services Security utilizând aserţiunea identităţii.

Această configuraţie de logare este pentru aplicaţii Web Services Security V1.0 JAX-RPC.

Proprietatea personalizată com.ibm.wsspi.wssecurity.auth.module.IDAssertionLoginModule.disableUserRegistryCheck poate fi configurată pentru modulul de logare JAAS IDAssertionUsernameToken. Această proprietate este o opţiune pentru modulul de logare JAAS al aserţiunii identităţii securităţii serviciilor web, wssecurity.IDAssertionUsernameToken. Proprietatea indică faptul că modulul de logare nu ar trebui să realizeze o verificare a registrului de utilizatori când se procesează un jeton de identitate de intrare.

wssecurity.PKCS7

Verifică un certificat X.509 cu o listă de revocare de certificate într-un obiect PKCS7 (Public Key Cryptography Standards #7).

Această configuraţie de logare este pentru sistemele Versiunea 6.0.x.

wssecurity.PkiPath

Verifică un certificat X.509 cu o cale PKI (infrastructură cheie publică).

Această configuraţie de logare este pentru sistemele Versiunea 6.0.x.

wssecurity.signature

Procesează cereri de configurare a logării pentru Web Services Security utilizând validarea semnăturii digitale.

Această configuraţie de logare este pentru sistemele Versiunea 5.x.

wssecurity.UsernameToken

Verifică autentificarea de bază (numele utilizator şi parola).

Când utilizaţi runtime-ul JAX-RPC, următoarele proprietăţi personalizate pot fi configurate pentru modulul de logare JAAS UsernameToken:

Proprietatea personalizată com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule.disableUserRegistryCheck poate fi configurată pentru modulul de logare JAAS UsernameToken. Această proprietate este o opţiune pentru modulul de logare JAAS UsernamToken al securităţii serviciilor web, com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule. Proprietatea indică faptul că modulul de logare nu ar trebui să realizeze o verificare a registrului de utilizatori când se procesează un jeton de nume de utilizator de intrare.

wssecurity.X509BST

Verificăun jeton de securitate binar (BST) X.509 verificând validitatea certificatului şi a căii certificatului.

Această configuraţie de logare este pentru sistemele Versiunea 6.0.x.

LTPA_WEB

Procesează cererile de logare la componente din containerul web, cum ar fi servlet-uri şi fişiere JSP (JavaServer pages).

Modulul de logare com.ibm.ws.security.web.AuthenLoginModule este predefinit în configuraţia de logare LTPA. Puteţi adăuga module de logare personalizate înainte sau după acest modul în configuraţia de logare LTPA_WEB.

Configuraţia de logare LTPA_WEB poate procesa obiectul HttpServletRequest, obiectul HttpServletResponse şi numele aplicaţiei web care sunt transmise utilizând o rutină de tratare a callback-urilor. Pentru informaţii suplimentare, vedeţi "Exemplu: Personalizarea unuei autentificări şi configuraţii de logare Java Authentication and Authorization Service server-side" în centrul de informare.

LTPA

Procesează cereri de logare care nu sunt tratate de configuraţia de logare LTPA_WEB.

Această configuraţie de logare este folosită de WebSphere Application Server Versiunea 6.1 şi versiunile anterioare.

Modulul de logare com.ibm.ws.security.server.lm.ltpaLoginModule este predefinit în configuraţia de logare LTPA. Puteţi adăuga module de logare personalizate înainte sau după acest modul în configuraţia de logare LTPA. Pentru informaţii suplimentare, vedeţi "Exemplu: Personalizarea unuei autentificări şi configuraţii de logare Java Authentication and Authorization Service authentication server-side" în centrul de informare.

LTPA_WEB

Procesează cererile de logare la componente din containerul web, cum ar fi servlet-uri şi fişiere JSP (JavaServer pages).

DESERIALIZE_ASYNCH_CONTEXT

Procesează cereri de logare pentru bean-uri asincron.

Configuraţia DESERIALIZE_ASYNCH_CONTEXT este utilizată doar pentru bean-uri asincron. Planificatorul utilizează managerul de alarmă de bean-uri asincrone pentru "Deferred Start", care permite serializarea şi deserializarea contextului J2EE. Această configuraţie de logare este utilizată când utilizaţi bean-uri asincrone, Planificator şi Cronometre EJB.

CAUTION:

Configuraţia de logare DESERIALIZE_ASYNCH_CONTEXT are o limitare. Orice operaţie care necesită validare jeton în lognModules configurat în configuraţia de logare DESERIALIZE_ASYNC_CONTEXT poate avea ca rezulta aruncarea de către API a TokenExpiredException în mod repetat.

Numele fişierului: usec_sysjaas.html