Accesso al portale APM: a chi appartiene la sessione dell’applicazione?

Pubblicare un’applicazione intranet tramite BIG-IP APM Portal Access è una decisione sulle sessioni, non sulla copia di un server virtuale. Il portale ammette l’utente, il profilo di riscrittura mantiene le richieste selezionate sul percorso del gateway e l’applicazione possiede ancora una sessione propria. Cinque controlli separano un progetto che si comporta in modo prevedibile da uno in cui l’help desk scopre i timeout utente per utente. Seguili in ordine e fermati al primo che non risulta vero.

Controllo 1: la risorsa è pubblicata, non solo collegata

Un segnalibro nel webtop dimostra che un utente vede una voce. Non dimostra che l’applicazione sia pubblicata. Cerca il profilo di accesso, il profilo di riscrittura e il server virtuale che li combina, poi conferma che l’assegnazione della risorsa punti all’applicazione che pensi. Se uno dei tre manca o è incoerente, il resto dell’elenco è privo di senso.

Il caso a metà pubblicazione sembra sano al punto di ingresso. Il server virtuale porta il profilo di accesso mentre il profilo di riscrittura è limitato a un altro URI della risorsa, così la voce del webtop compare e la prima pagina si carica, poi le richieste del sotto-percorso lasciano il percorso del gateway e raggiungono il backend direttamente. L’immagine speculare è una risorsa assegnata all’applicazione sbagliata: il segnalibro si apre, e apre qualcosa che nessuno ha approvato.

Controllo 2: la sessione del backend è uno stato separato

Il backend può richiedere un’autenticazione propria anche quando APM considera l’utente connesso. Un’integrazione SSO supportata stabilisce quella relazione per te, ma accettare il login del portale non fa accettare a ogni applicazione le stesse credenziali o lo stesso cookie di sessione. Se SSO non è configurato per la risorsa, l’applicazione chiederà il proprio login dentro un portale già autenticato.

Disattivare SSO per cambiare il messaggio visibile è una scorciatoia comune e scadente: modifica il progetto di autenticazione senza toccare il ciclo di vita che ha prodotto il messaggio. Decidi invece se il login del backend debba comparire del tutto, e se deve, fanne una parte esplicita del flusso pubblicato.

Controllo 3: ci sono due orologi, e non sono lo stesso orologio

Il profilo di accesso di APM porta un timeout di inattività e una durata massima della sessione. L’applicazione porta il proprio timer di inattività e la scadenza del cookie. Allungare il timer del portale non prolunga la sessione dell’applicazione, e accorciare la sessione dell’applicazione non disconnette l’utente dal portale.

La classica chiamata all’assistenza nasce da una coppia mal assortita: il portale è ancora valido, la sessione dell’applicazione no, e l’utente vede un modulo di accesso che sembra contraddire il portale. È un comportamento corretto, non un guasto, e la soluzione è scegliere quale orologio deve scadere per primo per questa applicazione.

Controllo 4: il logout ha un ambito definito

Scrivi cosa deve terminare il pulsante di uscita dell’applicazione: solo quell’applicazione, l’intera sessione APM o una sessione più ampia del provider di identità. Il profilo di accesso supporta un elenco di URI di logout con un ritardo opzionale, ed è così che fai terminare al logout dell’applicazione la sessione del portale quando è questo il requisito. Senza, il logout dell’applicazione lascia vivo il portale, e una richiesta successiva può riconnettere l’utente in silenzio.

Tieni conto dell’effetto sulle altre risorse dello stesso portale. Se il logout da un’applicazione termina la sessione di altre sei, gli utenti lo chiameranno difetto a meno che il comportamento non sia stato concordato prima con il proprietario dell’applicazione. Chiudere una scheda e tornare al webtop non sono prova che qualcosa sia terminato.

Controllo 5: l’applicazione sopravvive alla riscrittura

Portal Access riscrive contenuti web selezionati, e la riscrittura ha i suoi bordi. Le funzionalità moderne lato client, i processi in background, i flussi di caricamento e il login federato possono cadere fuori da ciò che una data versione gestisce. La matrice di compatibilità per versione di F5 è il documento da leggere prima di impegnarsi, perché i limiti dipendono dalla versione.

Prova i flussi che contano, non la pagina di atterraggio: accedi, naviga ogni funzione richiesta, carica file se l’applicazione lo fa, lascia scadere la sessione prevista e segui ogni percorso di logout. Una pagina che si visualizza una volta non è prova che l’applicazione funzioni.

Quando un flusso richiesto non può essere riscritto, passa a un progetto documentato di federazione, proxy inverso o accesso di rete. Un portale browser a cui si chiede di comportarsi come un tunnel generale supererà la demo e fallirà l’audit.