A partire dalla data odierna, 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 e dottorandi (@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”.

Quando un utente viene reindirizzato verso l'autenticazione Microsoft EntraID:

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 = 4 ore

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

• idp.authn.defaultLifetime = 8 ore

Durata massima assoluta dell’ultima autenticazione valida.

• idp.session.timeout = 8 ore

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: PT8H (8 ore)
• Significato: È la durata massima di una sessione IdP, indipendentemente dall'attività dell’utente. Anche se l’utente rimane attivo, dopo 8 ore la sessione viene comunque chiusa e servirà una nuova autenticazione.
• In parole semplici: “La sessione IdP dura al massimo 8 ore.”

2. idp.authn.defaultLifetime
• Tipo: Duration
• Valore originale: PT60M
• Nuovo valore: PT8H
• 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 8 ore dalla prima autenticazione, posso riutilizzare quella login senza rifarla.”

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

Tabella riepilogativa: