APM-Portalzugriff: Wem gehört die Sitzung der Anwendung?
Fünf Prüfungen für eine Veröffentlichungsentscheidung mit BIG-IP Portal Access: Ressourcenumfang, Backend-Sitzung, zwei Zeitgeber, Bedeutung des Abmeldens und Grenzen des Umschreibens.
Eine Intranet-Anwendung über BIG-IP APM Portal Access zu veröffentlichen ist eine Entscheidung über Sitzungen, nicht über das Kopieren eines virtuellen Servers. Das Portal lässt den Benutzer herein, das Rewrite-Profil hält ausgewählte Anfragen auf dem Pfad des Gateways, und die Anwendung besitzt weiterhin ihre eigene Sitzung. Fünf Prüfungen trennen ein Design, das sich vorhersehbar verhält, von einem, bei dem der Helpdesk von Timeouts Benutzer für Benutzer erfährt. Arbeiten Sie sie der Reihe nach ab und halten Sie bei der ersten an, die nicht zutrifft.
Prüfung 1: die Ressource ist veröffentlicht, nicht nur verlinkt
Ein Lesezeichen im Webtop belegt, dass ein Benutzer einen Eintrag sieht. Es belegt nicht, dass die Anwendung veröffentlicht ist. Suchen Sie das Zugriffsprofil, das Rewrite-Profil und den virtuellen Server, der beide verbindet, und bestätigen Sie dann, dass die Ressourcenzuweisung auf die Anwendung zeigt, die Sie meinen. Fehlt eine der drei oder ist sie widersprüchlich, ist der Rest der Liste gegenstandslos.
Der halb veröffentlichte Fall sieht am Einstiegspunkt gesund aus. Der virtuelle Server trägt das Zugriffsprofil, während das Rewrite-Profil auf eine andere Resource-URI begrenzt ist, sodass der Webtop-Eintrag erscheint und die erste Seite lädt, danach verlassen die Anfragen des Unterpfads den Pfad des Gateways und erreichen das Backend direkt. Das Spiegelbild ist eine Ressource, die der falschen Anwendung zugewiesen ist: Das Lesezeichen öffnet sich, und es öffnet etwas, das niemand genehmigt hat.
Prüfung 2: die Backend-Sitzung ist ein eigener Zustand
Das Backend kann eine eigene Authentifizierung verlangen, selbst wenn APM den Benutzer als angemeldet betrachtet. Eine unterstützte SSO-Integration stellt diese Beziehung für Sie her, aber die Portal-Anmeldung zu akzeptieren führt nicht dazu, dass jede Anwendung dieselben Anmeldedaten oder dasselbe Sitzungs-Cookie akzeptiert. Ist SSO für die Ressource nicht konfiguriert, verlangt die Anwendung ihre eigene Anmeldung innerhalb eines bereits authentifizierten Portals.
SSO abzuschalten, um die sichtbare Aufforderung zu ändern, ist ein verbreiteter und schlechter Abkürzungsweg: Er ändert das Authentifizierungsdesign, ohne den Lebenszyklus anzutasten, der die Aufforderung erzeugt hat. Entscheiden Sie stattdessen, ob die Backend-Anmeldung überhaupt erscheinen soll, und wenn ja, machen Sie sie zu einem ausdrücklichen Teil des veröffentlichten Ablaufs.
Prüfung 3: es gibt zwei Uhren, und es ist nicht dieselbe Uhr
Das Zugriffsprofil von APM trägt einen Inaktivitäts-Timeout und eine maximale Sitzungslebensdauer. Die Anwendung trägt ihren eigenen Idle-Timer und den Ablauf des Cookies. Einen Portal-Timer zu erhöhen verlängert keine Anwendungssitzung, und eine Anwendungssitzung zu verkürzen meldet den Benutzer nicht vom Portal ab.
| 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 |
Der klassische Supportanruf folgt aus einem unpassenden Paar: Das Portal ist noch gültig, die Anwendungssitzung nicht, und der Benutzer sieht ein Anmeldeformular, das dem Portal scheinbar widerspricht. Das ist korrektes Verhalten, kein Fehler, und die Lösung besteht darin, zu wählen, welche Uhr für diese Anwendung zuerst ablaufen soll.
Prüfung 4: die Abmeldung hat einen definierten Umfang
Schreiben Sie auf, was die Abmeldeschaltfläche der Anwendung beenden soll: nur diese Anwendung, die gesamte APM-Sitzung oder eine weiter reichende Sitzung des Identitätsanbieters. Das Zugriffsprofil unterstützt eine Liste von Logout-URIs mit optionaler Verzögerung, und so erreichen Sie, dass die Abmeldung der Anwendung die Portalsitzung beendet, wenn das die Anforderung ist. Ohne sie lässt die Abmeldung der Anwendung das Portal am Leben, und eine folgende Anfrage kann den Benutzer stillschweigend wieder anmelden.
Berücksichtigen Sie die Wirkung auf andere Ressourcen im selben Portal. Wenn die Abmeldung von einer Anwendung die Sitzung für sechs weitere beendet, nennen Benutzer das einen Fehler, sofern das Verhalten nicht vorher mit dem Eigentümer der Anwendung abgestimmt wurde. Einen Tab zu schließen und zum Webtop zurückzukehren ist kein Beweis dafür, dass etwas beendet wurde.
Prüfung 5: die Anwendung übersteht das Umschreiben
Portal Access schreibt ausgewählte Webinhalte um, und das Umschreiben hat Ränder. Moderne Client-Funktionen, Hintergrundprozesse, Upload-Abläufe und föderierte Anmeldung können außerhalb dessen liegen, was eine gegebene Version abdeckt. Die versionsgebundene Kompatibilitätsmatrix von F5 ist das Dokument, das vor der Festlegung zu lesen ist, denn die Grenzen sind release-spezifisch.
Testen Sie die Abläufe, auf die es ankommt, nicht die Startseite: Melden Sie sich an, navigieren Sie durch jede erforderliche Funktion, laden Sie hoch, wenn die App hochlädt, lassen Sie die vorgesehene Sitzung ablaufen und folgen Sie jedem Abmeldeweg. Eine Seite, die einmal rendert, ist kein Beleg dafür, dass die Anwendung funktioniert.
Wenn ein erforderlicher Ablauf nicht umgeschrieben werden kann, wechseln Sie zu einem dokumentierten Föderations-, Reverse-Proxy- oder Netzwerkzugriffsdesign. Ein Browserportal, von dem verlangt wird, sich wie ein allgemeiner Tunnel zu verhalten, besteht die Demo und scheitert im Audit.