OPENAM – amService-UrlAccessAgent Autentificare de mai multe ori (Programare, Securitate, Identitate, Openam, Opensso)

Vultur pleșuv a intrebat.

În desfășurarea noastră, avem 3 instanțe OpenAM în spatele unui LoadBalancer, stickiness se bazează pe adrese IP, astfel încât utilizatorii să ajungă întotdeauna pe același server.

Problema mea este că sesiunile noastre maxime concurente sunt atinse pe fiecare server după doar o zi de încărcare.

Când am analizat jurnalul de audit amSSO, am descoperit că agentul meu web (amService-UrlAccessAgent) deschide sesiuni frecvent (peste 20 de sesiuni pe minut) și că aceste sesiuni nu sunt niciodată distruse (toate trăiesc mult timp :)).

Vă rog să mă ajutați să interpretez acest comportament?amService-UrlAccessAgent nu trebuia să înregistreze o singură dată?

În avans Vă mulțumesc.

2 răspunsuri
Peter Major

Există câteva lucruri interesante în descrierea dumneavoastră:

  • Dacă folosiți un agent web, atunci de ce îl folosiți cu amService-UrlAccessAgent? Ar trebui să creați un profil de agent Web pentru agentul dvs. și să utilizați acel cont în schimb.
  • Nu este clar ce server web folosiți, așa că presupun că este Apache. În acest caz, asigurați-vă că NU utilizați modul prefork, mpm recomandat este worker, deoarece va necesita mult mai puține autentificări ale agentului în general. Cu toate acestea, din câte știu eu, agentul se deconectează întotdeauna singur odată ce procesul copil moare.
  • De asemenea, este posibil să doriți să încercați să utilizați o versiune mai nouă a agentului web sau chiar o versiune nightly dacă această problemă continuă să se repete.

Comentarii

  • Mulțumesc mult pentru răspuns, într-adevăr, folosim apache, și este efectiv în modul prefork, deoarece găzduiește aplicații PHP și facem acest lucru prin mod_php (care este incompatibil cu modul Worker). în ceea ce privește prima întrebare: folosim profilul implicit pentru că ne satisface nevoile, nu văd modificări specifice care ar putea fi adăugate printr-un profil personalizat (ca începător openAM care sunt). voi încerca ultima dvs. presupunere de îndată ce voi construi un mediu de testare… dar încă mai păstrez speranța că aș putea invalida acele sesiuni prin configurare 🙂 –  > Por Vultur pleșuv.
  • Ar trebui să creați un profil de agent în Control acces – domeniu – agenți – fila Web și să utilizați numele/parola profilului la instalarea agentului web. În momentul de față se pare că utilizați o versiune foarte veche a agentului (nici măcar nu sunt sigur cum funcționează fără un profil de agent web adecvat – deoarece UrlAccessAgent nu este chiar unul -, agentului ar trebui să-i lipsească o mulțime de opțiuni de configurare din profilul agentului…). –  > Por Peter Major.
Bald Eagle

Cred că am găsit soluția. când am început să sap puțin în codul OpenAm și în codul agentului, am descoperit următorul lucru

           if ((isApplicationModule(authMethName) && 
                (ad.isSuperUser(userDN) || ad.**isSpecialUser**(userDN)))
                || isAgent(amIdentityUser))
           if (isAgent(amIdentityUser) && agentSessionIdleTime > 0) {
                ....
                session.setMaxSessionTime(Long.MAX_VALUE/60);
                session.setMaxIdleTime(agentSessionIdleTime);
                session.setMaxCachingTime(agentSessionIdleTime);
            } else {
                session.setExpire(false);
            }

și când Te uiți puțin înainte, ai aflat că valoarea lui agentSessionIdleTime este 0 în cazul în care proprietatea com.iplanet.am.session.agentsessionidletim.agentession. nu este configurată.

Pentru interpretarea semnificației acestei proprietăți, urmați acest link: Policy agent sessions to time out

Mulțumesc Peter pentru ajutor. vă voi spune în curând dacă funcționează bine pe sistemul nostru de producție.

Comentarii

  • dar totuși, nu-mi dau seama de ce nu s-a deconectat automat –  > Por Bald Eagle.
  • Soluția pe care am propus-o este doar o soluție de lucru care funcționează în cazul nostru, dar, într-adevăr, problema încă persistă. Când vă uitați la openam, la prima vedere puteți vedea că acesta agață o metodă de curățare la sfârșitul procesului care, în mod necondiționat, deconectează agentul. Și înregistrează erori dacă procesul respectiv generează erori, în timp ce jurnalele noastre sunt curate, fără erori sau avertismente în jurnalul agenților. După un mic test pe un mediu de testare în care am pus aceeași configurație (aceeași versiune apache mod, același fișier conf agent), nu am reprodus eroarea, agentul se deconectează corect.  > Por Bald Eagle.