Acces prin portalul APM: a cui aparține sesiunea aplicației?
Cinci verificări pentru o decizie de publicare cu BIG-IP Portal Access: sfera resursei, sesiunea backend, două temporizatoare, sensul deconectării și limitele rescrierii.
Publicarea unei aplicații de intranet prin BIG-IP APM Portal Access este o decizie despre sesiuni, nu despre copierea unui server virtual. Portalul admite utilizatorul, profilul de rescriere menține cererile selectate pe calea gateway-ului, iar aplicația are în continuare propria sesiune. Cinci verificări separă un design care se comportă previzibil de unul în care serviciul de asistență află despre expirări utilizator cu utilizator. Parcurgeți-le în ordine și opriți-vă la prima care nu este adevărată.
Verificarea 1: resursa este publicată, nu doar legată
Un semn de carte din webtop dovedește că un utilizator vede o intrare. Nu dovedește că aplicația este publicată. Căutați profilul de acces, profilul de rescriere și serverul virtual care le combină, apoi confirmați că alocarea resursei indică aplicația la care vă gândiți. Dacă lipsește sau este incoerent vreunul dintre cele trei, restul listei nu are sens.
Cazul publicat pe jumătate pare sănătos la punctul de intrare. Serverul virtual poartă profilul de acces, în timp ce profilul de rescriere este limitat la un alt URI de resursă, așa că intrarea din webtop apare și prima pagină se încarcă, apoi cererile sub-căii părăsesc calea gateway-ului și ajung la backend direct. Imaginea inversă este o resursă alocată aplicației greșite: semnul de carte se deschide și deschide ceva ce nimeni nu a aprobat.
Verificarea 2: sesiunea backend este o stare separată
Backendul poate cere propria autentificare chiar și când APM consideră utilizatorul autentificat. Integrarea SSO acceptată stabilește acea relație pentru dumneavoastră, dar acceptarea autentificării în portal nu face ca fiecare aplicație să accepte aceleași credențiale sau același cookie de sesiune. Dacă SSO nu este configurat pentru resursă, aplicația va cere propria autentificare în interiorul unui portal deja autentificat.
Dezactivarea SSO pentru a schimba mesajul vizibil este o scurtătură frecventă și proastă: modifică designul autentificării fără să atingă ciclul de viață care a produs mesajul. Decideți în schimb dacă autentificarea backend trebuie să apară deloc, iar dacă trebuie, faceți-o o parte explicită a fluxului publicat.
Verificarea 3: există două ceasuri și nu sunt același ceas
Profilul de acces al APM poartă un timeout de inactivitate și o durată maximă de viață a sesiunii. Aplicația poartă propriul temporizator de inactivitate și expirarea cookie-ului. Prelungirea temporizatorului portalului nu prelungește sesiunea aplicației, iar scurtarea sesiunii aplicației nu deconectează utilizatorul din portal.
| Timer | Owner | What it ends |
|---|---|---|
| Inactivity timeout | APM access profile | the portal session after idle time |
| Maximum lifetime | APM access profile | the portal session regardless of activity |
| Application cookie | Backend application | the application session inside a live portal |
Apelul clasic la asistență provine dintr-o pereche nepotrivită: portalul este încă valid, sesiunea aplicației nu, iar utilizatorul vede un formular de autentificare care pare să contrazică portalul. Acesta este un comportament corect, nu o defecțiune, iar soluția este să alegeți care ceas trebuie să expire primul pentru această aplicație.
Verificarea 4: deconectarea are un domeniu definit
Scrieți ce trebuie să încheie butonul de ieșire al aplicației: doar acea aplicație, întreaga sesiune APM sau o sesiune mai largă a furnizorului de identitate. Profilul de acces acceptă o listă de URI de deconectare cu o întârziere opțională, și astfel faceți ca deconectarea din aplicație să încheie sesiunea portalului atunci când aceasta este cerința. Fără ea, deconectarea din aplicație lasă portalul viu, iar o cerere ulterioară poate autentifica utilizatorul din nou în tăcere.
Luați în calcul efectul asupra altor resurse din același portal. Dacă deconectarea dintr-o aplicație încheie sesiunea altor șase, utilizatorii vor numi asta o eroare dacă comportamentul nu a fost convenit în prealabil cu proprietarul aplicației. Închiderea unui tab și revenirea la webtop nu sunt dovada că ceva s-a încheiat.
Verificarea 5: aplicația supraviețuiește rescrierii
Portal Access rescrie conținut web selectat, iar rescrierea are margini. Funcțiile moderne din partea clientului, procesele din fundal, fluxurile de încărcare și autentificarea federată pot cădea în afara a ceea ce gestionează o anumită versiune. Matricea de compatibilitate pe versiuni a F5 este documentul de citit înainte de angajare, pentru că limitele depind de versiune.
Testați fluxurile care contează, nu pagina de destinație: autentificați-vă, navigați fiecare funcție necesară, încărcați fișiere dacă aplicația o face, lăsați sesiunea dorită să expire și urmați fiecare cale de deconectare. O pagină care se randează o dată nu este dovada că aplicația funcționează.
Când un flux necesar nu poate fi rescris, treceți la un design documentat de federație, proxy invers sau acces de rețea. Un portal de browser căruia i se cere să se comporte ca un tunel general va trece demonstrația și va eșua auditul.