APM-portalåtkomst: vem äger applikationens session?
Fem kontroller för ett publiceringsbeslut med BIG-IP Portal Access: resursens omfattning, backendsession, två timers, innebörden av utloggning och gränserna för omskrivning.
Att publicera en intranätapplikation via BIG-IP APM Portal Access är ett beslut om sessioner, inte om att kopiera en virtuell server. Portalen släpper in användaren, omskrivningsprofilen håller utvalda förfrågningar på gatewayens väg, och applikationen har fortfarande en egen session. Fem kontroller skiljer en design som beter sig förutsägbart från en där helpdesken lär sig om tidsgränser en användare i taget. Gå igenom dem i ordning och stanna vid den första som inte stämmer.
Kontroll 1: resursen är publicerad, inte bara länkad
Ett bokmärke i webtopen bevisar att en användare ser en post. Det bevisar inte att applikationen är publicerad. Leta efter åtkomstprofilen, omskrivningsprofilen och den virtuella server som kombinerar dem, och bekräfta sedan att resurstilldelningen pekar på den applikation du tror. Saknas någon av de tre eller är den inkonsekvent är resten av listan meningslös.
Fallet med halvt publicerad ser friskt ut vid ingången. Den virtuella servern bär åtkomstprofilen medan omskrivningsprofilen är begränsad till en annan resource-URI, så webtop-posten visas och den första sidan laddas, därefter lämnar förfrågningarna på undervägen gatewayens väg och når backend direkt. Spegelbilden är en resurs som tilldelats fel applikation: bokmärket öppnas, och det öppnar något som ingen har godkänt.
Kontroll 2: backendsessionen är ett eget tillstånd
Backend kan kräva sin egen autentisering även när APM anser att användaren är inloggad. En stödd SSO-integrering upprättar den relationen åt dig, men att acceptera portalinloggningen gör inte att varje applikation accepterar samma uppgifter eller samma sessionscookie. Om SSO inte är konfigurerat för resursen kommer applikationen att begära sin egen inloggning inne i en redan autentiserad portal.
Att stänga av SSO för att ändra den synliga uppmaningen är en vanlig och dålig genväg: den ändrar autentiseringsdesignen utan att röra livscykeln som skapade uppmaningen. Bestäm i stället om backendinloggningen alls ska visas, och om den ska det, gör den till en uttrycklig del av det publicerade flödet.
Kontroll 3: det finns två klockor, och de är inte samma klocka
APM:s åtkomstprofil bär en inaktivitets-timeout och en maximal sessionslivslängd. Applikationen bär sin egen idle-timer och cookiens utgång. Att förlänga portalens timer förlänger inte applikationens session, och att förkorta applikationens session loggar inte ut användaren från portalen.
| 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 |
Det klassiska supportärendet följer av ett par som inte passar: portalen är fortfarande giltig, applikationens session är det inte, och användaren ser ett inloggningsformulär som tycks motsäga portalen. Det är korrekt beteende, inte ett fel, och lösningen är att välja vilken klocka som ska gå ut först för den här applikationen.
Kontroll 4: utloggning har en definierad omfattning
Skriv ned vad applikationens utloggningsknapp ska avsluta: bara den applikationen, hela APM-sessionen eller en bredare identitetsleverantörssession. Åtkomstprofilen stöder en lista med utloggnings-URI:er och en valfri fördröjning, och det är så du får applikationens utloggning att avsluta portalsessionen när det är kravet. Utan det lämnar applikationens utloggning portalen levande, och en följande förfrågan kan tyst logga in användaren igen.
Räkna med effekten på andra resurser i samma portal. Om utloggning från en applikation avslutar sessionen för sex andra kommer användarna att kalla det en bugg om inte beteendet har avtalats med applikationens ägare i förväg. Att stänga en flik och återgå till webtopen är inte bevis för att något har avslutats.
Kontroll 5: applikationen överlever omskrivning
Portal Access skriver om utvalt webbinnehåll, och omskrivning har kanter. Moderna klientfunktioner, bakgrundsarbetare, uppladdningsflöden och federerad inloggning kan hamna utanför vad en given version hanterar. F5:s versionsbundna kompatibilitetsmatris är dokumentet du bör läsa innan du förbinder dig, eftersom gränserna är versionsberoende.
Testa flödena som betyder något, inte landningssidan: logga in, navigera genom varje nödvändig funktion, ladda upp om appen laddar upp, låt den avsedda sessionen gå ut och följ varje utloggningsväg. En sida som renderas en gång är inte bevis för att applikationen fungerar.
När ett nödvändigt flöde inte kan skrivas om, byt till en dokumenterad design för federation, omvänd proxy eller nätverksåtkomst. En webbläsarportal som ombeds bete sig som en allmän tunnel klarar demon och underkänns i revisionen.