Accés al portal APM: de qui és la sessió de l’aplicació?

Publicar una aplicació d’intranet mitjançant BIG-IP APM Portal Access és una decisió sobre sessions, no sobre copiar un servidor virtual. El portal admet l’usuari, el perfil de reescriptura manté les sol·licituds seleccionades al camí de la passarel·la, i l’aplicació continua tenint una sessió pròpia. Cinc comprovacions separen un disseny que es comporta de manera previsible d’un altre on el servei d’assistència descobreix els temps d’espera usuari a usuari. Feu-les en ordre i atureu-vos a la primera que no sigui certa.

Comprovació 1: el recurs està publicat, no només enllaçat

Una adreça desada al webtop demostra que l’usuari veu una entrada. No demostra que l’aplicació estigui publicada. Cerqueu el perfil d’accés, el perfil de reescriptura i el servidor virtual que els combina, i confirmeu després que l’assignació del recurs apunta a l’aplicació que us penseu. Si falta qualsevol dels tres o és incoherent, la resta de la llista no té sentit.

El cas de publicació a mitges sembla sa al punt d’entrada. El servidor virtual porta el perfil d’accés mentre el perfil de reescriptura està limitat a un altre URI de recurs, de manera que l’entrada del webtop apareix i la primera pàgina carrega, i després les sol·licituds del subcamí abandonen el camí de la passarel·la i arriben al backend directament. La imatge inversa és un recurs assignat a l’aplicació equivocada: l’adreça s’obre, i obre una cosa que ningú no havia aprovat.

Comprovació 2: la sessió del backend és un estat a part

El backend pot exigir la seva pròpia autenticació fins i tot quan APM considera l’usuari dins la sessió. La integració SSO suportada estableix aquesta relació per vosaltres, però acceptar l’inici de sessió del portal no fa que cada aplicació accepti les mateixes credencials o la mateixa galeta de sessió. Si SSO no està configurat per al recurs, l’aplicació demanarà el seu propi inici de sessió dins d’un portal ja autenticat.

Desactivar SSO per canviar el missatge visible és una drecera habitual i dolenta: altera el disseny d’autenticació sense tocar el cicle de vida que havia produït el missatge. Decidiu en canvi si l’inici de sessió del backend ha d’aparèixer o no, i si ha d’aparèixer, feu-ne una part explícita del flux publicat.

Comprovació 3: hi ha dos rellotges, i no són el mateix rellotge

El perfil d’accés d’APM porta un temps d’inactivitat i una vida màxima de la sessió. L’aplicació porta el seu propi temporitzador d’inactivitat i la caducitat de la galeta. Allargar el temporitzador del portal no allarga la sessió de l’aplicació, i escurçar la sessió de l’aplicació no tanca la sessió del portal.

La trucada clàssica a l’assistència surt d’una parella descompensada: el portal encara és vàlid, la sessió de l’aplicació no, i l’usuari veu un formulari d’inici de sessió que sembla contradir el portal. Això és un comportament correcte, no una avaria, i la solució és triar quin rellotge ha de caducar primer per a aquesta aplicació.

Comprovació 4: el tancament de sessió té un abast definit

Escriviu què ha d’acabar el botó de sortida de l’aplicació: només aquella aplicació, tota la sessió APM o una sessió més àmplia del proveïdor d’identitat. El perfil d’accés admet una llista d’URI de sortida amb un retard opcional, i així és com feu que la sortida de l’aplicació acabi la sessió del portal quan aquest és el requisit. Sense això, la sortida de l’aplicació deixa el portal viu, i una sol·licitud posterior pot tornar a entrar l’usuari en silenci.

Compteu l’efecte sobre altres recursos del mateix portal. Si tancar la sessió d’una aplicació acaba la sessió de sis més, els usuaris ho qualificaran d’error tret que el comportament s’hagi acordat abans amb el propietari de l’aplicació. Tancar una pestanya i tornar al webtop no són prova que res hagi acabat.

Comprovació 5: l’aplicació sobreviu a la reescriptura

Portal Access reescriu contingut web seleccionat, i la reescriptura té vores. Les funcions modernes del costat del client, els processos en segon pla, els fluxos de càrrega i l’inici de sessió federat poden quedar fora del que gestiona una versió concreta. La matriu de compatibilitat per versions de F5 és el document que cal llegir abans de comprometre-s’hi, perquè els límits depenen de la versió.

Proveu els fluxos que importen i no la pàgina d’entrada: inicieu sessió, navegueu per cada funció necessària, pugeu fitxers si l’aplicació ho fa, deixeu que la sessió prevista caduqui i seguiu cada camí de sortida. Una pàgina que es renderitza una vegada no és prova que l’aplicació funcioni.

Quan un flux necessari no es pot reescriure, passeu a un disseny documentat de federació, de proxy invers o d’accés de xarxa. Un portal de navegador al qual es demana que es comporti com un túnel general passarà la demostració i suspendrà l’auditoria.