A partire dalla data X, l’architettura di autenticazione dell’Ateneo di Parma, basata sul protocollo Shibboleth, è stata integrata con il sistema di Identity Management di Microsoft, EntraID (precedentemente Azure AD). Questa evoluzione introduce un nuovo flusso di accesso unificato: tutte le tipologie di utenza — incluse le identità strutturate (@unipr.it), le carriere studentesche (@studenti.unipr.it) e gli account esterni/ospiti (@guest.unipr.it) — dovranno ora interagire con un pulsante di autenticazione delegata presente sulla pagina di login.

Tale configurazione delega la verifica delle credenziali direttamente al provider Microsoft, estendendo così l'obbligatorietà dell'autenticazione a più fattori (MFA - Multi-Factor Authentication) a tutti i servizi web di Ateneo federati.

L’obiettivo è uniformare i criteri di sicurezza già in vigore per l'ecosistema Microsoft 365 (come la posta elettronica istituzionale e Teams), garantendo un perimetro di protezione coerente e robusto per l'intero Single Sign-On (SSO) universitario.

L'interfaccia del Servizio Accesso Web dell'Ateneo è stata aggiornata per riflettere le nuove policy di sicurezza. La schermata di login presenta ora una distinzione netta tra le utenze istituzionali/standard e le utenze tecniche temporanee.

Per tutte le categorie di utenza sottoelencate, l'accesso avviene esclusivamente tramite il nuovo pulsante “Entra con UNIPR”:

• Personale strutturato e contrattualizzato (@unipr.it)

• Studenti (@studenti.unipr.it)

• Account ospiti e collaboratori esterni (@guest.unipr.it)

L'interazione con questo pulsante è obbligatoria; esso funge da gateway verso il provider EntraID, dove verrà perfezionata l'autenticazione tramite l'inserimento delle credenziali e la successiva validazione del secondo fattore (MFA).

Per agevolare la transizione, è stato predisposto un pop-up informativo a tempo che compare automaticamente all'apertura della pagina, ricordando agli utenti degli sopraccitati domini di utilizzare esclusivamente il percorso di login delegato.

Il form di inserimento diretto (campi Username e Password) presente nella sezione “Accesso riservato alle utenze con credenziali numeriche temporanee” non è più abilitato per le utenze istituzionali.

Gli utenti che in precedenza hanno memorizzato le proprie credenziali (@unipr.it, @studenti.unipr.it o @guest.unipr.it) all'interno del gestore password del proprio browser (Chrome, Firefox, Edge, etc.) devono prestare particolare attenzione:

• Il sistema è configurato per impedire l'autenticazione qualora si tenti di inviare il form tradizionale con tali account. In caso di errore, comparirà un avviso specifico in rosso che invita all'utilizzo del pulsante corretto.

• Si raccomanda di ignorare il completamento automatico del browser in questa sezione e di procedere direttamente con il pulsante “Entra con UNIPR”.

Un utente viene reindirizzato verso l'autenticazione Microsoft EntraID quando sussistono le seguenti condizioni:

1. La sessione Shibboleth non è persistente nel browser

La sessione Shibboleth è legata a un cookie non permanente.
Quando l’utente chiude il browser, il cookie viene rimosso e Shibboleth non può più riconoscerlo.
Conseguenza: al successivo accesso viene richiesto un nuovo login su EntraID.

2. La sessione Shibboleth può scadere per inattività

La sessione IdP ha un suo timeout. Se l’utente non accede ad alcun servizio per un lungo periodo, la sessione scade e Shibboleth richiede una nuova autenticazione. (Vedere più avanti: Tempistiche attualmente configurate (valori provvisori))

3. La precedente autenticazione non è sempre riutilizzabile Ogni autenticazione ha:

• un timeout di inattività
• una durata massima assoluta

Se uno di questi limiti viene superato, Shibboleth non può riusare la precedente autenticazione e deve richiedere un nuovo login EntraID.

4. Accesso a un nuovo service provider (SP)

Ogni SP decide se deve rivolgersi all’IdP.
Se l’SP non trova una sessione locale valida (o è un nuovo SP per l’utente), invia una AuthnRequest all’IdP: ciò può eventualmente comportare una nuova autenticazione EntraID.

Se uno SP invia una AuthnRequest con ForceAuthn=true, Shibboleth IdP è obbligato ad avviare una nuova autenticazione, anche se:

• la sessione IdP è ancora valida,
• l’AuthenticationResult è recente,
• l’utente ha appena usato un altro SP due secondi prima.

5. Scelta architetturale: nessun SSO con Microsoft 365

Per motivi di sicurezza, Shibboleth non riutilizza la sessione Microsoft 365.

• Essere già loggati su Microsoft 365 non basta per accedere ai servizi Shibboleth.
• Può venire richiesto un nuovo login EntraID (con MFA), anche se Microsoft 365 è aperto.

Le sessioni Microsoft hanno tempi di validità molto lunghi (refresh token ampi).
Per questo motivo le autenticazioni Shibboleth sono indipendenti e più stringenti.

6. Cambio di browser o modalità anonima

Ogni browser gestisce i cookie separatamente.
Se l’utente cambia browser o usa la modalità anonima, Shibboleth non trova più la sessione e richiede un nuovo login EntraID.

Altre situazioni, meno frequenti ma possibili

Questi casi sono rari, ma tecnicamente possono verificarsi:

• utilizzo del link diretto di logout dell’IdP (/idp/profile/Logout) e logout federato (SLO)
• rimozione manuale dei cookie da parte dell’utente
• cambio improvviso della rete o dell’indirizzo IP (dipende dalla configurazione di sicurezza - idp.session.consistentAddress = true)
• tab del browser lasciata aperta per molte ore, con sessione SP scaduta
• casi isolati di perdita della sessione lato server (es. riavvio o pulizia Memcached)

In attesa della definizione dei valori definitivi, l’IdP utilizza i seguenti timeout:

• idp.authn.defaultTimeout = 24 ore

Se per 4 ore nessuno SP contatta l’IdP, la precedente autenticazione non può essere riutilizzata → nuovo login EntraID.

• idp.authn.defaultLifetime = 7 giorni

Durata massima assoluta dell’ultima autenticazione valida.

• idp.session.timeout = 7 giorni

Durata massima della sessione IdP, misurata dall’ultimo utilizzo (sliding window). Obiettivo: ridurre la frequenza delle autenticazioni verso EntraID mantenendo un adeguato livello di sicurezza.

Le tempistiche dei token lato Shibboleth prevalgono rispetto alla durata del token (refresh token) di EntraID.

1. idp.session.timeout
• Tipo: Duration
• Valore originale: PT60M (60 minuti)
• Nuovo valore: P7D (7 giorni)
• Significato: È la durata massima di una sessione IdP, indipendentemente dall'attività dell’utente. Anche se l’utente rimane attivo, dopo 7 giorni la sessione viene comunque chiusa e servirà una nuova autenticazione.
• In parole semplici: “La sessione IdP dura al massimo 7 giorni.”

2. idp.authn.defaultLifetime
• Tipo: Duration
• Valore originale: PT60M
• Nuovo valore: P7D
• Significato: È il periodo massimo in cui si può riusare un’autenticazione preesistente (un “previous authentication flow”). Conta dal momento in cui quell’autenticazione viene usata per la prima volta.
• In parole semplici: “Per 7 giorni dalla prima autenticazione, posso riutilizzare quella login senza rifarla.”

3. idp.authn.defaultTimeout
• Tipo: Duration
• Valore originale: PT30M
• Nuovo valore: PT24H
• Significato: È il timeout di inattività relativo alla possibilità di riutilizzare un’autenticazione precedente. Se l’utente rimane inattivo per 24 ore, la vecchia autenticazione non può più essere riutilizzata.
• In parole semplici: “Se sto fermo per più di 24 ore, devo rifare l’autenticazione.”

Tabella riepilogativa:

Questo parametro rappresenta il tempo massimo di inattività oltre il quale l’IdP non può più riusare una precedente autenticazione (es. login EntraID) all’interno di una sessione IdP ancora valida.
Se l’utente non accede ad alcun servizio per un tempo superiore del valore impostato (es. 4 ore), quando torna all'IdP, deve rifare il processo di autenticazione: nel nostro caso, viene rilanciata la delega verso EntraID con forceAuthn, che richiede nuovamente credenziali/MFA.

Questo parametro non chiude la sessione IdP (che dura complessivamente 7 giorni), ma limita quanto a lungo è riusabile un singolo “risultato di autenticazione” pregresso.
Aumentare il defaultTimeout significa ridurre la frequenza delle ri-autenticazioni verso EntraID dopo periodi di inattività, migliorando l’esperienza utente, a fronte di un’estensione della finestra di rischio in cui la stessa autenticazione può essere riutilizzata senza nuovo challenge.

1. Accesso iniziale: L’utente accede alla prima pagina protetta.
2. Richiesta di Autenticazione: Lo SP invia una AuthnRequest all’IdP.
3. Risposta SAML: L’IdP autentica l’utente (o riutilizza un AuthenticationResult esistente) e invia una SAML Response.
4. Sessione Locale: Lo SP crea una propria sessione locale tramite un cookie SP-side.

Da quel momento in poi, il comportamento del sistema segue queste regole:

• Persistenza: Lo SP non rimanda l’utente all’IdP finché la propria sessione interna rimane valida.
• Navigazione interna: Navigare tra le pagine dello stesso SP non coinvolge affatto l’IdP.

Punto chiave: Visitare una pagina “a caso” dello SP NON comporta il riuso dell’AuthenticationResult, poiché quell’azione non causa alcun contatto con l’IdP; l'accesso è totalmente gestito dal cookie di sessione dello SP.

L'Identity Provider viene interpellato solo quando un Service Provider (qualsiasi) richiede una nuova autenticazione SAML. Questo accade nei seguenti scenari:

• Nuovo accesso: L’utente accede a uno SP in cui non ha ancora una sessione locale.
• Sessione scaduta: La sessione locale dello SP è scaduta e deve essere rigenerata.
• Richiesta forzata: Lo SP richiede specificamente una nuova AuthnRequest (ad esempio tramite il parametro ForceAuthn).
• Nuovo servizio: L'utente accede a un nuovo SP mai visitato prima durante l'attuale sessione IdP.

Avendo impostato attualmente

• idp.authn.defaultTimeout = 24 ore
• idp.authn.defaultLifetime = 7 giorni
• idp.session.timeout = 7 giorni

Se l’utente usa servizi periodicamente, oppure passa da uno SP a un altro entro 4 ore, l’IdP potrà riutilizzare la precedente autenticazione → SSO fluido, nessuna nuova richiesta di login.

Se passa più di 24 ore senza che lo SP contatti l’IdP (cioè senza accedere a un nuovo servizio protetto), l’IdP dovrà ripetere l’autenticazione verso EntraID.

La sessione complessiva dell’utente dura comunque massimo 7 giorni.