Accès au portail APM : à qui appartient la session de l’application ?

Publier une application intranet via BIG-IP APM Portal Access est une décision sur les sessions, pas sur la copie d’un serveur virtuel. Le portail admet l’utilisateur, le profil de réécriture maintient certaines requêtes sur le chemin de la passerelle, et l’application possède toujours sa propre session. Cinq contrôles séparent une conception qui se comporte de façon prévisible d’une autre où le service d’assistance découvre les délais d’inactivité utilisateur par utilisateur. Déroulez-les dans l’ordre et arrêtez-vous au premier qui n’est pas vérifié.

Contrôle 1 : la ressource est publiée, pas seulement liée

Un signet dans le webtop prouve qu’un utilisateur voit une entrée. Il ne prouve pas que l’application est publiée. Cherchez le profil d’accès, le profil de réécriture et le serveur virtuel qui les combine, puis confirmez que l’affectation de ressource pointe vers l’application que vous croyez. Si l’un des trois manque ou est incohérent, le reste de la liste est sans objet.

Le cas à moitié publié paraît sain au point d’entrée. Le serveur virtuel porte le profil d’accès tandis que le profil de réécriture est limité à un autre URI de ressource : l’entrée du webtop apparaît et la première page se charge, puis les requêtes du sous-chemin quittent le chemin de la passerelle et atteignent le backend directement. L’image inverse est une ressource affectée à la mauvaise application : le signet s’ouvre, et il ouvre quelque chose que personne n’a approuvé.

Contrôle 2 : la session du backend est un état distinct

Le backend peut exiger sa propre authentification alors même qu’APM considère l’utilisateur connecté. Une intégration SSO prise en charge établit cette relation pour vous, mais accepter la connexion au portail ne fait pas accepter à chaque application les mêmes identifiants ni le même cookie de session. Si SSO n’est pas configuré pour la ressource, l’application demandera sa propre connexion à l’intérieur d’un portail déjà authentifié.

Désactiver SSO pour changer l’invite visible est un raccourci courant et médiocre : il modifie la conception de l’authentification sans toucher au cycle de vie qui a produit l’invite. Décidez plutôt si la connexion au backend doit apparaître, et si oui, faites-en une partie explicite du flux publié.

Contrôle 3 : il y a deux horloges, et ce ne sont pas les mêmes

Le profil d’accès d’APM porte un délai d’inactivité et une durée de vie maximale de session. L’application porte son propre minuteur d’inactivité et l’expiration de son cookie. Allonger la minuterie du portail ne prolonge pas la session de l’application, et raccourcir la session de l’application ne déconnecte pas l’utilisateur du portail.

L’appel d’assistance classique découle d’une paire désaccordée : le portail est encore valide, la session de l’application ne l’est plus, et l’utilisateur voit un formulaire de connexion qui semble contredire le portail. C’est un comportement correct, pas une panne, et la solution consiste à choisir quelle horloge doit expirer en premier pour cette application.

Contrôle 4 : la déconnexion a une portée définie

Écrivez ce que le bouton de déconnexion de l’application doit terminer : cette application seule, toute la session APM ou une session plus large du fournisseur d’identité. Le profil d’accès prend en charge une liste d’URI de déconnexion avec un délai facultatif, et c’est ainsi que vous faites terminer la session du portail par la déconnexion de l’application lorsque c’est l’exigence. Sans cela, la déconnexion de l’application laisse le portail vivant, et une requête ultérieure peut reconnecter l’utilisateur en silence.

Tenez compte de l’effet sur les autres ressources du même portail. Si la déconnexion d’une application termine la session de six autres, les utilisateurs appelleront cela un défaut, à moins que le comportement n’ait été convenu au préalable avec le propriétaire de l’application. Fermer un onglet et revenir au webtop ne prouvent pas que quelque chose s’est terminé.

Contrôle 5 : l’application survit à la réécriture

Portal Access réécrit certains contenus web, et la réécriture a ses limites. Les fonctionnalités modernes côté client, les traitements d’arrière-plan, les flux de téléversement et la connexion fédérée peuvent sortir de ce qu’une version donnée gère. La matrice de compatibilité par version de F5 est le document à lire avant de s’engager, car les limites dépendent de la version.

Testez les flux qui comptent plutôt que la page d’accueil : connectez-vous, parcourez chaque fonction requise, téléversez si l’application le fait, laissez la session prévue expirer et suivez chaque chemin de déconnexion. Une page qui s’affiche une fois ne prouve pas que l’application fonctionne.

Lorsqu’un flux requis ne peut pas être réécrit, passez à une conception documentée de fédération, de proxy inverse ou d’accès réseau. Un portail navigateur à qui l’on demande de se comporter comme un tunnel général réussira la démonstration et échouera à l’audit.