Inizierò dicendo che le tecnologie di identità di oggi possono essere molto confuse. Esistono molti servizi (nell'era del cloud tutto è un servizio), protocolli, soluzioni, SDK, tecnologie e prodotti che mirano a risolvere il problema dell'identità.

Inizierò con un confronto tra i due sistemi di base, che potrebbero essere i più confusi in quanto condividono lo stesso nome: il buon vecchio Active Directory Domain Services (ADDS in breve) e Windows Azure Active Directory (AAD in breve).

ADDS è utilizzato da sempre (beh, 13 anni di computer sembrano secoli) per fornire servizi di autenticazione e autorizzazione (AuthN e AuthZ) all'interno del Data Center aziendale (l'ambiente on-premises). È piuttosto popolare (l'87% di Fortune 1000 lo usa, secondo Gartner) e si è dimostrato piuttosto solido nel fornire tutti i servizi richiesti. (Disclaimer: ho lavorato per MSFT e quindi mi piace il prodotto).

Ma nell'attuale panorama in continua evoluzione non è più sufficiente e il motivo è: Ze 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 è arrivato il cloud" (e Facebook, che ha un legame molto tangibile).

Osservando come AuthN e AuthZ vengono gestiti (o non gestiti) nel cloud, è abbastanza comprensibile che Kerberos non sia abbastanza buono.

Il motivo è che quando si usa Kerberos si specificano le chiavi utilizzate per crittografare i ticket Kerberos e fornite da un'unica fonte autorevole. Questo non è possibile nell'ambiente cloud (quali chiavi utilizzereste se voleste autenticare un account Facebook a un servizio Google? Non c'è un archivio centrale di identità e non c'è 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à?).

Per quanto riguarda il livello di accesso ai dati, vale lo stesso discorso. Anche se LDAP potrebbe funzionare, c'è qualcosa che ha più senso quando si tratta di gestire le connessioni tra le persone (che siano utenti organizzativi o consumatori con foto profilo e pareti), ovvero Graph!

L'uso di Graph per l'archivio dei dati (in particolare per l'archivio delle identità) ha perfettamente senso, perché non è gerarchico come LDAP e può effettivamente mostrare le "connessioni" tra gli utenti e le risorse dell'organizzazione, consentendo di gestire effettivamente un'identità, piuttosto che un'intera gerarchia utilizzata per organizzare le identità in "cartelle" basate su ciò che l'organizzazione ha deciso che ha senso per loro.

È 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 dei 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 le due cose possano essere interconnesse per ottenere un'identità "ibrida" (che permetta di utilizzare lo stesso account sia per le risorse on premise che per i servizi cloud).