Acceso ao portal APM: de quen é a sesión da aplicación?

Publicar unha aplicación de intranet mediante BIG-IP APM Portal Access é unha decisión sobre sesións, non sobre copiar un servidor virtual. O portal admite o usuario, o perfil de reescritura mantén as peticións seleccionadas na ruta da pasarela e a aplicación segue tendo unha sesión propia. Cinco comprobacións separan un deseño que se comporta de xeito previsible doutro no que o servizo de asistencia descobre os tempos de espera usuario a usuario. Repásaas en orde e detente na primeira que non se cumpra.

Comprobación 1: o recurso está publicado, non só ligado

Un marcador no webtop demostra que un usuario ve unha entrada. Non demostra que a aplicación estea publicada. Busca o perfil de acceso, o perfil de reescritura e o servidor virtual que os combina, e confirma despois que a asignación de recurso apunta á aplicación que cres. Se falta ou é incoherente calquera dos tres, o resto da lista non ten sentido.

O caso de publicación a medias parece san no punto de entrada. O servidor virtual leva o perfil de acceso mentres o perfil de reescritura está acoutado a outro URI de recurso, así que a entrada do webtop aparece e a primeira páxina carga, e logo as peticións da subruta abandonan a ruta da pasarela e chegan ao backend directamente. A imaxe inversa é un recurso asignado á aplicación equivocada: o marcador ábrese, e abre algo que ninguén aprobou.

Comprobación 2: a sesión do backend é un estado aparte

O backend pode esixir a súa propia autenticación mesmo cando APM considera que o usuario iniciou sesión. A integración de SSO compatible establece esa relación por ti, pero aceptar o inicio de sesión do portal non fai que cada aplicación acepte as mesmas credenciais ou a mesma cookie de sesión. Se SSO non está configurado para o recurso, a aplicación pedirá o seu propio inicio de sesión dentro dun portal xa autenticado.

Desactivar SSO para cambiar o aviso visible é un atallo habitual e malo: altera o deseño de autenticación sen tocar o ciclo de vida que produciu o aviso. Decide en cambio se o inicio de sesión do backend debe aparecer ou non, e se debe facelo, convérteo en parte explícita do fluxo publicado.

Comprobación 3: hai dous reloxos, e non son o mesmo reloxo

O perfil de acceso de APM leva un tempo de inactividade e unha vida máxima da sesión. A aplicación leva o seu propio temporizador de inactividade e a caducidade da cookie. Alongar o temporizador do portal non alonga a sesión da aplicación, e acurtar a sesión da aplicación non pecha a sesión do portal.

A chamada clásica ao servizo de asistencia nace dunha parella desaxustada: o portal segue sendo válido, a sesión da aplicación non, e o usuario ve un formulario de inicio de sesión que parece contradicir o portal. Iso é un comportamento correcto, non unha avaría, e a solución é escoller que reloxo debe caducar primeiro para esta aplicación.

Comprobación 4: o peche de sesión ten un alcance definido

Escribe que debe terminar o botón de peche de sesión da aplicación: só esa aplicación, toda a sesión de APM ou unha sesión máis ampla do provedor de identidade. O perfil de acceso admite unha lista de URI de peche de sesión cun atraso opcional, e así fas que o peche de sesión da aplicación termine a sesión do portal cando ese é o requisito. Sen iso, o peche de sesión da aplicación deixa o portal vivo, e unha petición posterior pode volver iniciar sesión ao usuario en silencio.

Ten en conta o efecto sobre outros recursos do mesmo portal. Se pechar a sesión dunha aplicación termina a sesión doutras seis, os usuarios chamaranlle erro salvo que o comportamento se acordase antes co propietario da aplicación. Pechar unha pestana e volver ao webtop non son proba de que algo rematase.

Comprobación 5: a aplicación sobrevive á reescritura

Portal Access reescribe contido web seleccionado, e a reescritura ten bordos. As funcións modernas do lado do cliente, os procesos en segundo plano, os fluxos de carga e o inicio de sesión federado poden quedar fóra do que manexa unha versión concreta. A matriz de compatibilidade por versións de F5 é o documento que hai que ler antes de comprometerse, porque os límites dependen da versión.

Proba os fluxos que importan, non a páxina de aterraxe: inicia sesión, navega por cada función necesaria, carga ficheiros se a aplicación os carga, deixa que caduque a sesión prevista e segue cada ruta de peche de sesión. Unha páxina que se renderiza unha vez non é proba de que a aplicación funcione.

Cando un fluxo necesario non se pode reescribir, pasa a un deseño documentado de federación, proxy inverso ou acceso de rede. Un portal de navegador ao que se lle pide comportarse como un túnel xeral superará a demostración e suspenderá a auditoría.