APM-portaltilgang: kven eig økta til applikasjonen?

Å publisere ein intranettapplikasjon gjennom BIG-IP APM Portal Access er ei avgjerd om økter, ikkje om å kopiere ein virtuell server. Portalen slepp brukaren inn, omskrivingsprofilen held utvalde førespurnader på stien til gatewayen, og applikasjonen har framleis si eiga økt. Fem kontrollar skil eit design som oppfører seg føreseieleg frå eit der helpdesken lærer om tidsavbrot éin brukar om gongen. Gå gjennom dei i rekkjefølgje og stopp ved den første som ikkje stemmer.

Kontroll 1: ressursen er publisert, ikkje berre lenkja

Eit bokmerke i webtop beviser at ein brukar ser ein oppføring. Det beviser ikkje at applikasjonen er publisert. Sjå etter tilgangsprofilen, omskrivingsprofilen og den virtuelle serveren som kombinerer dei, og stadfest deretter at ressurstildelinga peikar på applikasjonen du trur. Manglar ein av dei tre eller er han inkonsistent, er resten av lista utan tyding.

Tilfellet med halvt publisert ser sunt ut ved inngangen. Den virtuelle serveren ber tilgangsprofilen medan omskrivingsprofilen er avgrensa til ein annan resource-URI, så webtop-oppføringa kjem fram og den første sida blir lasta, deretter forlèt førespurnadene på understien stien til gatewayen og når backend direkte. Spegelbiletet er ein ressurs tildelt feil applikasjon: bokmerket opnar, og det opnar noko ingen har godkjent.

Kontroll 2: backend-økta er ein eigen tilstand

Backend kan krevje si eiga autentisering sjølv når APM reknar brukaren som pålogga. Ein støtta SSO-integrasjon etablerer det tilhøvet for deg, men å godta portalloggen gjer ikkje at kvar applikasjon godtar dei same påloggingsdataa eller den same øktkapselen. Viss SSO ikkje er konfigurert for ressursen, vil applikasjonen be om si eiga pålogging inne i ein allereie autentisert portal.

Å slå av SSO for å endre den synlege førespurnaden er ein vanleg og dårleg snarvveg: han endrar autentiseringsdesignet utan å røre livssyklusen som skapte førespurnaden. Avgjer i staden om backend-pålogginga i det heile skal visast, og viss ho skal det, gjer ho til ein eksplisitt del av den publiserte flyten.

Kontroll 3: det er to klokker, og dei er ikkje same klokka

Tilgangsprofilen i APM ber ein inaktivitets-timeout og ei maksimal øktlevetid. Applikasjonen ber sin eigen ledig-tidtakar og utløpet av kapselen. Å auke tidtakaren til portalen forlenger ikkje økta til applikasjonen, og å forkorte økta til applikasjonen loggar ikkje brukaren ut av portalen.

Den klassiske støttehenvendinga kjem av eit par som ikkje passar: portalen er framleis gyldig, økta til applikasjonen er det ikkje, og brukaren ser eit påloggingsskjema som tilsynelatande motsier portalen. Det er korrekt oppførsel, ikkje ein feil, og løysinga er å velje kva klokke som skal utløpe først for denne applikasjonen.

Kontroll 4: utlogging har eit definert omfang

Skriv ned kva logg ut-knappen til applikasjonen skal avslutte: berre den applikasjonen, heile APM-økta eller ei breiare identitetsleverandørøkt. Tilgangsprofilen støttar ei liste over utloggings-URI-ar med valfri forseinking, og det er slik du får utlogginga av applikasjonen til å avslutte portaløkta når det er kravet. Utan det lèt utlogginga av applikasjonen portalen leve, og ein påfølgjande førespurnad kan stille logge brukaren inn igjen.

Rekn med verknaden på andre ressursar i same portal. Viss utlogging frå éin applikasjon avsluttar økta for seks andre, vil brukarane kalle det ein feil med mindre oppførselen er avtalt med eigaren av applikasjonen på førehand. Å lukke ei fane og gå tilbake til webtop er ikkje bevis for at noko er avslutta.

Kontroll 5: applikasjonen overlever omskriving

Portal Access skriv om utvalt webinnhald, og omskriving har kantar. Moderne klientfunksjonar, bakgrunnsjobbar, opplastingsflytar og føderert pålogging kan falle utanfor det ein gjeven versjon handterer. Den versjonsbundne kompatibilitetsmatrisa til F5 er dokumentet du bør lese før du forpliktar deg, fordi grensene er versjonsavhengige.

Test flytane som betyr noko, ikkje landingssida: logg inn, naviger gjennom kvar påkravd funksjon, last opp viss appen lastar opp, la den tiltenkte økta utløpe og følg kvar utloggingsveg. Ei side som blir vist éin gong er ikkje bevis for at applikasjonen verkar.

Når ein påkravd flyt ikkje kan skrivast om, gå over til eit dokumentert føderasjons-, revers-proxy- eller nettverkstilgangsdesign. Ein nettlesarportal som blir beden om å oppføre seg som ein generell tunnel, vil bestå demoen og stryke i revisjonen.