Přístup přes portál APM: komu patří relace aplikace?
Pět kontrol pro rozhodnutí o publikování přes BIG-IP Portal Access: rozsah prostředku, relace backendu, dva časovače, význam odhlášení a limity přepisování.
Publikovat intranetovou aplikaci přes BIG-IP APM Portal Access je rozhodnutí o relacích, nikoli o kopírování virtuálního serveru. Portál vpustí uživatele, profil přepisování udrží vybrané požadavky na cestě brány a aplikace si stále drží vlastní relaci. Pět kontrol odděluje návrh, který se chová předvídatelně, od toho, kde se help desk o časových limitech dozvídá uživatel po uživateli. Projděte je v pořadí a zastavte se u první, která neplatí.
Kontrola 1: prostředek je publikovaný, ne jen propojený
Záložka na webtopu dokazuje, že uživatel vidí položku. Nedokazuje, že aplikace je publikovaná. Najděte access profil, rewrite profil a virtuální server, který je spojuje, a potvrďte, že přiřazení prostředku ukazuje na aplikaci, kterou máte na mysli. Pokud některý z těch tří chybí nebo je nekonzistentní, zbytek seznamu nemá smysl.
Případ napůl publikované aplikace vypadá na vstupním bodě zdravě. Virtuální server nese access profil, zatímco rewrite profil je omezen na jiné resource URI, takže položka na webtopu se objeví a první stránka se načte, pak požadavky podcesty opustí cestu brány a dosáhnou backendu přímo. Zrcadlovým obrazem je prostředek přiřazený špatné aplikaci: záložka se otevře a otevře něco, co nikdo neschválil.
Kontrola 2: relace backendu je samostatný stav
Backend může vyžadovat vlastní autentizaci, i když APM uživatele považuje za přihlášeného. Podporovaná integrace SSO tento vztah vytvoří za vás, ale přijetí přihlášení do portálu neznamená, že každá aplikace přijme stejné přihlašovací údaje nebo stejnou session cookie. Pokud pro prostředek není SSO nakonfigurováno, aplikace si vyžádá vlastní přihlášení uvnitř už autentizovaného portálu.
Vypnutí SSO kvůli změně viditelné výzvy je častá a špatná zkratka: mění návrh autentizace, aniž by se dotklo životního cyklu, který výzvu vytvořil. Rozhodněte místo toho, zda se přihlášení do backendu má vůbec objevovat, a pokud ano, udělejte z něj výslovnou součást publikovaného toku.
Kontrola 3: existují dvoje hodiny a nejsou to stejné hodiny
Access profil APM nese inactivity timeout a maximální životnost relace. Aplikace nese vlastní idle timer a vypršení cookie. Prodloužení časovače portálu neprodlouží relaci aplikace a zkrácení relace aplikace neodhlásí uživatele z portálu.
| 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 |
Klasické volání podpory vzniká z neshody: portál je stále platný, relace aplikace ne, a uživatel vidí přihlašovací formulář, který portálu zdánlivě odporuje. To je správné chování, ne závada, a řešením je zvolit, které hodiny mají pro tuto aplikaci vypršet první.
Kontrola 4: odhlášení má definovaný rozsah
Zapište, co má tlačítko odhlášení v aplikaci ukončit: jen tuto aplikaci, celou relaci APM, nebo širší relaci poskytovatele identity. Access profil podporuje seznam logout URI s volitelným zpožděním, a tak zajistíte, že odhlášení z aplikace ukončí relaci portálu, když je to požadavek. Bez toho odhlášení z aplikace nechá portál živý a následný požadavek může uživatele tiše přihlásit zpět.
Zohledněte dopad na ostatní prostředky ve stejném portálu. Pokud odhlášení z jedné aplikace ukončí relaci šesti dalším, uživatelé to nazvou chybou, pokud se na chování předem nedohodli s vlastníkem aplikace. Zavření karty a návrat na webtop nejsou důkazem, že něco skončilo.
Kontrola 5: aplikace přežije přepisování
Portal Access přepisuje vybraný webový obsah a přepisování má hrany. Moderní klientské funkce, procesy na pozadí, toky nahrávání a federované přihlášení se mohou dostat mimo to, co dané vydání zvládá. matice kompatibility podle verzí od F5 je dokument, který je třeba si přečíst před závazkem, protože limity jsou specifické pro vydání.
Testujte toky, na kterých záleží, ne vstupní stránku: přihlaste se, projděte každou požadovanou funkci, nahrajte soubory, pokud aplikace nahrává, nechte zamýšlenou relaci vypršet a projděte všechny cesty odhlášení. Stránka, která se jednou vykreslí, není důkazem, že aplikace funguje.
Když požadovaný tok nelze přepsat, přejděte k dokumentovanému návrhu federace, reverzního proxy nebo síťového přístupu. Prohlížečový portál, po kterém se chce, aby se choval jako obecný tunel, projde demem a selže u auditu.