APM-portaltilgang: hvem eier applikasjonens sesjon?

Å publisere en intranettapplikasjon gjennom BIG-IP APM Portal Access er en beslutning om sesjoner, ikke om å kopiere en virtuell server. Portalen slipper brukeren inn, omskrivingsprofilen holder utvalgte forespørsler på gatewayens sti, og applikasjonen har fortsatt sin egen sesjon. Fem sjekker skiller et design som oppfører seg forutsigbart fra et der brukerstøtten lærer om tidsavbrudd én bruker om gangen. Gå gjennom dem i rekkefølge og stopp ved den første som ikke stemmer.

Sjekk 1: ressursen er publisert, ikke bare lenket

Et bokmerke i webtop beviser at en bruker ser en oppføring. Det beviser ikke at applikasjonen er publisert. Se etter tilgangsprofilen, omskrivingsprofilen og den virtuelle serveren som kombinerer dem, og bekreft deretter at ressurstildelingen peker på applikasjonen du tror. Mangler én av de tre eller er den inkonsistent, er resten av listen uten betydning.

Tilfellet med halvt publisert ser sunt ut ved inngangen. Den virtuelle serveren bærer tilgangsprofilen mens omskrivingsprofilen er begrenset til en annen resource-URI, slik at webtop-oppføringen vises og den første siden lastes, deretter forlater forespørslene på understien gatewayens sti og når backend direkte. Speilbildet er en ressurs tildelt feil applikasjon: bokmerket åpnes, og det åpner noe ingen har godkjent.

Sjekk 2: backend-sesjonen er en egen tilstand

Backend kan kreve sin egen autentisering selv når APM anser brukeren som pålogget. En støttet SSO-integrasjon etablerer det forholdet for deg, men å godta portalloggen gjør ikke at hver applikasjon godtar de samme påloggingsdetaljene eller den samme sesjonskapselen. Hvis SSO ikke er konfigurert for ressursen, vil applikasjonen be om sin egen pålogging inne i en allerede autentisert portal.

Å slå av SSO for å endre den synlige forespørselen er en vanlig og dårlig snarvei: den endrer autentiseringsdesignet uten å røre livssyklusen som skapte forespørselen. Bestem i stedet om backend-påloggingen i det hele tatt skal vises, og hvis den skal, gjør den til en eksplisitt del av den publiserte flyten.

Sjekk 3: det er to klokker, og de er ikke samme klokke

Tilgangsprofilen i APM bærer en inaktivitets-timeout og en maksimal sesjonslevetid. Applikasjonen bærer sin egen ledig-tidtaker og utløpet av kapselen. Å øke portaltidtakeren forlenger ikke applikasjonens sesjon, og å forkorte applikasjonens sesjon logger ikke brukeren ut av portalen.

Den klassiske støttehenvendelsen følger av et par som ikke passer: portalen er fortsatt gyldig, applikasjonens sesjon er det ikke, og brukeren ser et påloggingsskjema som tilsynelatende motsier portalen. Det er korrekt oppførsel, ikke en feil, og løsningen er å velge hvilken klokke som skal utløpe først for denne applikasjonen.

Sjekk 4: utlogging har et definert omfang

Skriv ned hva applikasjonens logg ut-knapp skal avslutte: bare den applikasjonen, hele APM-sesjonen eller en bredere identitetsleverandørsesjon. Tilgangsprofilen støtter en liste over utloggings-URI-er med valgfri forsinkelse, og det er slik du får applikasjonens utlogging til å avslutte portalsesjonen når det er kravet. Uten det lar applikasjonens utlogging portalen leve, og en påfølgende forespørsel kan stille logge brukeren inn igjen.

Regn med effekten på andre ressurser i samme portal. Hvis utlogging fra én applikasjon avslutter sesjonen for seks andre, vil brukerne kalle det en feil med mindre oppførselen er avtalt med applikasjonens eier på forhånd. Å lukke en fane og gå tilbake til webtop er ikke bevis for at noe er avsluttet.

Sjekk 5: applikasjonen overlever omskriving

Portal Access skriver om utvalgt webinnhold, og omskriving har kanter. Moderne klientfunksjoner, bakgrunnsjobber, opplastingsflyter og føderert pålogging kan falle utenfor det en gitt versjon håndterer. F5s versjonsbestemte kompatibilitetsmatrise er dokumentet du bør lese før du forplikter deg, fordi grensene avhenger av versjonen.

Test flytene som betyr noe, ikke landingssiden: logg inn, naviger gjennom hver påkrevde funksjon, last opp hvis appen laster opp, la den tiltenkte sesjonen utløpe og følg hver utloggingsvei. En side som vises én gang er ikke bevis for at applikasjonen virker.

Når en påkrevd flyt ikke kan skrives om, gå over til et dokumentert føderasjons-, revers-proxy- eller nettverkstilgangsdesign. En nettleserportal som blir bedt om å oppføre seg som en generell tunnel, vil bestå demoen og stryke i revisjonen.