Acceso al portal APM: ¿de quién es la sesión de la aplicación?
Cinco comprobaciones para una decisión de publicación con BIG-IP Portal Access: alcance del recurso, sesión del backend, dos temporizadores, significado del cierre de sesión y límites de la reescritura.
Publicar una aplicación de intranet mediante BIG-IP APM Portal Access es una decisión sobre sesiones, no sobre copiar un servidor virtual. El portal admite al usuario, el perfil de reescritura mantiene las peticiones seleccionadas en la ruta de la pasarela y la aplicación sigue teniendo una sesión propia. Cinco comprobaciones separan un diseño que se comporta de forma predecible de otro en el que el servicio de asistencia descubre los tiempos de espera usuario a usuario. Repásalas en orden y detente en la primera que no se cumpla.
Comprobación 1: el recurso está publicado, no solo enlazado
Un marcador en el webtop demuestra que un usuario ve una entrada. No demuestra que la aplicación esté publicada. Busca el perfil de acceso, el perfil de reescritura y el servidor virtual que los combina, y confirma después que la asignación de recurso apunta a la aplicación que crees. Si falta o es incoherente cualquiera de los tres, el resto de la lista no tiene sentido.
El caso de publicación a medias parece sano en el punto de entrada. El servidor virtual lleva el perfil de acceso mientras el perfil de reescritura está acotado a otro URI de recurso, así que la entrada del webtop aparece y la primera página carga, y luego las peticiones de la subruta abandonan la ruta de la pasarela y llegan al backend directamente. La imagen inversa es un recurso asignado a la aplicación equivocada: el marcador se abre, y abre algo que nadie aprobó.
Comprobación 2: la sesión del backend es un estado aparte
El backend puede exigir su propia autenticación incluso cuando APM considera que el usuario ha iniciado sesión. La integración de SSO compatible establece esa relación por ti, pero aceptar el inicio de sesión del portal no hace que cada aplicación acepte las mismas credenciales o la misma cookie de sesión. Si SSO no está configurado para el recurso, la aplicación pedirá su propio inicio de sesión dentro de un portal ya autenticado.
Desactivar SSO para cambiar el aviso visible es un atajo habitual y malo: altera el diseño de autenticación sin tocar el ciclo de vida que produjo el aviso. Decide en cambio si el inicio de sesión del backend debe aparecer o no, y si debe hacerlo, conviértelo en parte explícita del flujo publicado.
Comprobación 3: hay dos relojes, y no son el mismo reloj
El perfil de acceso de APM lleva un tiempo de inactividad y una vida máxima de la sesión. La aplicación lleva su propio temporizador de inactividad y la caducidad de la cookie. Alargar el temporizador del portal no alarga la sesión de la aplicación, y acortar la sesión de la aplicación no cierra la sesión del portal.
| 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 |
La llamada clásica al servicio de asistencia nace de una pareja desajustada: el portal sigue siendo válido, la sesión de la aplicación no, y el usuario ve un formulario de inicio de sesión que parece contradecir al portal. Eso es un comportamiento correcto, no una avería, y la solución es elegir qué reloj debe caducar primero para esta aplicación.
Comprobación 4: el cierre de sesión tiene un alcance definido
Escribe qué debe terminar el botón de cierre de sesión de la aplicación: solo esa aplicación, toda la sesión de APM o una sesión más amplia del proveedor de identidad. El perfil de acceso admite una lista de URI de cierre de sesión con un retardo opcional, y así haces que el cierre de sesión de la aplicación termine la sesión del portal cuando ese es el requisito. Sin ello, el cierre de sesión de la aplicación deja el portal vivo, y una petición posterior puede volver a iniciar sesión al usuario en silencio.
Ten en cuenta el efecto sobre otros recursos del mismo portal. Si cerrar la sesión de una aplicación termina la sesión de otras seis, los usuarios lo llamarán error salvo que el comportamiento se haya acordado antes con el propietario de la aplicación. Cerrar una pestaña y volver al webtop no son prueba de que algo haya terminado.
Comprobación 5: la aplicación sobrevive a la reescritura
Portal Access reescribe contenido web seleccionado, y la reescritura tiene bordes. Las funciones modernas del lado del cliente, los procesos en segundo plano, los flujos de carga y el inicio de sesión federado pueden quedar fuera de lo que maneja una versión concreta. La matriz de compatibilidad por versiones de F5 es el documento que hay que leer antes de comprometerse, porque los límites dependen de la versión.
Prueba los flujos que importan, no la página de aterrizaje: inicia sesión, navega por cada función necesaria, sube archivos si la aplicación los sube, deja que caduque la sesión prevista y sigue cada ruta de cierre de sesión. Una página que se renderiza una vez no es prueba de que la aplicación funcione.
Cuando un flujo necesario no se puede reescribir, pasa a un diseño documentado de federación, proxy inverso o acceso de red. Un portal de navegador al que se le pide comportarse como un túnel general superará la demo y suspenderá la auditoría.