Caratteristiche e Differenza tra LDAP, SAML e Oauth

Caratteristiche e Differenza tra LDAP, SAML e Oauth

LDAP

Lightweight Directory Access Protocol (LDAP) è una tecnologia che permette di organizzare in modo efficiente le informazioni relative a un’identità digitale e interrogarla tramite protocolli basati su IP. È ottimizzata per le operazioni più frequenti di verifica dell’identità (lettura e ricerca) ed ha una struttura gerarchica. Le modalità di funzionamento sono specificate da una serie di standard dell’IETF che ne assicurano un’ottima interoperabilità.

Le funzioni principali prevedono la possibilità di organizzare le informazioni in una struttura gerarchica, le entità appartenenti al Directory sono determinate da uno schema, quindi fortemente tipizzate. Ogni entità è definita da una serie di attributi i cui valori ammessi e la dimensione sono sempre definiti nello schema.

I tipici elementi di un Directory sono:

  • utenti: rappresentazione dell’identità digitale assegnata ad un utente, collegata ad una password in forma di hash, verificata al momento del binding;
  • gruppi: permettono di specificare logiche di appartenenza su cui è possibile costruire un controllo di accessi RBAC, i gruppi possono essere innestati tra loro e l’utente può appartenere a più gruppi;
  • organizational unit: è una suddivisione logica dell’organizzazione, permette di specificare indirettamente la designazione di un utente se collocato al suo interno, ha il limite di prevedere un’assegnazione 1 a molti, non adattandosi correttamente ai contesti dove gli utenti possono avere più designazioni contemporaneamente.

LDAP è parte integrante dei sistemi di autorizzazione più diffusi, si può dire che ogni organizzazione ne ha (almeno) uno. I prodotti più diffusi in questo campo sono Microsoft Active Directory, Novell eDirectory (Novell Directory Services), Oracle Unified Directory, OpenLDAP (opensource) e OpenDJ (opensource). Inoltre sono disponibili librerie per qualsiasi linguaggio di programmazione, rendendone semplice l’integrazione in un qualunque sistema software.

Probabilmente a causa di questa semplicità di integrazione questa tecnologia viene spesso utilizzata in modo inappropriato, sfruttandola per implementare anche il processo di autenticazione, a discapito dei meccanismi visti in precedenza. Il binding LDAP è infatti l’operazione che permette di accedere al Directory specificando l’identità dell’utente e le credenziali per accedervi. Se questa operazione viene mediata da un altro sistema software (ad esempio un web service o un’applicazione web che hanno accesso al Directory), quest’ultimo può efficacemente verificare l’identità fornita da un utente.

Il problema di questa modalità, rispetto ad una soluzione sicura come Kerberos, è che espone le credenziali dell’utente al sistema software (non necessariamente trusted, o con livelli di manutenzione adeguata alla delicatezza del ruolo).

Caratteristiche e Differenza tra LDAP, SAML e Oauth

SAML e WS-Federation

SAML è un protocollo basato su XML che permette di definire flussi di autenticazione e autorizzazione, coprendo una serie di casi d’uso specificati nei profili che stabiliscono le regole della comunicazione.

Ad esempio il Web SSO profile può essere usato per veicolare attributi relativi all’utente che possono essere recuperati al momento dell’autenticazione (informazioni puntuali ma anche appartenenza a gruppi, quindi a ruoli), permettendo quindi di specificare le autorizzazioni dell’utente agli occhi del fornitore dell’identità.

Un altro profilo interessante è l’Assertion Query/Request Profile, esso permette di scambiare tra Service Provider e Attribute Authority (che può essere il fornitore dell’identità o una o più parti terze) messaggi per il recupero di attributi (AttributeQuery) o decisioni autorizzative (AuthzDecisionQuery).

WS-Federation è un altro insieme di specifiche, simile a SAML, inizialmente sviluppato nel 2002 da Microsoft e IBM con l’obiettivo di definire i profili di interazione dei messaggi tra Web Service per garantirne la sicurezza. Fa parte dell’iniziativa WS-* basata su SOAP che raccoglie altri standard quali WS-Security, WS-Trust, WS-Policy, WSPrivacy, WS-Authorization, WS-SecureConversation. Si tratta una famiglia di protocolli piuttosto diffusa nell’ambiente Enterprise.

La suite è specificamente orientata alla sicurezza dell’interazione tra Web Service, tuttavia esiste un WS-Federation Passive Requestor Profile che ha un funzionamento simile al flusso di autenticazione di SAML.

Oauth

Il framework di autorizzazione Oauth 2.0 si propone come ideale complemento di OpenID e si rivolge ad un contesto più flessibile e dinamico di quello Enterprise a cui sono rivolti di più SAML e WS-*.

La sua nascita è dovuta principalmente a due esigenze dei principali fornitori di applicazioni web:

  1. la necessità di consentire l’interazione tra applicazioni web di diversi fornitori, su autorizzazione di un utente, utilizzando la propria identità;
  2. la necessità di poter accedere ai dati di un’applicazione web attraverso un dispositivo mobile senza dover reinserire ogni volta le credenziali, attività molto scomoda in mobilità.

Oauth risponde a queste richieste con un modello che prevede quattro attori e una serie di flussi di funzionamento (flow) tra cui scegliere per meglio rispondere al caso d’uso specifico.

La comunicazione è basata su REST, secondo la sequenza:

  1. il Client (che può essere un’applicazione web o nativa) effettua una richiesta di autorizzazione al Resource Owner (tipicamente l’utente finale);
  2. il Resource Owner accetta fornendo un Authorization Grant (tipicamente delle credenziali);
  3. il Client fornisce l’Authorization Grant all’Authorization Server che restituisce un Access Token un lasciapassare con scadenza che permette di accedere liberamente senza ripetere l’autorizzazione per un certo periodo di tempo;
  4. il Client fornisce l’Access Token al Resource Server (che dovrà validarlo con l’Authorization Server) per accedere alla risorsa protetta.

Un Access Token ha una naturale scadenza, per mantenere l’accesso alla risorsa il Client deve periodicamente usare un Refresh Token per ottenere un valido Access Token.
Oauth 2.0 è molto usato anche per l’autorizzazione all’accesso di API che possono essere consumate con l’identità di un utente, in generale è diventato velocemente uno standard di fatto nel mondo delle applicazioni web.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *