Inizierò dicendo che le tecnologie relative all'identità odierne possono creare molta confusione. Esistono numerosi servizi (nell'era del cloud tutto è un servizio), protocolli, soluzioni, SDK, tecnologie e prodotti volti a risolvere il problema dell'identità.

Inizierò confrontando i due servizi di base che potrebbero creare maggiore confusione, poiché hanno lo stesso nome: il buon vecchio Active Directory Domain Services (ADDS in breve) e Windows Azure Active Directory (AAD in breve).

ADDS viene utilizzato da una vita (beh, 13 anni nel mondo dell’informatica sembrano un’eternità) per fornire servizi di autenticazione e autorizzazione (AuthN e AuthZ) all’interno del data center aziendale (l’ambiente on-premises). È piuttosto diffuso (l’87% delle aziende Fortune 1000 lo utilizza, secondo Gartner) e si è dimostrato molto affidabile nel fornire tutti i servizi richiesti. (Dichiarazione di non responsabilità: mi occupavo del supporto tecnico di questo prodotto quando lavoravo per Microsoft, quindi in un certo senso mi piace).

Ma nel panorama in continua evoluzione di oggi questo non basta più, e il motivo è: il cloud!

Se consideriamo il Data Center locale e l'ambiente Cloud, ci sono molte differenze nei protocolli e nelle soluzioni utilizzate per diversi motivi, ma i tre principali sono: Sicurezza, Privacy e Interoperabilità.

Se si considerano i protocolli utilizzati all'interno del data center locale per l'autenticazione e l'autorizzazione, si può affermare con certezza che Kerberos è il protocollo più diffuso e che, se si considera l'accesso ai dati utilizzato oggi nei data center per accedere all'archivio delle identità, direi che LDAP è il protocollo più comune, supportato da quasi tutti i fornitori di directory.

Questo è esattamente ciò che fa ADDS: Autentica gli utenti e autorizza l'accesso alle risorse utilizzando Kerberos e fornisce l'accesso all'archivio dati utilizzando il protocollo LDAP.

«Ma poi è arrivata la “cloud”» (e Facebook, che ha un legame molto concreto con essa)

Se si considera il modo in cui l'autenticazione (AuthN) e l'autorizzazione (AuthZ) vengono gestite (o non gestite) nel cloud, è abbastanza comprensibile che Kerberos non sia del tutto adeguato.

Il motivo è che, quando si utilizza Kerberos, si specificano delle chiavi che vengono utilizzate per crittografare i ticket Kerberos e che sono fornite da un’unica fonte autorevole. Ciò non è possibile in un ambiente cloud (quali chiavi useresti se volessi autenticare un account Facebook su un servizio Google? Non esiste un archivio centrale delle identità, né un fornitore centrale di chiavi!).

Quindi sono arrivati in soccorso SAML, OAuth, OpenID e molti altri. Tutte tecnologie che consentono di effettuare un accesso federato. (In pratica, come posso effettuare il single sign-on da Facebook a Google senza dover inserire le mie credenziali due volte). Ognuna di esse ha le proprie specifiche, ma l'obiettivo principale è quello di consentire l'autenticazione tra diversi servizi da parte di diversi fornitori di servizi/cloud (ho già parlato di interoperabilità?).

Se consideriamo il livello di accesso ai dati, vale lo stesso ragionamento. Sebbene LDAP possa funzionare, esiste una soluzione più sensata per gestire le relazioni tra le persone (che si tratti di utenti aziendali o di consumatori con foto profilo e bacheche): il Graph!

L'utilizzo di Graph come archivio dati (in particolare come archivio delle identità) è perfettamente sensato, poiché non è gerarchico come LDAP e può effettivamente mostrare le "connessioni" tra gli utenti e le risorse all'interno dell'organizzazione, consentendo di gestire realmente un'identità, anziché un'intera gerarchia utilizzata per organizzare le identità in "cartelle" in base a ciò che l'organizzazione ha ritenuto più opportuno.

È qui che entra in gioco Azure Active Directory. AAD è un IDaaS (Identity as a Service) basato sul cloud e fornito da Microsoft che utilizza standard aperti (ad esempio SAML) per autenticare gli utenti e consentire la federazione delle identità tra i servizi cloud, nonché il modello di dati Graph per interrogare e gestire gli oggetti.

Ecco una breve tabella di confronto tra i due:

Azure Active Directory Servizi di dominio Active Directory
Fornisce SSO e repository degli utenti per i servizi cloud. Fornisce SSO e gestione delle identità per i servizi on premise.
Fornire una piattaforma estensibile per la gestione dei ruoli diterzi Non offre la possibilità di gestire i ruoli nei servizi cloud diterze parti
Fornisce una piattaforma di identità cloud multi-tenant Si affida a una piattaforma on premise a singolo inquilino
Utilizzo degli standard di settore per l'autenticazione nel cloud Utilizzo degli standard di settore per l'autenticazione on premise
Utilizza Graph API per l'accesso ai dati Utilizza il protocollo LDAP per l'accesso ai dati

In conclusione, ADDS ci fornisce la possibilità di accedere alla nostra rete aziendale, di accedere alle risorse che si trovano nella rete aziendale e permette ai servizi di interrogare le informazioni sugli oggetti come utenti, gruppi e risorse.

L'AAD consente di accedere ai nostri servizi cloud, di accedere alle risorse situate nel cloud e di interrogare le informazioni sugli oggetti da parte dei servizi cloud.

Spero che la comprensione delle due cose abbia senso.

Nel prossimo post cercherò di spiegare come i due possano essere interconnessi per creare un'identità "ibrida" (che consenta di utilizzare lo stesso account sia per le risorse on-premise che per i servizi cloud).