Dostęp przez portal APM: do kogo należy sesja aplikacji?
Pięć kontroli dla decyzji o publikacji z BIG-IP Portal Access: zakres zasobu, sesja backendu, dwa liczniki czasu, znaczenie wylogowania i granice przepisywania.
Publikowanie aplikacji intranetowej przez BIG-IP APM Portal Access to decyzja o sesjach, a nie o kopiowaniu serwera wirtualnego. Portal wpuszcza użytkownika, profil przepisywania utrzymuje wybrane żądania na ścieżce bramy, a aplikacja nadal ma własną sesję. Pięć kontroli oddziela projekt zachowujący się przewidywalnie od takiego, w którym helpdesk poznaje limity czasu użytkownik po użytkowniku. Przejdź je po kolei i zatrzymaj się na pierwszej, która nie jest prawdziwa.
Kontrola 1: zasób jest opublikowany, a nie tylko podlinkowany
Zakładka w webtopie dowodzi, że użytkownik widzi wpis. Nie dowodzi, że aplikacja jest opublikowana. Znajdź profil dostępu, profil przepisywania i serwer wirtualny, który je łączy, a następnie potwierdź, że przypisanie zasobu wskazuje aplikację, którą masz na myśli. Jeśli któregoś z tych trzech brakuje lub jest niespójny, reszta listy nie ma sensu.
Przypadek połowicznego opublikowania wygląda zdrowo w punkcie wejścia. Serwer wirtualny niesie profil dostępu, podczas gdy profil przepisywania jest ograniczony do innego URI zasobu, więc wpis w webtopie się pojawia i pierwsza strona się ładuje, po czym żądania podścieżki opuszczają ścieżkę bramy i docierają do backendu bezpośrednio. Obrazem odwrotnym jest zasób przypisany do niewłaściwej aplikacji: zakładka się otwiera i otwiera coś, czego nikt nie zatwierdził.
Kontrola 2: sesja backendu to odrębny stan
Backend może wymagać własnego uwierzytelnienia nawet wtedy, gdy APM uważa użytkownika za zalogowanego. Wspierana integracja SSO ustanawia tę relację za ciebie, ale przyjęcie logowania do portalu nie sprawia, że każda aplikacja akceptuje te same dane uwierzytelniające czy ten sam plik cookie sesji. Jeśli SSO nie jest skonfigurowane dla zasobu, aplikacja poprosi o własne logowanie wewnątrz już uwierzytelnionego portalu.
Wyłączanie SSO, aby zmienić widoczny monit, to częsty i zły skrót: zmienia projekt uwierzytelniania bez ruszania cyklu życia, który ten monit wytworzył. Zamiast tego zdecyduj, czy logowanie backendu ma się w ogóle pojawiać, a jeśli tak, uczyń je wyraźną częścią opublikowanego przepływu.
Kontrola 3: są dwa zegary i nie są to te same zegary
Profil dostępu APM niesie limit bezczynności i maksymalny czas życia sesji. Aplikacja niesie własny licznik bezczynności i wygaśnięcie pliku cookie. Wydłużenie licznika portalu nie wydłuża sesji aplikacji, a skrócenie sesji aplikacji nie wylogowuje użytkownika z portalu.
| 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 |
Klasyczne zgłoszenie do pomocy technicznej wynika z niedopasowanej pary: portal jest nadal ważny, sesja aplikacji już nie, a użytkownik widzi formularz logowania, który zdaje się przeczyć portalowi. To poprawne zachowanie, a nie awaria, i rozwiązaniem jest wybór, który zegar ma dla tej aplikacji wygasnąć pierwszy.
Kontrola 4: wylogowanie ma określony zakres
Zapisz, co ma zakończyć przycisk wylogowania aplikacji: tylko tę aplikację, całą sesję APM czy szerszą sesję dostawcy tożsamości. Profil dostępu obsługuje listę URI wylogowania z opcjonalnym opóźnieniem i tak sprawiasz, że wylogowanie aplikacji kończy sesję portalu, gdy jest to wymagane. Bez tego wylogowanie aplikacji pozostawia portal żywy, a kolejne żądanie może po cichu zalogować użytkownika ponownie.
Uwzględnij wpływ na inne zasoby w tym samym portalu. Jeśli wylogowanie z jednej aplikacji kończy sesję sześciu innych, użytkownicy nazwą to błędem, chyba że zachowanie uzgodniono wcześniej z właścicielem aplikacji. Zamknięcie karty i powrót do webtopa nie są dowodem, że coś się zakończyło.
Kontrola 5: aplikacja przeżywa przepisywanie
Portal Access przepisuje wybrane treści webowe, a przepisywanie ma krawędzie. Nowoczesne funkcje po stronie klienta, procesy w tle, przepływy wysyłania i logowanie federacyjne mogą wypaść poza to, co obsługuje dana wersja. Matryca zgodności według wersji firmy F5 to dokument, który trzeba przeczytać przed zobowiązaniem się, ponieważ granice zależą od wersji.
Testuj przepływy, które mają znaczenie, a nie stronę startową: zaloguj się, przejdź każdą wymaganą funkcję, wyślij pliki, jeśli aplikacja to robi, pozwól zamierzonej sesji wygasnąć i przejdź każdą ścieżkę wylogowania. Strona, która wyrenderuje się raz, nie jest dowodem, że aplikacja działa.
Gdy wymaganego przepływu nie da się przepisać, przejdź na udokumentowany projekt federacji, odwrotnego proxy lub dostępu sieciowego. Portal przeglądarkowy, od którego wymaga się zachowania jak ogólny tunel, przejdzie demonstrację i obleje audyt.