APM-portaaltoegang: wie besit die sessie van die toepassing?
Vyf kontroles vir die publikasiebesluit van die app deur BIG-IP Portal Access: die omvang van die hulpbron, die sessie van die backend, twee timers, die betekenis van afmelding en die grense van herskrywing.
Om die app van die intranet deur BIG-IP APM-portaaltoegang te publiseer, is die besluit een oor sessies, nie oor die duplisering van die virtuele bediener nie. Die portaal laat die gebruiker in, die herskryfprofiel hou geselekteerde versoeke op die pad van die poort, en die toepassing besit steeds sy eie sessie. Vyf kontroles skei die ontwerp wat voorspelbaar werk van die een waar die dienslessenaar van tydoverskrydings een gebruiker op 'n slag uitvind. Werk hulle in volgorde deur en stop by die eerste een wat nie waar is nie.
Kontrole 1: die hulpbron word gepubliseer, nie net geskakel nie
Die webtop-merk wys dat die gebruiker die inskrywing sien. Dit wys nie dat die toepassing gepubliseer is nie. Soek die toegangsprofiel, die herskryfprofiel en die virtuele bediener wat hulle kombineer, en bevestig dan dat die hulpbrontoewysing na die toepassing wys wat jy dink dit wys. As enige van die drie ontbreek of teenstrydig is, is die res van die lys irrelevant.
Die halfgepubliseerde geval lyk gesond by die ingang. Die virtuele bediener dra die toegangsprofiel terwyl die herskryfprofiel op die URI van 'n tweede hulpbron gemik is, so die webtop-inskrywing verskyn en die eerste bladsy laai, dan verlaat die versoeke na die subpad die pad van die poort en bereik die backend direk. Die spieëlbeeld is die hulpbron wat aan die verkeerde toepassing toegewys is: die merk maak oop, en dit maak iets oop wat niemand goedgekeur het nie.
Kontrole 2: die sessie van die backend staan apart
Die backend kan sy eie verifikasie vereis selfs terwyl APM die gebruiker as aangemeld beskou. Die ondersteunde SSO-integrasie vestig daardie verhouding vir jou, maar die aanvaarding van die portaal-aanmelding maak nie dat elke toepassing dieselfde geloofsbriewe of dieselfde sessiekoekie aanvaar nie. As SSO nie vir die hulpbron opgestel is nie, sal die toepassing sy eie aanmelding binne die reeds geverifieerde portaal vra.
Om SSO af te skakel om die sigbare aansporing te verander, is die algemene kortpad en 'n swak een: dit verander die verifikasie-ontwerp sonder om die lewensiklus te raak wat die aansporing veroorsaak het. Besluit eerder of die backend-aanmelding hoegenaamd moet verskyn, en maak dit dan deel van die gepubliseerde vloei.
Kontrole 3: daar is twee horlosies, en dit is nie dieselfde horlosie nie
Die toegangsprofiel van APM dra 'n tydoverskryding vir onaktiwiteit en 'n maksimum sessieleeftyd. Die toepassing dra sy eie ledige tydhouer en die vervaldatum van die koekie. Om die tydhouer van die portaal te verleng, verleng nie die sessie van die toepassing nie, en om die sessie van die toepassing te verkort, meld nie die gebruiker by die portaal af nie.
| 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 |
Die klassieke ondersteuningsoproep volg uit 'n passende paar wat nie pas nie: die portaal is nog geldig, die sessie van die toepassing is nie, en die gebruiker sien 'n vorm van aanmelding wat die portaal skynbaar weerspreek. Dit is korrekte gedrag, nie 'n fout nie, en die oplossing is om te kies watter horlosie vir hierdie toepassing eerste moet verval.
Kontrole 4: afmelding het 'n bepaalde omvang
Skryf neer wat die afmeldknoppie van die toepassing moet beëindig: net daardie toepassing, die hele APM-sessie, of 'n wyer sessie by die identiteitsverskaffer. Die toegangsprofiel ondersteun 'n lys van afmeld-URI's met vertraging na keuse, en dit is hoe jy die afmelding van die toepassing die portaal-sessie laat beëindig wanneer dit die vereiste is. Sonder dit bly die portaal lewendig na die afmelding van die toepassing, en 'n daaropvolgende versoek kan die gebruiker stilweg weer aanmeld.
Verreken die uitwerking op ander hulpbronne in dieselfde portaal. As afmelding by een toepassing die sessie vir ses ander beëindig, sal gebruikers dit 'n fout noem, tensy die gedrag vooraf met die eienaar van die toepassing ooreengekom is. Om die oortjie toe te maak en na die webtop terug te keer, is nie bewys dat iets beëindig is nie.
Kontrole 5: die toepassing oorleef die herskrywing
Portaaltoegang herskryf geselekteerde webinhoud, en herskrywing het rande. Moderne kenmerke aan die kliëntekant, agtergrondwerkers, oplaai-vloei en federatiewe aanmelding kan buite die bereik van 'n gegewe weergawe val. Die weergawe-gebonde versoenbaarheidsmatriks van F5 is die dokument om te lees voordat jy jou verbind, want die grense verskil per weergawe.
Toets die vloei wat saak maak eerder as die landingsbladsy: meld aan, navigeer deur elke vereiste funksie, laai op as die app oplaai, laat die beoogde sessie verval, en volg elke afmeldpad. 'n Bladsy wat een keer vertoon, is nie bewys dat die toepassing werk nie.
Wanneer 'n vereiste vloei nie herskryf kan word nie, skuif na 'n gedokumenteerde ontwerp vir federasie, omgekeerde proxy of netwerktoegang. 'n Blaaierportaal wat gevra word om soos 'n tonnel te werk, sal die demo slaag en die oudit faal.