Identità federata: SAML, OAuth e OpenID Connect

Nelle aziende moderne, i dipendenti devono accedere a decine di applicazioni — app cloud, strumenti SaaS, portali dei partner e sistemi interni — ciascuna potenzialmente gestita da organizzazioni diverse. Creare e gestire account separati per ognuna è insicuro (proliferazione delle credenziali) e inefficiente. La federated identity risolve questo problema consentendo a un Identity Provider (IdP) — una fonte di identità autorevole e affidabile — di autenticare gli utenti e condividere tale identità autenticata con i Service Provider (SP) oltre i confini organizzativi. Gli utenti effettuano l'autenticazione una sola volta e ottengono l'accesso a più sistemi senza dover reinserire le credenziali.

Il Single Sign-On (SSO) consente agli utenti di autenticarsi una sola volta e accedere a più applicazioni durante una sessione senza ripetere l'autenticazione. L'utente accede all'Identity Provider (Active Directory aziendale, Okta, Azure AD), riceve un token di sessione o un'asserzione e presenta questo token a ogni Service Provider che visita. L'SSO migliora la sicurezza riducendo il numero di password che gli utenti devono gestire (e quindi il loro riutilizzo), consentendo di applicare centralmente le policy di autenticazione e permettendo di revocare immediatamente l'accesso in tutte le applicazioni integrate quando un account viene disabilitato a livello di IdP.

SAML (Security Assertion Markup Language) 2.0 è lo standard aperto basato su XML per lo scambio di dati di autenticazione e autorizzazione tra Identity Provider e Service Provider. Il flusso SAML è il seguente: (1) l'utente accede a un Service Provider (ad esempio Salesforce); (2) l'SP reindirizza l'utente all'Identity Provider (ad esempio Okta); (3) l'utente effettua l'autenticazione presso l'IdP; (4) l'IdP emette una SAML Assertion XML firmata, contenente l'identità e gli attributi dell'utente; (5) l'asserzione viene restituita all'SP; (6) l'SP convalida la firma dell'asserzione usando la chiave pubblica dell'IdP e concede l'accesso. SAML è ampiamente utilizzato per l'SSO aziendale nelle applicazioni web.

A una federazione SAML partecipano tre soggetti. Il Principal è l'utente (o il sistema) che richiede l'accesso e avvia il processo di autenticazione. L'Identity Provider (IdP) è la fonte autorevole dell'identità, autentica il principal ed emette le asserzioni; tra gli esempi figurano Microsoft Azure AD, Okta, Ping Identity e ADFS. Il Service Provider (SP) utilizza l'asserzione e concede l'accesso in base a essa; tra gli esempi figurano Salesforce, Google Workspace, AWS e qualsiasi applicazione abilitata per SAML. L'SP e l'IdP stabiliscono preventivamente una relazione di trust scambiandosi metadati contenenti gli URL degli endpoint e i certificati di firma reciproci.

OAuth 2.0 è un framework di autorizzazione (non un protocollo di autenticazione) che consente a un'applicazione di terze parti di accedere alle risorse per conto di un utente senza esporne le credenziali. Il caso d'uso classico è: «Consenti a questa app di fotoritocco di accedere a Google Photos». OAuth 2.0 introduce quattro ruoli: il Resource Owner (l'utente), il Client (l'app di terze parti), l'Authorization Server (emette i token) e il Resource Server (ospita la risorsa protetta). L'utente autorizza il client, che riceve un access token da presentare al resource server, senza dover mai utilizzare la password effettiva dell'utente.

Il Authorization Code Flow è il flusso OAuth 2.0 più sicuro per le applicazioni web. Il flusso è il seguente: (1) il Client reindirizza l'utente all'Authorization Server indicando gli scope richiesti; (2) l'utente effettua l'autenticazione e concede il consenso presso l'Authorization Server; (3) l'Authorization Server reindirizza l'utente al Client con un authorization code di breve durata; (4) il Client scambia il codice con un access token (e facoltativamente un refresh token) tramite una chiamata da server a server usando le credenziali del client; (5) il Client usa l'access token per chiamare il Resource Server. Lo scambio del codice avviene lato server, impedendo che l'access token venga esposto nella cronologia del browser o nei log.

OpenID Connect (OIDC) è un livello di autenticazione basato su OAuth 2.0. OAuth fornisce solo l'autorizzazione (gli access token dimostrano cosa può fare il client); OIDC aggiunge l'autenticazione (un ID token dimostra chi è l'utente). OIDC aggiunge lo scope openid al flusso OAuth e restituisce un JWT (JSON Web Token) ID Token firmato insieme all'access token. L'ID token contiene claims (nome, email, sub [subject identifier]) che identificano l'utente. OIDC è oggi il protocollo dominante per l'SSO rivolto agli utenti finali: i pulsanti «Sign in with Google/Apple/Microsoft» usano tutti OIDC.

I JSON Web Tokens (JWT) sono un formato compatto e sicuro per gli URL per rappresentare le claims tra soggetti. Un JWT è composto da tre parti codificate in base64url e separate da punti: Header (algoritmo e tipo di token), Payload (claims: iss, sub, aud, exp, iat e claims personalizzate) e Signature (firma crittografica che verifica l'integrità del token). I JWT sono self-contained: il Resource Server può verificarli senza contattare nuovamente l'Authorization Server, migliorando le prestazioni e consentendo architetture stateless. Il requisito di sicurezza fondamentale è verificare sempre la firma del JWT e controllare le claims exp (scadenza) e aud (audience).

Capire quando applicare ciascuno standard è fondamentale per l'esame Security+. SAML 2.0: SSO aziendale per applicazioni web, flussi basati sul browser e asserzioni XML. È una tecnologia legacy, ma ampiamente utilizzata nelle aziende. OAuth 2.0: autorizzazione per le API, ovvero concessione alle app di terze parti di un accesso limitato alle risorse. Non autentica direttamente gli utenti. OIDC: autenticazione per gli utenti finali e per le aziende moderne (SSO), basata su OAuth 2.0. Restituisce ID token JWT che identificano l'utente. In pratica, gli ambienti aziendali usano spesso SAML per l'SSO delle applicazioni e OIDC per l'autenticazione di API e dispositivi mobili. Gli ambienti moderni cloud-native preferiscono OIDC a SAML per il formato JSON/JWT e il migliore supporto ai dispositivi mobili.

I sistemi di federated identity introducono specifici vettori di attacco. Attacchi di replay delle asserzioni: un aggressore intercetta un'asserzione SAML e la riutilizza per ottenere l'accesso. Il rischio viene mitigato con asserzioni di breve durata e ID delle asserzioni utilizzabili una sola volta. XML signature wrapping (XSW): in SAML, gli aggressori possono talvolta manipolare l'XML firmato per alterare le claims mantenendo valida la firma sul contenuto originale. Confusione dell'algoritmo JWT: se un server accetta sia gli algoritmi RS256 (asimmetrico) sia HS256 (simmetrico), un aggressore può falsificare i JWT usando la chiave pubblica del server come segreto HMAC per HS256. Convalidi sempre che l'algoritmo nell'header corrisponda a quello previsto. Open redirector: gli URI di reindirizzamento OAuth devono corrispondere esattamente, per impedire il furto dei token tramite reindirizzamenti verso siti controllati dall'aggressore.

La federazione delle identità aziendali richiede spesso la sincronizzazione dei dati sull'identità degli utenti tra i sistemi. SCIM (System for Cross-domain Identity Management) è uno standard API REST per automatizzare il provisioning e il deprovisioning degli utenti tra un Identity Provider e i Service Provider connessi. Quando un nuovo dipendente viene aggiunto ad Azure AD (IdP), SCIM crea automaticamente il relativo account in Salesforce, Slack, GitHub e nelle altre app compatibili con SCIM. Quando il dipendente cessa il rapporto di lavoro, SCIM disattiva contemporaneamente tutti gli account, eliminando la finestra temporale in cui gli account orfani potrebbero essere sfruttati. SCIM integra i protocolli SSO (SAML/OIDC) gestendo il ciclo di vita delle identità, aspetto non coperto dai protocolli SSO.

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha imparato che: SAML 2.0 utilizza asserzioni XML per l'SSO aziendale basato sul browser; OAuth 2.0 è un framework di autorizzazione per la delega dell'accesso alle API; OpenID Connect aggiunge l'autenticazione (ID token JWT) a OAuth; e SCIM automatizza la gestione del ciclo di vita delle identità nei sistemi federati. Con questo si conclude il corso su Authentication and Authorization; prossimamente esamineremo i Network Security Fundamentals.