SSO, Kerberos e SAML - Enterprise Identity Federation

Cos'e'

#

SSO, Kerberos e SAML sono tre soluzioni al problema dell'autenticazione a silos: senza di essi, ogni applicazione aziendale richiede credenziali separate, moltiplicando le password da ricordare e le superfici di attacco. SSO e' l'obiettivo architetturale, Kerberos e SAML sono i protocolli che lo realizzano in ambienti diversi.

SSO, Kerberos e SAML sono i meccanismi enterprise per autenticare l'utente una volta sola e propagare l'identita' a sistemi multipli — su rete locale (Kerberos) o tra organizzazioni diverse (SAML Federation).

TL;DR

#

SSO e' l'obiettivo (un login, N risorse), non un protocollo.

1. All'interno di una rete Windows, Kerberos emette ticket (TGT + Service Ticket) in sostituzione delle password.
2. Tra organizzazioni diverse, SAML trasporta via XML l'assertion di identita' dall'IdP al SP.
3. La password non viaggia mai sulla rete: viene usata solo per derivare chiavi (Kerberos) o non raggiunge mai il SP (SAML).
4. SSO senza MFA e' un'architettura difettosa: una sola credenziale compromessa apre tutti i sistemi.

L'Albero Decisionale SSO

#

Scegliere il protocollo giusto dipende dall'ecosistema. La domanda chiave e': sei su una rete Windows interna, stai federando con un'altra organizzazione via web, o stai delegando accesso a un'API?

graph TD
    DB[("Database Identita - LDAP / Active Directory")]
    SSO{"IdP / IDaaS (Motore SSO)
Okta - Entra ID - Keycloak"}
    INT["Risorse INTERNE
PC aziendali - file share - stampanti"]
    EXT["Servizi CLOUD B2B
Salesforce - Workday - Zoom"]
    APP["Autorizzare app terza
Spotify legge Google Calendar"]
    LOG["Login B2C tramite terzi
Accedi con Google su app mobile"]
    KERB["Kerberos (TGT)
porta 88"]
    SAM["SAML (XML Assertion)
HTTPS"]
    OAU["OAuth (Access Token)
AUTORIZZAZIONE"]
    OIDC["OIDC (ID Token)
AUTENTICAZIONE"]

    DB --- SSO
    SSO --> INT
    SSO --> EXT
    SSO --> APP
    SSO --> LOG
    INT -->|Usa| KERB
    EXT -->|Usa| SAM
    APP -->|Usa| OAU
    LOG -->|Usa| OIDC

    style SSO fill:#e67e22,color:#fff
    style KERB fill:#2980b9,color:#fff
    style SAM fill:#27ae60,color:#fff
    style OAU fill:#8e44ad,color:#fff
    style OIDC fill:#c0392b,color:#fff

Lettura diagramma: Il database delle identita' (LDAP/AD) alimenta il motore SSO (IdP/IDaaS). Da li', quattro scenari: reti interne usano Kerberos, servizi cloud B2B usano SAML, autorizzazioni API usano OAuth, login consumer usano OIDC. Il protocollo giusto dipende dall'ambiente, non dalla preferenza.

SSO - Single Sign-On

#

SSO e' un concetto architetturale: l'utente si autentica una volta sola, ottiene un token sicuro, e quel token viene presentato automaticamente a ogni risorsa successiva per tutta la sessione. Non e' un protocollo, ma un obiettivo realizzato da Kerberos, SAML e OIDC in ambienti diversi.

graph TD
    A[Utente vuole accedere a una risorsa] --> B{Ha gia' un token SSO?}

    B -->|NO - prima volta| C[Inserisce username e password]
    C --> D[IdP verifica le credenziali]
    D --> E[IdP genera un token sicuro
valido per tutta la sessione]
    E --> F[Accesso concesso]
    E --> G[(Token salvato in sessione)]

    B -->|SI - token presente| H[IdP presenta il token automaticamente]
    H --> F

    F --> I[Utente accede a un'altra risorsa]
    I --> B

    style C fill:#e74c3c,color:#fff
    style E fill:#27ae60,color:#fff
    style H fill:#27ae60,color:#fff
    style G fill:#8e44ad,color:#fff

Lettura diagramma: La prima volta (ramo rosso) l'utente inserisce le credenziali, l'IdP verifica e genera un token salvato in sessione. Le volte successive (ramo verde) il token e' gia' presente e viene presentato automaticamente senza reinserire la password. Il ciclo si ripete per ogni risorsa successiva.

Dev parallel: la sessione PHP con $_SESSION e il JWT Bearer token in un'API Node/Symfony sono la versione application-level dell'SSO. Un'unica autenticazione, un token, accesso a tutte le route protette senza reinserire le credenziali a ogni richiesta. La differenza e' la scala: SSO aziendale federa decine di applicazioni di organizzazioni diverse, non solo le route di un singolo progetto.

Kerberos

#

Kerberos e' il protocollo SSO per reti Windows interne. Invece di inviare la password su rete, usa un sistema a ticket: all'autenticazione iniziale si ottiene un "master ticket" (TGT), poi ogni risorsa specifica richiede un ticket derivato (Service Ticket) emesso senza reinserire la password. E' il motore di autenticazione di Active Directory.

sequenceDiagram
    participant U as Utente
    participant KDC as KDC (dentro il Domain Controller)
    participant R as Risorsa (file server / stampante)

    U->>KDC: 1 - Username + password hashata
    KDC->>KDC: Verifica le credenziali
    KDC->>U: 2 - TGT (valido ~10 ore)
    Note over U: La password non esce mai dal PC

    U->>KDC: 3 - Voglio accedere alla risorsa X (presenta TGT)
    KDC->>U: 4 - Service Ticket per risorsa X (valido ~1 ora)
    Note over KDC,U: Service Ticket contiene il PAC con gruppi e diritti

    U->>R: 5 - Presenta Service Ticket
    R->>R: Legge PAC - conosce gia' i permessi
    R->>U: 6 - Accesso concesso senza chiedere la password

Lettura diagramma: Kerberos in 6 passi. L'utente invia username e password hashata al KDC (passo 1). Il KDC verifica e restituisce il TGT (passo 2, valido 10 ore). La password non esce mai dal PC. Quando l'utente vuole accedere a una risorsa, presenta il TGT al KDC (passo 3). Il KDC emette un Service Ticket specifico (passo 4, valido 1 ora) che contiene il PAC con i permessi. L'utente presenta il Service Ticket alla risorsa (passo 5). La risorsa legge il PAC e concede l'accesso senza query aggiuntive al Domain Controller (passo 6).

Analogia con il mondo web:

Dev parallel: Kerberos in Active Directory e' il meccanismo che fa si' che un utente Windows acceda al file share o alla stampante di rete senza reinserire la password dopo il login mattutino. Il TGT viene rilasciato al momento del login al dominio, i Service Ticket vengono derivati automaticamente. Lo stesso principio del JWT Bearer token in Symfony: ottenuto al login, riusato per ogni route protetta senza re-autenticazione.

SAML - Security Assertion Markup Language

#

SAML e' il protocollo XML per l'SSO federato B2B: permette a un utente di autenticarsi presso la propria organizzazione (IdP) e accedere a servizi di organizzazioni terze (SP) senza che la password raggiunga mai il SP. E' il protocollo enterprise standard per federation tra aziende, universita', fornitori SaaS.

Flusso SP-Initiated (il piu' comune)

#

Nel flusso SP-initiated l'utente parte direttamente dall'applicazione che vuole usare. Il SP lo redirige all'IdP per l'autenticazione, poi il token torna all'utente che lo presenta al SP.

sequenceDiagram
    participant M as Mario (Principal)
    participant SP as SP - Microsoft 365
    participant IdP as IdP - Sapienza

    M->>SP: Vuole accedere a Teams
    SP->>M: Redirect alla Sapienza (IdP)
    M->>IdP: Login con credenziali Sapienza
    IdP->>IdP: Verifica nel proprio AD/LDAP
    IdP->>M: SAML Assertion - XML firmato
    M->>SP: Presenta SAML Assertion
    SP->>M: Accesso concesso - Microsoft non ha mai visto la password

Lettura diagramma: Mario vuole accedere a Teams (SP). Il SP lo redirige alla Sapienza (IdP). Mario fa login con le sue credenziali. L'IdP verifica nel proprio AD e produce un'assertion SAML (XML firmato). Mario presenta l'assertion a Microsoft 365. Microsoft accetta e concede l'accesso senza aver mai visto la password. La password resta sempre tra Mario e l'IdP.

Flusso IdP-Initiated

#

Nel flusso IdP-initiated l'utente parte dal portale aziendale. L'IdP invia proattivamente il token SAML al SP, senza che l'utente faccia una richiesta diretta all'app.

sequenceDiagram
    participant M as Mario (Principal)
    participant IdP as IdP - Sapienza
    participant SP as SP - Microsoft 365

    M->>IdP: Login con credenziali Sapienza
    IdP->>IdP: Verifica identita' nel proprio AD
    IdP->>SP: SAML Assertion inviata proattivamente
    SP->>M: Accesso concesso senza nuovo account

Lettura diagramma: Mario fa login direttamente sull'IdP (es. portale Sapienza). L'IdP verifica l'identita' e invia proattivamente un'assertion SAML al SP. Il SP concede l'accesso a Mario senza che lui abbia mai contattato direttamente il SP.

Dev parallel: SP-initiated e' analogo al redirect OAuth: l'app (SP) manda l'utente all'authorization server (IdP) per ottenere il token, poi l'utente torna con il token. IdP-initiated e' come quando un portale aziendale ti fa cliccare un link e ti manda direttamente sull'applicazione gia' autenticato, senza redirect espliciti.

SAML e Autorizzazione

#

SAML autentica (chi sei) ma puo' trasportare anche attributi di autorizzazione (cosa puoi fare). L'autenticazione e' sempre presente nell'assertion, l'autorizzazione e' opzionale e dipende da cosa l'IdP decide di includere.

Federation

#

La federation e' il concetto architetturale su cui si basa SAML: due organizzazioni stabiliscono una relazione di fiducia per riconoscere reciprocamente le identita', senza fondersi e senza condividere i sistemi. SAML e' il protocollo che implementa tecnicamente questo accordo.

Due termini da non confondere:

Vantaggi operativi della federation:

• Deprovisioning centralizzato: quando Mario si laurea, la Sapienza disabilita il suo account e lui perde automaticamente l'accesso a Microsoft 365, Coursera, Zoom e qualsiasi altro SP federato in un colpo solo.
• Nessun account separato per ogni SP: Mario usa sempre e solo le credenziali Sapienza.
• Trust configurabile: unidirezionale (Sapienza → Microsoft) o bidirezionale.

Scenario Reale Blue Team

#

In un ambiente enterprise, questi protocolli lasciano tracce nei log che il Blue Team deve saper leggere. Ecco come investigare anomalie su un sistema AD/Kerberos e un IdP SAML.

# Kerberos: visualizzare i ticket attivi sul sistema Windows (PowerShell)
klist

# Output atteso: TGT + Service Ticket con scadenza
# Se TGT e' assente ma l'utente e' loggato → anomalia

# Analisi log eventi Windows per Kerberos (Event ID critici)
# 4768 = TGT richiesto (Authentication Service Request)
# 4769 = Service Ticket richiesto (Ticket Granting Service Request)
# 4771 = Pre-authentication failed (tentativi login falliti)
# 4776 = DC ha tentato di validare credenziali

# Su Windows: filtrare log sicurezza per Kerberos
wevtutil qe Security /q:"*[System[EventID=4768 or EventID=4769 or EventID=4771]]" /f:text | head -100

# Linux con Kerberos (ambienti misti): verificare ticket
klist -v

# SAML: i log degli accessi federati vivono sull'IdP
# Okta: Admin → Reports → System Log → filtra per event type "user.authentication.sso"
# Azure AD: Sign-in logs → filtra per "Federated" in Authentication method

# Test connettivita' verso KDC (porta 88)
nmap -p 88 <domain-controller-ip>

# Verificare se un host e' nel dominio AD
realm list

Cosa cercare in un'analisi Kerberos (Blue Team):

• 4771 in massa da un singolo source IP → password spraying contro l'AD
• TGT con lifetime insolitamente lungo (> 10 ore) → Golden Ticket attack (Mimikatz)
• Service Ticket per servizi insoliti (KRBTGT, CIFS su server non noti) → Pass-the-Ticket
• Autenticazioni SAML con assertion riusate oltre la window di validita' → SAML replay

Collegato a

#

• pam — PAM gestisce account privilegiati che si autenticano tramite questi stessi protocolli
• pki — SAML usa certificati X.509 per firmare le assertion; Kerberos usa crittografia simmetrica/asimmetrica
• ssl-tls — SAML viaggia su HTTPS; la cifratura del canale protegge l'assertion XML in transito
• mitre-attack-framework — Golden Ticket (T1558.001), Pass-the-Ticket (T1550.003), SAML token forgery