Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

--- guide_pubbliche:autenticazione_shib_mfa [2026/01/15 10:07] – riccardo.cappone_unipr.it
+++ guide_pubbliche:autenticazione_shib_mfa [2026/04/13 12:01] (versione attuale) – [Tempistiche attualmente configurate (valori provvisori)] riccardo.cappone_unipr.it
@@ Linea 1: / Linea 1: @@
 ====== Aggiornamento del Sistema di Autenticazione Centralizzata (SSO) ======
-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.
+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.
@@ Linea 28: / Linea 28: @@
   * Personale strutturato e contrattualizzato (@unipr.it)
-  * Studenti e dottorandi (@studenti.unipr.it)
+  * Studenti (@studenti.unipr.it)
   * Account ospiti e collaboratori esterni (@guest.unipr.it)
@@ Linea 63: / Linea 63: @@
 ====== Validità temporale e regole tecniche dell'autenticazione Shibboleth ======
-Quando un utente viene reindirizzato verso l'autenticazione Microsoft EntraID:
+Un utente viene reindirizzato verso l'autenticazione Microsoft EntraID quando sussistono le seguenti condizioni:
 **1. La sessione Shibboleth non è persistente nel browser**
@@ Linea 122: / Linea 122: @@
 In attesa della definizione dei valori definitivi, l’IdP utilizza i seguenti timeout:
-  * **idp.authn.defaultTimeout = 4 ore**
+  * **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 = 8 ore**
+  * **idp.authn.defaultLifetime = 7 giorni**
 Durata massima assoluta dell’ultima autenticazione valida.
-  * **idp.session.timeout = 8 ore**
+  * **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.
-===== Per i veri Geek: parametri di configurazione per le tempistiche =====
+===== Per i veri Geek: parametri di configurazione delle tempistiche =====
 **Le tempistiche dei token lato Shibboleth prevalgono rispetto alla durata del token (refresh token) di EntraID.**
@@ Linea 139: / Linea 139: @@
 •	Tipo: Duration\\
 •	Valore originale: PT60M (60 minuti)\\
-•	Nuovo valore: PT8H (8 ore)\\
+•	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 8 ore la sessione viene comunque chiusa e servirà una nuova autenticazione.\\
+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 8 ore.”
+•	In parole semplici: “La sessione IdP dura al massimo 7 giorni.”
 **2. idp.authn.defaultLifetime**\\
 •	Tipo: Duration\\
 •	Valore originale: PT60M\\
-•	Nuovo valore: PT8H\\
+•	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 8 ore dalla prima autenticazione, posso riutilizzare quella login senza rifarla.”
+•	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: PT4H\\
+•	Nuovo valore: PT24H\\
 •	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.\\
+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 60 minuti, devo rifare l’autenticazione.”
+•	In parole semplici: “Se sto fermo per più di 24 ore, devo rifare l’autenticazione.”
 Tabella riepilogativa:
 ^ Parametro                  ^ Valor precedente  ^ Nuovo valore  ^ Significato pratico                                                                ^ Tipo di timeout                 ^
-| idp.session.timeout        | 60 min            | 8 h           | Durata massima della sessione IdP                                                  | Assoluto (hard limit)           |
+| idp.session.timeout        | 60 min            | 7 g           | Durata massima della sessione IdP                                                  | Assoluto (hard limit)           |
-| idp.authn.defaultLifetime  | 60 min            | 8 h           | Durata massima per riusare l’autenticazione valida                                 | Assoluto (sull’autenticazione)  |
+| idp.authn.defaultLifetime  | 60 min            | 7 g           | Durata massima per riusare l’autenticazione valida                                 | Assoluto (sull’autenticazione)  |
-| idp.authn.defaultTimeout   | 30 min            | 4 h           | Tempo massimo di inattività prima che l’autenticazione non sia più riutilizzabile  | Inattività                      |
+| idp.authn.defaultTimeout   | 30 min            | 24 h           | Tempo massimo di inattività prima che l’autenticazione non sia più riutilizzabile  | Inattività                      |
@@ Linea 176: / Linea 176: @@
 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 8 ore), ma limita quanto a lungo è riusabile un singolo “risultato di autenticazione” pregresso.\\
+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.
@@ Linea 207: / Linea 207: @@
   * **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.
+==== Diagramma tempistiche di sessione SP e IdP con defaultTimeout e defaultLifetime ====
+<mermaid>
+flowchart TD
+  A[Utente accede a un service provider] --> B{Sessione SP ancora valida}
+  B -->|Si| C[Accesso diretto al service provider]
+  B -->|No| D[SP reindirizza verso IdP Shibboleth]
+  D --> E{Cookie di sessione IdP presente}
+  E -->|No| H[IdP vede nuova sessione utente]
+  E -->|Si| F{Sessione IdP entro idp.session.timeout}
+  F -->|No| H
+  F -->|Si| G{Risultato di autenticazione entro idp.authn.defaultTimeout}
+  G -->|No| H
+  G -->|Si| I{Risultato di autenticazione entro idp.authn.defaultLifetime}
+  I -->|No| H
+  I -->|Si| L[IdP riusa autenticazione esistente nessuna delega Entra ID]
+  L --> M[IdP emette risposta verso SP]
+  M --> N[SP crea nuova sessione SP e concede accesso]
+  H --> O[IdP avvia delega verso Entra ID con forceAuthn attivo]
+  O --> P[Entra ID chiede login all utente]
+  P --> Q[Utente completa login su Entra ID]
+  Q --> R[IdP crea nuova sessione IdP e nuovo risultato di autenticazione]
+  R --> M
+</mermaid>