I tre portali guest di Cisco ISE rispondono a esigenze diverse di onboarding, tracciabilità e overhead amministrativo. Sceglierli correttamente è il cuore dello scenario d’esame: la domanda non è “quale portale esiste”, ma “quale portale in questo contesto e con quali conseguenze sull’authorization policy”.
Il flusso comune: Central Web Authentication (CWA)
Tutti e tre i portali si appoggiano al pattern CWA, che è una autenticazione a due fasi guidata da CoA (Change of Authorization):
- Il client si associa alla WLAN aperta (o cablata) e viene autenticato in MAB. L’endpoint è sconosciuto, quindi ISE restituisce un authorization result che contiene un redirect ACL e la redirect URL verso il guest portal.
- L’utente apre il browser, completa l’interazione richiesta dal portale (AUP, login, registrazione). ISE invia un CoA reauth al NAD (WLC o switch): la sessione viene rivalutata e il nuovo authorization result concede l’accesso pieno (
PermitAccesso dACL/VLAN dedicata).
Il punto critico: dopo il CoA la policy deve avere una seconda regola che intercetta la sessione autenticata, altrimenti l’utente ricicla all’infinito sul portale.
Hotspot portal
Nessun account. L’utente accetta la Acceptable Use Policy (AUP) e (opzionalmente) inserisce un Access Code condiviso. È l’onboarding più rapido, ideale per Wi-Fi retail o sale d’attesa.
Meccanismo chiave: la device registration. Al momento dell’accettazione, il MAC dell’endpoint viene scritto in un endpoint identity group (default GuestEndpoints). Alla riconnessione successiva, il MAB trova l’endpoint già registrato e la policy lo autorizza senza ripresentare l’AUP, fino alla scadenza della registrazione o al purge dell’endpoint.
Conseguenza per l’authorization policy: la regola post-login dell’hotspot si costruisce sul membership dell’endpoint identity group, non su un’identità utente.
Self-registered portal
L’ospite crea da solo il proprio account (nome, email, telefono…). Le credenziali vengono memorizzate e usate per il login. Due varianti fondamentali:
- Self-registration con accesso immediato: l’account è subito utilizzabile.
- Self-registration con approvazione (sponsor approval): l’account resta in stato pending finché uno sponsor non lo approva (tipicamente via email con link approve/deny). Aggiunge accountability senza carico operativo costante.
Il Guest Type assegnato governa durata dell’account, orari, numero massimo di device e time profile. Fornisce tracciabilità reale: ogni sessione è legata a un utente identificabile e loggato.
Sponsored guest portal
L’account è creato a monte da uno sponsor tramite lo Sponsor Portal. Lo sponsor consegna le credenziali all’ospite (stampa, email, SMS). È il modello a massima governance: chi autorizza, chi è autorizzato e per quanto tempo sono tutti tracciati e attribuibili.
Lo sponsor è vincolato da uno sponsor group che definisce quali guest type può creare, quali permessi ha (bulk, notifiche, reset password) e su quali location.
Confronto sintetico
| Aspetto | Hotspot | Self-registered | Sponsored |
|---|---|---|---|
| Account utente | Nessuno | Creato dall’ospite | Creato dallo sponsor |
| Interazione | Solo AUP (+ access code) | Registrazione + login | Login con credenziali fornite |
| Tracciabilità utente | Debole (solo MAC) | Buona | Massima |
| Approvazione | Non prevista | Opzionale (sponsor approval) | Implicita nello sponsor |
| Overhead operativo | Minimo | Basso | Medio/alto |
| Meccanismo distintivo | Device registration | Guest self-provisioning | Sponsor Portal |
Legame con l’authorization policy dopo il login
Per hotspot la regola finale si aggancia all’endpoint identity group popolato dalla registrazione. Per self-registered e sponsored la condizione autoritativa è Network Access:UseCase EQUALS Guest Flow: è l’attributo che ISE valuta sulla sessione dopo un login guest andato a buon fine, e va combinato con il Guest Type o l’identity group per differenziare i profili di accesso.
Trappole tipiche d’esame
- Scenario: serve sapere chi è connesso per audit/compliance → risposta giusta: self-registered (meglio se con approvazione) o sponsored; mai hotspot, che non crea account e offre solo il MAC come identificatore.
- Scenario: l’utente accetta l’AUP ma resta bloccato in redirect loop → risposta giusta: manca la seconda regola di authorization che intercetta la sessione dopo il CoA (per hotspot: membership in
GuestEndpoints; per credentialed:UseCase EQUALS Guest Flow). - Scenario: dopo l’hotspot il device richiede di nuovo l’AUP ogni volta → risposta giusta: la device registration non viene sfruttata; verificare l’endpoint identity group configurato nel portale e la regola che lo referenzia.
- Scenario: l’IT non deve creare manualmente gli account ma serve comunque un controllo → risposta giusta: self-registered con sponsor approval, non sponsored (che richiede creazione manuale) né hotspot (nessun controllo).
- Scenario: la policy usa la condizione
Guest Flowma l’hotspot non matcha → risposta giusta: l’hotspot non generaUseCase Guest Flowcome un login credenziale; va agganciato all’endpoint identity group, non alla condizione Guest Flow.