APM-portaladgang: hvem ejer applikationens session?

At publicere en intranetapp gennem BIG-IP APM Portal Access er en beslutning om sessioner, ikke om at kopiere en virtuel server. Portalen lukker brugeren ind, rewrite-profilen holder udvalgte anmodninger på gatewayens sti, og applikationen har stadig sin egen session. Fem kontroller adskiller et design, der opfører sig forudsigeligt, fra et hvor helpdesken lærer om timeouts én bruger ad gangen. Gå dem igennem i rækkefølge, og stop ved den første, der ikke holder.

Kontrol 1: ressourcen er publiceret, ikke blot linket

Et bogmærke på webtop beviser, at brugeren ser en post. Det beviser ikke, at applikationen er publiceret. Find access-profilen, rewrite-profilen og den virtuelle server, der kombinerer dem, og bekræft derefter, at ressourcetildelingen peger på den applikation, du tror. Hvis en af de tre mangler eller er inkonsistent, er resten af listen uden betydning.

Tilfældet med halvt publiceret ser sundt ud ved indgangen. Den virtuelle server bærer access-profilen, mens rewrite-profilen er afgrænset til en anden resource-URI, så webtop-posten vises, og den første side indlæses, hvorefter understiens anmodninger forlader gatewayens sti og når backend direkte. Det omvendte billede er en ressource tildelt den forkerte applikation: bogmærket åbner, og det åbner noget, ingen har godkendt.

Kontrol 2: backend-sessionen er en separat tilstand

Backenden kan kræve sin egen godkendelse, selv når APM anser brugeren for logget ind. En understøttet SSO-integration etablerer det forhold for dig, men at acceptere portallogindet får ikke hver applikation til at acceptere de samme legitimationsoplysninger eller den samme sessionscookie. Hvis SSO ikke er konfigureret for ressourcen, vil applikationen bede om sit eget login inde i en allerede godkendt portal.

At slå SSO fra for at ændre den synlige prompt er en almindelig og dårlig genvej: den ændrer godkendelsesdesignet uden at røre den livscyklus, der skabte prompten. Beslut i stedet, om backend-logindet overhovedet skal vises, og hvis det skal, så gør det til en eksplicit del af det publicerede flow.

Kontrol 3: der er to ure, og de er ikke det samme ur

APM's access-profil bærer en inaktivitetstimeout og en maksimal sessionlevetid. Applikationen bærer sin egen idle-timer og cookie-udløb. At forlænge portalens timer forlænger ikke applikationens session, og at forkorte applikationens session logger ikke brugeren ud af portalen.

Det klassiske supportopkald følger af et par, der ikke passer: portalen er stadig gyldig, applikationens session er det ikke, og brugeren ser en loginformular, der tilsyneladende modsiger portalen. Det er korrekt adfærd, ikke en fejl, og løsningen er at vælge, hvilket ur der skal udløbe først for denne applikation.

Kontrol 4: logud har et defineret omfang

Skriv ned, hvad applikationens logud-knap skal afslutte: kun den applikation, hele APM-sessionen eller en bredere identitetsudbyder-session. Access-profilen understøtter en liste af logud-URI'er med en valgfri forsinkelse, og det er sådan, du får applikationens logud til at afslutte portalsessionen, når det er kravet. Uden det lader applikationens logud portalen leve, og en efterfølgende anmodning kan lydløst logge brugeren ind igen.

Medregn effekten på andre ressourcer i samme portal. Hvis logud fra én applikation afslutter sessionen for seks andre, vil brugerne kalde det en fejl, medmindre adfærden er aftalt med applikationens ejer først. At lukke en fane og vende tilbage til webtop er ikke bevis på, at noget er afsluttet.

Kontrol 5: applikationen overlever omskrivning

Portal Access omskriver udvalgt webindhold, og omskrivning har kanter. Moderne klientfunktioner, baggrundsarbejdere, upload-flow og fødereret login kan falde uden for, hvad en given version håndterer. F5's versionsbestemte kompatibilitetsmatrix er dokumentet, du skal læse, før du forpligter dig, fordi grænserne er versionsspecifikke.

Test de flows, der betyder noget, frem for landingssiden: log ind, naviger gennem hver påkrævet funktion, upload hvis appen uploader, lad den tilsigtede session udløbe, og følg hver logud-sti. En side, der renderes én gang, er ikke bevis på, at applikationen virker.

Når et påkrævet flow ikke kan omskrives, skift til et dokumenteret federations-, reverse-proxy- eller netværksadgangsdesign. En browserportal, der bliver bedt om at opføre sig som en generel tunnel, vil bestå demoen og dumpe revisionen.