APM-portaltoegang: van wie is de sessie van de applicatie?

Een intranetapplicatie publiceren via BIG-IP APM Portal Access is een beslissing over sessies, niet over het kopiëren van een virtuele server. De portal laat de gebruiker binnen, het herschrijfprofiel houdt geselecteerde verzoeken op het pad van de gateway, en de applicatie heeft nog steeds een eigen sessie. Vijf controles scheiden een ontwerp dat zich voorspelbaar gedraagt van een waarin de helpdesk tijdlimieten gebruiker voor gebruiker leert kennen. Werk ze in volgorde af en stop bij de eerste die niet klopt.

Controle 1: de resource is gepubliceerd, niet alleen gelinkt

Een bladwijzer in de webtop bewijst dat een gebruiker een item ziet. Hij bewijst niet dat de applicatie is gepubliceerd. Zoek het toegangsprofiel, het herschrijfprofiel en de virtuele server die ze combineert, en bevestig dan dat de resourcetoewijzing naar de applicatie wijst die je denkt. Ontbreekt een van de drie of is die inconsistent, dan is de rest van de lijst irrelevant.

Het half gepubliceerde geval ziet er gezond uit bij het toegangspunt. De virtuele server draagt het toegangsprofiel terwijl het herschrijfprofiel beperkt is tot een andere resource-URI, zodat het webtop-item verschijnt en de eerste pagina laadt, waarna de verzoeken van het subpad het pad van de gateway verlaten en de backend direct bereiken. Het spiegelbeeld is een resource die aan de verkeerde applicatie is toegewezen: de bladwijzer opent, en hij opent iets dat niemand heeft goedgekeurd.

Controle 2: de backendsessie is een aparte toestand

De backend kan zijn eigen authenticatie eisen, zelfs wanneer APM de gebruiker als ingelogd beschouwt. Een ondersteunde SSO-integratie legt die relatie voor je vast, maar de portaal-login accepteren maakt niet dat elke applicatie dezelfde inloggegevens of dezelfde sessiecookie accepteert. Is SSO niet geconfigureerd voor de resource, dan vraagt de applicatie om zijn eigen login binnen een al geauthenticeerd portaal.

SSO uitschakelen om de zichtbare prompt te veranderen is een veelgebruikte en slechte sluiproute: het wijzigt het ontwerp van de authenticatie zonder de levenscyclus aan te raken die de prompt heeft veroorzaakt. Beslis in plaats daarvan of de backend-login überhaupt moet verschijnen, en als dat zo is, maak er dan een expliciet onderdeel van de gepubliceerde flow van.

Controle 3: er zijn twee klokken, en het is niet dezelfde klok

Het toegangsprofiel van APM draagt een inactiviteitstimeout en een maximale sessieduur. De applicatie draagt zijn eigen idle-timer en het verlopen van de cookie. Een portaal-timer verhogen verlengt geen applicatiesessie, en een applicatiesessie verkorten logt de gebruiker niet uit het portaal.

Het klassieke supportgesprek komt voort uit een paar dat niet past: het portaal is nog geldig, de applicatiesessie niet, en de gebruiker ziet een loginformulier dat het portaal schijnbaar tegenspreekt. Dat is correct gedrag, geen storing, en de oplossing is kiezen welke klok voor deze applicatie eerst moet verlopen.

Controle 4: uitloggen heeft een gedefinieerde omvang

Schrijf op wat de uitlogknop van de applicatie moet beëindigen: alleen die applicatie, de hele APM-sessie of een bredere sessie van de identiteitsprovider. Het toegangsprofiel ondersteunt een lijst met logout-URI's met een optionele vertraging, en zo zorg je dat het uitloggen van de applicatie de portaalsessie beëindigt wanneer dat de eis is. Zonder dat laat het uitloggen van de applicatie het portaal leven, en een volgend verzoek kan de gebruiker stil weer aanmelden.

Houd rekening met het effect op andere resources in hetzelfde portaal. Als uitloggen bij één applicatie de sessie van zes andere beëindigt, noemen gebruikers dat een fout, tenzij het gedrag vooraf met de eigenaar van de applicatie is afgestemd. Een tab sluiten en terugkeren naar de webtop bewijst niet dat er iets is beëindigd.

Controle 5: de applicatie overleeft het herschrijven

Portal Access herschrijft geselecteerde webinhoud, en herschrijven heeft randen. Moderne clientfuncties, achtergrondtaken, uploadstromen en federatieve login kunnen buiten vallen wat een bepaalde versie aankan. De versiegebonden compatibiliteitsmatrix van F5 is het document dat je moet lezen voordat je je vastlegt, omdat de grenzen versieafhankelijk zijn.

Test de stromen die ertoe doen, niet de landingspagina: log in, navigeer door elke vereiste functie, upload als de app uploadt, laat de bedoelde sessie verlopen en volg elk uitlogpad. Een pagina die één keer rendert is geen bewijs dat de applicatie werkt.

Als een vereiste stroom niet herschreven kan worden, stap over op een gedocumenteerd federatie-, reverse-proxy- of netwerktoegangsontwerp. Een browserportaal dat wordt gevraagd zich als een algemene tunnel te gedragen, haalt de demo en zakt voor de audit.