APM-portálhozzáférés: kié az alkalmazás munkamenete?
Öt ellenőrzés egy BIG-IP Portal Access publikálási döntéshez: az erőforrás hatóköre, a backend munkamenete, két időzítő, a kijelentkezés jelentése és az átírás korlátai.
Egy intranet-alkalmazás közzététele BIG-IP APM Portal Access-szel munkamenetekről szóló döntés, nem virtuális kiszolgáló másolása. A portál beengedi a felhasználót, az átíró profil a kiválasztott kéréseket a gateway útvonalán tartja, és az alkalmazásnak továbbra is saját munkamenete van. Öt ellenőrzés választja el a kiszámíthatóan viselkedő tervet attól, amelyben az ügyfélszolgálat felhasználónként szerez tudomást az időtúllépésekről. Végezze el őket sorrendben, és álljon meg az elsőnél, amely nem igaz.
1. ellenőrzés: az erőforrás közzé van téve, nem csak hivatkozva
A webtopon lévő könyvjelző bizonyítja, hogy a felhasználó lát egy bejegyzést. Azt nem bizonyítja, hogy az alkalmazás közzé van téve. Keresse meg a hozzáférési profilt, az átíró profilt és az ezeket összekapcsoló virtuális kiszolgálót, majd igazolja, hogy az erőforrás-hozzárendelés arra az alkalmazásra mutat, amelyre gondol. Ha a három közül bármelyik hiányzik vagy ellentmondásos, a lista többi része értelmetlen.
A félig közzétett eset a belépési ponton egészségesnek látszik. A virtuális kiszolgáló hordozza a hozzáférési profilt, míg az átíró profil egy másik erőforrás URI-ra van korlátozva, így a webtop-bejegyzés megjelenik és az első oldal betöltődik, majd az alútvonal kérései elhagyják a gateway útvonalát és közvetlenül a backendhez érnek. A tükörkép a rossz alkalmazáshoz rendelt erőforrás: a könyvjelző megnyílik, és olyasmit nyit meg, amit senki nem hagyott jóvá.
2. ellenőrzés: a backend munkamenete külön állapot
A backend saját hitelesítést kérhet, miközben az APM a felhasználót bejelentkezettnek tekinti. A támogatott SSO-integráció ezt a kapcsolatot helyetted létrehozza, de a portál bejelentkezésének elfogadása nem teszi azt, hogy minden alkalmazás ugyanazokat a hitelesítő adatokat vagy ugyanazt a munkamenet-sütit fogadja el. Ha az SSO nincs beállítva az erőforráshoz, az alkalmazás a saját bejelentkezését kéri egy már hitelesített portálon belül.
Az SSO kikapcsolása a látható kérés megváltoztatásához gyakori és rossz rövidítés: megváltoztatja a hitelesítés tervét anélkül, hogy hozzányúlna ahhoz az életciklushoz, amely a kérést létrehozta. Döntse el inkább, hogy a backend bejelentkezésnek egyáltalán meg kell-e jelennie, és ha igen, tegye a közzétett folyamat kifejezett részévé.
3. ellenőrzés: két óra van, és nem ugyanaz az óra
Az APM hozzáférési profilja inaktivitási időtúllépést és maximális munkamenet-élettartamot hordoz. Az alkalmazás saját tétlenségi időzítőt és süti-lejáratot hordoz. A portál időzítőjének növelése nem hosszabbítja meg az alkalmazás munkamenetét, és az alkalmazás munkamenetének rövidítése nem jelentkezteti ki a felhasználót a portálról.
| 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 |
A klasszikus támogatási hívás egy nem illeszkedő párból fakad: a portál még érvényes, az alkalmazás munkamenete nem, és a felhasználó olyan bejelentkezési űrlapot lát, amely látszólag ellentmond a portálnak. Ez helyes viselkedés, nem hiba, és a megoldás az, hogy kiválasszuk, melyik órának kell előbb lejárnia ennél az alkalmazásnál.
4. ellenőrzés: a kijelentkezésnek meghatározott hatóköre van
Írja le, mit kell az alkalmazás kijelentkezés gombjának befejeznie: csak azt az alkalmazást, a teljes APM-munkamenetet vagy egy szélesebb identitásszolgáltatói munkamenetet. A hozzáférési profil támogatja a kijelentkezési URI-k listáját opcionális késleltetéssel, és így éri el, hogy az alkalmazás kijelentkezése befejezze a portál munkamenetét, amikor ez a követelmény. Enélkül az alkalmazás kijelentkezése életben hagyja a portált, és egy következő kérés csendben újra bejelentkeztetheti a felhasználót.
Számoljon az ugyanabban a portálban lévő más erőforrásokra gyakorolt hatással. Ha az egyik alkalmazásból való kijelentkezés hat másik munkamenetét befejezi, a felhasználók ezt hibának nevezik, hacsak a viselkedést előzetesen nem egyeztették az alkalmazás tulajdonosával. Egy lap bezárása és a webtopra való visszatérés nem bizonyítja, hogy valami befejeződött.
5. ellenőrzés: az alkalmazás túléli az átírást
A Portal Access kiválasztott webes tartalmat ír át, és az átírásnak szélei vannak. A modern kliensoldali funkciók, a háttérfolyamatok, a feltöltési folyamatok és a föderált bejelentkezés kívül eshetnek azon, amit egy adott kiadás kezel. Az F5 verzióhoz kötött kompatibilitási mátrixa az a dokumentum, amelyet elköteleződés előtt el kell olvasni, mert a korlátok kiadásfüggők.
Tesztelje a fontos folyamatokat, ne a nyitóoldalt: jelentkezzen be, járja végig az egyes szükséges funkciókat, töltsön fel, ha az alkalmazás feltölt, hagyja lejárni a tervezett munkamenetet, és kövesse az összes kijelentkezési útvonalat. Az egyszer megjelenő oldal nem bizonyítja, hogy az alkalmazás működik.
Amikor egy szükséges folyamat nem írható át, térjen át dokumentált föderációs, fordított proxy vagy hálózati hozzáférési tervre. Az a böngészőportál, amelytől általános alagútként való viselkedést kérnek, átmegy a bemutatón és elbukik az auditáláson.