Panoramica dell'architettura di ID verificato di Microsoft Entra
È importante pianificare la soluzione di credenziali verificabili in modo che, oltre a emettere e o convalidare le credenziali, si abbia una visione completa degli impatti dell'architettura e dell'azienda della soluzione. Se non sono già state esaminate, è consigliabile consultare Introduzione a ID verificato di Microsoft Entra e domande frequenti e quindi completare l'esercitazione introduttiva.
Questa panoramica dell'architettura presenta le funzionalità e i componenti del servizio ID verificato di Microsoft Entra. Per informazioni più dettagliate sul rilascio e la convalida, vedere
Approcci all'identità
Oggi la maggior parte delle organizzazioni usa sistemi di identità centralizzati per fornire le credenziali ai dipendenti. Usano anche vari metodi per portare clienti, partner, fornitori e relying party nei limiti di attendibilità dell'organizzazione. Questi metodi includono la federazione, la creazione e la gestione di account guest con sistemi come Microsoft Entra B2B e la creazione di attendibilità esplicite con relying party. La maggior parte delle relazioni commerciali ha un componente digitale, quindi l'abilitazione di una qualche forma di attendibilità tra le organizzazioni richiede un impegno significativo.
Sistemi di gestione delle identità centralizzati
Gli approcci centralizzati funzionano ancora in molti casi, ad esempio quando le applicazioni, i servizi e i dispositivi si basano sui meccanismi di attendibilità usati all'interno di un dominio o di un limite di attendibilità.
Nei sistemi di identità centralizzati, il provider di identità (IDP) controlla il ciclo di vita e l'utilizzo delle credenziali.
Tuttavia, esistono scenari in cui l'uso di un'architettura decentralizzata con credenziali verificabili può fornire valore aumentando gli scenari chiave, ad esempio
onboarding sicuro delle identità dei dipendenti e degli altri, inclusi scenari remoti.
accesso alle risorse all'interno del limite di attendibilità dell'organizzazione in base a criteri specifici.
accesso alle risorse al di fuori del limite di attendibilità, ad esempio l'accesso alle risorse dei partner, con credenziali portabili rilasciate dall'organizzazione.
Sistemi di identità decentralizzati
Nei sistemi di identità decentralizzati, il controllo del ciclo di vita e dell'utilizzo delle credenziali viene condiviso tra l'emittente, il titolare e la relying party che utilizza le credenziali.
Si consideri lo scenario nel diagramma in cui Proseware, un sito Web di e-commerce, vuole offrire sconti aziendali per i dipendenti di Woodgrove.
La terminologia per le credenziali verificabili potrebbe generare confusione se non si ha familiarità con le macchine virtuali. Le definizioni seguenti provengono dalla sezione Terminologia del modello di dati delle credenziali verificabile 1.0 . Dopo ognuno di essi, vengono correlati alle entità nel diagramma precedente.
"Un'autorità emittente è un ruolo che un'entità può eseguire asserendo attestazioni su uno o più soggetti, creando credenziali verificabili da queste attestazioni e trasmettendo le credenziali verificabili a un titolare".
- Nel diagramma precedente, Woodgrove è l'autorità di certificazione delle credenziali verificabili per i dipendenti.
"Un titolare è un ruolo che un'entità può eseguire possedere una o più credenziali verificabili e generare presentazioni da essi. Un titolare è in genere, ma non sempre, un oggetto delle credenziali verificabili che mantengono. I titolari archiviano le credenziali nei repository delle credenziali."
- Nel diagramma precedente Alice è un dipendente di Woodgrove. Hanno ottenuto una credenziale verificabile dall'emittente di Woodgrove ed è il titolare di tale credenziale.
"Un verificatore è un ruolo eseguito da un'entità ricevendo una o più credenziali verificabili, facoltativamente all'interno di una presentazione verificabile per l'elaborazione. Altre specifiche potrebbero fare riferimento a questo concetto come relying party".
- Nel diagramma precedente Proseware è un verificatore di credenziali rilasciate da Woodgrove.
"Una credenziale è un set di una o più attestazioni effettuate da un'autorità emittente. Una credenziale verificabile è una credenziale evidente manomissione che può essere verificata crittograficamente. Le credenziali verificabili possono essere usate per creare presentazioni verificabili, che possono anche essere verificate crittograficamente. Le attestazioni in una credenziale possono riguardare soggetti diversi".
"Un identificatore decentralizzato è un identificatore portatile basato su URI, noto anche come DID, associato a un'entità. Questi identificatori vengono spesso usati in una credenziale verificabile e sono associati a soggetti, emittenti e verificatori".
"Un documento identificatore decentralizzato, detto anche documento DID, è un documento accessibile usando un registro dei dati verificabile e contiene informazioni correlate a un identificatore decentralizzato specifico, ad esempio il repository associato e le informazioni sulla chiave pubblica."
Nello scenario, sia l'autorità emittente che il verificatore hanno un'operazione DID e un documento DID. Il documento DID contiene la chiave pubblica e l'elenco dei domini Web DNS associati a DID (noti anche come domini collegati).
Woodgrove (autorità di certificazione) firma i VC dei dipendenti con la propria chiave privata; Analogamente, Proseware (verifier) firma le richieste di presentare un vc usando la relativa chiave, che è associata anche al relativo DID.
Un sistema di trust è la base per stabilire una relazione di trust tra sistemi decentralizzati. Può essere un libro mastro distribuito o può essere qualcosa di centralizzato, ad esempio DID Web.
"Un libro mastro distribuito è un sistema non decentralizzato per la registrazione degli eventi. Questi sistemi stabiliscono una confidenza sufficiente per i partecipanti a basarsi sui dati registrati da altri utenti per prendere decisioni operative. In genere usano database distribuiti in cui nodi diversi usano un protocollo di consenso per confermare l'ordinamento delle transazioni con firma crittografica. Il collegamento di transazioni firmate digitalmente nel tempo spesso rende immutabile la storia del libro mastro".
Combinazione di architetture di identità centralizzate e decentralizzate
Quando si esamina una soluzione di credenziali verificabile, è utile comprendere in che modo le architetture di identità decentralizzate possono essere combinate con architetture di identità centralizzate per offrire una soluzione che riduce i rischi e offre vantaggi operativi significativi.
Percorso utente
Questa panoramica dell'architettura segue il percorso di un candidato al lavoro e di un dipendente, che si applica e accetta l'impiego con un'organizzazione. Segue quindi i dipendenti e l'organizzazione attraverso le modifiche in cui le credenziali verificabili possono aumentare i processi centralizzati.
Attori in questi casi d'uso
Alice, una persona che si candida e accetta l'impiego con Woodgrove, Inc.
Woodgrove, Inc, una società fittizia.
Adatum, partner fittizio di verifica dell'identità di Woodgrove.
Proseware, organizzazione partner fittizia di Woodgrove.
Woodgrove usa architetture di identità centralizzate e decentralizzate.
Passaggi nel percorso utente
Alice si candida a una posizione con Woodgrove, Inc.
Accesso alle risorse digitali entro il limite di attendibilità di Woodgrove.
Accesso alle risorse digitali al di fuori del limite di attendibilità di Woodgrove senza estendere i limiti di trust di Woodgrove o dei partner.
Mentre Woodgrove continua a operare, deve gestire continuamente le identità. I casi d'uso in questa guida descrivono come Alice può usare funzioni self-service per ottenere e gestire i relativi identificatori e come Woodgrove può aggiungere, modificare e relazioni business-to-business end con requisiti di attendibilità diversi.
Questi casi d'uso illustrano come combinare identità centralizzate e identità decentralizzate per fornire una strategia di identità e un ciclo di vita più affidabili ed efficienti.
Percorso utente: onboarding in Woodgrove
Consapevolezza: Alice è interessata a lavorare per Woodgrove, Inc. e visita il sito Web della carriera di Woodgrove.
Attivazione: il sito Woodgrove presenta Alice con un metodo per dimostrare la propria identità richiedendo loro un codice a matrice o un collegamento diretto per visitare il partner di verifica dell'identità attendibile, Adatum.
Richiesta e caricamento: Adatum richiede la prova dell'identità da Alice. Alice prende un selfie e un'immagine della patente di guida e li carica in Adatum.
Rilascio: dopo che Adatum verifica l'identità di Alice, Adatum rilascia a Alice una credenziale verificabile (VC) che attesta la propria identità.
Presentazione: Alice (titolare e soggetto delle credenziali) può quindi accedere al portale di carriera di Woodgrove per completare il processo dell'applicazione. Quando Alice usa vc per accedere al portale, Woodgrove assume i ruoli del verificatore e della relying party, considera attendibile l'attestazione da Adatum.
Distribuzione delle credenziali iniziali
Alice accetta un impiego con Woodgrove. Come parte del processo di onboarding, viene creato un account Microsoft Entra per consentire ad Alice di usare all'interno del limite di attendibilità di Woodgrove. Il manager di Alice deve capire come abilitare Alice, chi lavora in remoto, per ricevere informazioni di accesso iniziali in modo sicuro. In passato, il reparto IT potrebbe aver fornito tali credenziali al proprio responsabile, che li stampava e li consegnava ad Alice. La stampa delle credenziali non funziona con i dipendenti remoti.
Le macchine virtuali possono aggiungere valore ai sistemi centralizzati aumentando il processo di distribuzione delle credenziali. Invece di richiedere al manager di fornire le credenziali, Alice può usare il proprio vc come prova di identità per ricevere il nome utente iniziale e le credenziali per l'accesso centralizzato ai sistemi. Alice presenta la prova di identità aggiunta al portafoglio come parte del processo di onboarding.
Nel caso d'uso dell'onboarding, i ruoli della relazione di trust vengono distribuiti tra l'autorità emittente, il verificatore e il titolare.
L'autorità emittente è responsabile della convalida delle attestazioni che fanno parte del vc che rilasciano. Adatum convalida l'identità di Alice per emettere il vco. In questo caso, le macchine virtuali vengono rilasciate senza considerare un verificatore o una relying party.
Il titolare possiede il VC e avvia la presentazione del VC per la verifica. Solo Alice può presentare le schede virtuali che contiene.
Il verificatore accetta le attestazioni nel vc dalle autorità emittenti che considerano attendibili e convalidano il vc usando la funzionalità di contabilità mastro decentralizzata descritta nel modello di dati delle credenziali verificabili. Woodgrove si fida delle affermazioni di Adatum sull'identità di Alice.
Combinando architetture di identità centralizzate e decentralizzate per l'onboarding, le informazioni con privilegi su Alice necessarie per la verifica dell'identità, ad esempio un numero ID per enti pubblici, non devono essere archiviate da Woodgrove, perché considerano attendibile che il vc di Alice rilasciato dal partner di verifica dell'identità (Adatum) conferma la propria identità. La duplicazione dello sforzo è ridotta al minimo e può essere implementato un approccio programmatico e prevedibile alle attività di onboarding iniziali.
Percorso utente: accesso alle risorse all'interno del limite di attendibilità
In qualità di dipendente, Alice opera all'interno del confine di trust di Woodgrove. Woodgrove funge da provider di identità (IDP) e mantiene il controllo completo dell'identità e la configurazione delle app che Alice usa per interagire all'interno del limite di attendibilità di Woodgrove. Per usare le risorse nel limite di attendibilità di Microsoft Entra ID, Alice offre potenzialmente più forme di prova di identificazione per accedere al limite di attendibilità di Woodgrove e accedere alle risorse all'interno dell'ambiente tecnologico di Woodgrove. Più prove è uno scenario tipico che è ben servito usando un'architettura centralizzata di identità.
Woodgrove gestisce il limite di attendibilità e usa le procedure di sicurezza consigliate fornisce il livello di accesso con privilegi minimi ad Alice in base al processo eseguito. Per mantenere un comportamento di sicurezza forte e potenzialmente per motivi di conformità, Woodgrove deve anche essere in grado di tenere traccia delle autorizzazioni e dell'accesso alle risorse dei dipendenti e deve essere in grado di revocare le autorizzazioni al termine dell'impiego.
Alice usa solo le credenziali gestite da Woodgrove per accedere alle risorse di Woodgrove. Alice non ha bisogno di tenere traccia quando vengono usate le credenziali poiché Woodgrove gestisce le credenziali e che viene usato solo con le risorse Woodgrove. L'identità è valida solo all'interno del limite di attendibilità di Woodgrove quando è necessario l'accesso alle risorse di Woodgrove, quindi Alice non deve possedere le credenziali.
Uso di controller di rete all'interno del limite di attendibilità
I singoli dipendenti hanno esigenze di identità mutevoli e i controller di rete possono aumentare i sistemi centralizzati per gestire tali modifiche.
Anche se impiegato da Woodgrove Alice potrebbe avere bisogno di ottenere l'accesso alle risorse in base a requisiti specifici. Ad esempio, quando Alice completa la formazione sulla privacy, può essere rilasciato un nuovo impiegato VC con tale attestazione e che VC può essere usato per accedere a risorse limitate.
Le schede virtuali possono essere usate all'interno del limite di attendibilità per il ripristino dell'account. Ad esempio, se il dipendente ha perso il telefono e il computer, può ottenere nuovamente l'accesso ottenendo un nuovo vc dal servizio di verifica delle identità, considerato attendibile da Woodgrove e quindi usare tale vc per ottenere nuove credenziali.
Percorso utente: accesso alle risorse esterne
Woodgrove negozia uno sconto per l'acquisto di prodotti con Proseware. Tutti i dipendenti di Woodgrove sono idonei allo sconto. Woodgrove vuole fornire ad Alice un modo per accedere al sito Web di Proseware e ricevere lo sconto sui prodotti acquistati. Se Woodgrove usa un'architettura centralizzata per le identità, esistono due approcci per fornire a Alice lo sconto:
Alice potrebbe fornire informazioni personali per creare un account con Proseware e quindi Proseware dovrà verificare l'impiego di Alice con Woodgrove.
Woodgrove potrebbe espandere il limite di attendibilità per includere Proseware come relying party e Alice potrebbe usare il limite di attendibilità esteso per ricevere lo sconto.
Con gli identificatori decentralizzati, Woodgrove può fornire ad Alice una credenziale verificabile (VC) che Alice può usare per accedere al sito Web di Proseware e ad altre risorse esterne.
Fornendo Alice al VC, Woodgrove attesta che Alice è un dipendente. Woodgrove è un'autorità di certificazione VC attendibile nella soluzione di convalida di Proseware. Questa fiducia nel processo di rilascio di Woodgrove consente a Proseware di accettare elettronicamente il VC come prova che Alice è un dipendente di Woodgrove e fornire alice lo sconto. Come parte della convalida di VC Alice presenta, Proseware controlla la validità del vc usando il sistema di attendibilità. In questa soluzione:
Woodgrove consente ad Alice di fornire la prova proseware dell'impiego senza che Woodgrove abbia la necessità di estendere il limite di fiducia.
Proseware non deve espandere il limite di attendibilità per verificare che Alice sia un dipendente di Woodgrove. Proseware può usare invece il vc fornito da Woodgrove. Poiché il limite di attendibilità non viene espanso, la gestione della relazione di trust è più semplice e Proseware può facilmente terminare la relazione non accettando più le schede virtuali.
Alice non deve fornire informazioni personali di Proseware, ad esempio un messaggio di posta elettronica. Alice mantiene il VC in un'applicazione portafoglio su un dispositivo personale. L'unica persona che può usare vc è Alice e Alice deve avviare l'utilizzo delle credenziali. Ogni utilizzo del VC viene registrato dall'applicazione portafoglio, quindi Alice ha un record di quando e dove viene usato vc.
Combinando architetture di identità centralizzate e decentralizzate per operare all'interno e all'esterno dei confini di trust a Woodgrove, la complessità e il rischio possono essere ridotti e le relazioni limitate diventano più facili da gestire.
Modifiche nel tempo
Woodgrove aggiunge nuove e termina le relazioni commerciali correnti con altre organizzazioni e deve determinare quando vengono usate architetture di identità centralizzate e decentralizzate.
Combinando architetture di identità centralizzate e decentralizzate, la responsabilità e l'impegno associati all'identità e alla prova dell'identità vengono distribuiti e il rischio viene ridotto. L'utente non rischia di rilasciare le informazioni private con la frequenza o il numero di verificatori sconosciuti. In particolare:
- Nelle architetture di identità centralizzate, il provider di identità rilascia le credenziali ed esegue la verifica di tali credenziali rilasciate. Il provider di identità elabora le informazioni su tutte le identità. Li archivia in una directory o li recupera da una directory. Facoltativamente, gli IDP possono accettare token di sicurezza da altri sistemi IDP, ad esempio accessi di social networking o partner aziendali. Affinché una relying party usi le identità nel limite di attendibilità IDP, deve essere configurata per accettare i token emessi dal provider di identità.
Funzionamento dei sistemi di gestione delle identità decentralizzati
Nelle architetture di identità decentralizzate, l'autorità emittente, l'utente e la relying party (RP) hanno un ruolo nella definizione e nella garanzia di uno scambio attendibile continuo delle credenziali dell'altro. Le chiavi pubbliche degli ID degli attori sono risolvibili tramite il sistema di attendibilità, che consente la convalida della firma e quindi l'attendibilità di qualsiasi artefatto, inclusa una credenziale verificabile. Le relying party possono utilizzare credenziali verificabili senza stabilire relazioni di attendibilità con l'autorità emittente. L'emittente fornisce invece al soggetto credenziali da presentare come prova alle relying party. Tutti i messaggi tra attori vengono firmati con il DID dell'attore. I DID provenienti da autorità emittenti e verificatori devono anche possedere i domini DNS che hanno generato le richieste.
Ad esempio: Quando i titolari delle credenziali verificabili (VC) devono accedere a una risorsa, devono presentare le VC a tale relying party. A tale scopo, usano un'applicazione portafoglio per leggere la richiesta dell'RP per presentare le VC. Nell'ambito della lettura della richiesta, l'applicazione portafoglio usa il DID dell'RP per trovare le chiavi pubbliche dell'RP usando il sistema di attendibilità, verificando che la richiesta di presentare le VC non sia stata manomessa. Per dimostrare la proprietà del dominio, il portafoglio verifica anche che venga fatto riferimento al DID in un documento di metadati ospitato nel dominio DNS dell'RP.
Flusso 1: rilascio di credenziali verificabili
In questo flusso, il titolare delle credenziali interagisce con l'autorità emittente per richiedere credenziali verificabili, come illustrato nel diagramma seguente
Il titolare avvia il flusso usando un browser o un'applicazione nativa per accedere al front-end Web dell'autorità emittente. In questo caso, il sito Web dell'autorità emittente guida l'utente a raccogliere i dati ed esegue la logica specifica dell'autorità di certificazione per determinare se è possibile emettere le credenziali e il relativo contenuto.
Il front-end Web dell'autorità di certificazione chiama il servizio ID verificato di Microsoft Entra per generare una richiesta di rilascio di VC.
Il front-end Web esegue il rendering di un collegamento alla richiesta come codice a matrice o come collegamento diretto specifico del dispositivo (a seconda del dispositivo).
Il titolare analizza il codice a matrice o il collegamento diretto dal passaggio 3 usando un'app portafoglio come Microsoft Authenticator
Il portafoglio scarica la richiesta dal collegamento. La richiesta include:
DID dell'emittente. Il DID dell'autorità emittente viene usato dall'app portafoglio per risolvere tramite il sistema di attendibilità la ricerca di chiavi pubbliche e domini collegati.
URL con il manifesto di VC, che specifica i requisiti del contratto per rilasciare le VC. Il requisito del contratto può includere id_token, attributi autocertificati che devono essere forniti o la presentazione di altre VC.
Aspetto delle VC (URL del file logo, colori e così via).
Il portafoglio convalida le richieste di rilascio ed elabora i requisiti del contratto:
Verifica che il messaggio di richiesta di rilascio sia firmato dalle chiavi dell'autorità emittente trovate nel documento DID risolto tramite il sistema di attendibilità. La convalida della firma garantisce che il messaggio non sia stato manomesso.
Verifica che l'autorità emittente sia proprietaria del dominio DNS a cui viene fatto riferimento nel documento DID dell'autorità emittente.
A seconda dei requisiti del contratto delle VC, il portafoglio potrebbe richiedere al titolare di raccogliere informazioni aggiuntive, come attributi autocertificati o il suo spostamento in un flusso OIDC per ottenere un id_token.
Invia gli artefatti richiesti dal contratto al servizio ID verificato di Microsoft Entra. Il servizio ID verificato di Microsoft Entra restituisce il VC, firmato con la chiave DID dell'autorità emittente e il portafoglio archivia in modo sicuro le VC.
Per informazioni dettagliate su come creare una soluzione di rilascio e considerazioni sull'architettura, vedere Pianificare la soluzione di rilascio ID verificato di Microsoft Entra.
Flusso 2: presentazione delle credenziali verificabili
In questo flusso, un titolare interagisce con una relying party (RP) per presentare VC come parte dei requisiti di autorizzazione.
Il titolare avvia il flusso usando un browser o un'applicazione nativa per accedere al front-end Web della relying party.
Il front-end Web chiama il servizio ID verificato di Microsoft Entra per generare una richiesta di presentazione di VC.
Il front-end Web esegue il rendering di un collegamento alla richiesta come codice a matrice o come collegamento diretto specifico del dispositivo (a seconda del dispositivo).
Il titolare analizza il codice a matrice o il collegamento diretto dal passaggio 3 usando un'app portafoglio come Microsoft Authenticator
Il portafoglio scarica la richiesta dal collegamento. La richiesta include:
una richiesta basata su standard per le credenziali di uno schema o di un tipo di credenziale.
il DID del RP, che il portafoglio cerca nel sistema di fiducia.
Il portafoglio convalida la richiesta di presentazione e trova le VC archiviate che soddisfano la richiesta. In base alle VC richieste, il portafoglio guida il soggetto alla selezione e al consenso per l'uso delle VC.
- L'oggetto acconsente a condividere il vc con il punto di ripristino
Quindi, il portafoglio invia un payload di risposta di presentazione al servizio ID verificato di Microsoft Entra firmato dal soggetto. Contiene:
Le VC a cui ha acconsentito il soggetto.
Oggetto DID.
Rp DID come "gruppo di destinatari" del payload.
Il servizio ID verificato di Microsoft Entra convalida la risposta inviata dal portafoglio. In alcuni casi, l'autorità di certificazione di VC può revocare le VC. Per assicurarsi che le VC siano ancora valide, il verificatore deve verificare con l'autorità di certificazione delle VC. Questo dipende dal modo in cui il verificatore ha richiesto le VC nel passaggio 2.
Al termine della convalida, il servizio ID verificato di Microsoft Entra comunica il risultato all'RP.
Per informazioni dettagliate su come creare una soluzione di convalida e considerazioni sull'architettura, vedere Pianificare la soluzione di verifica ID verificato di Microsoft Entra.
Risultati principali
Le architetture decentralizzate possono essere usate per migliorare le soluzioni esistenti e fornire nuove funzionalità.
Per realizzare le aspirazioni degli obiettivi DIF (Centraled Identity Foundation) e W3C Design, è necessario considerare gli elementi seguenti quando si crea una soluzione di credenziali verificabile:
Non ci sono punti centrali per stabilire l'attendibilità tra gli attori nel sistema. Ovvero, i limiti di attendibilità non vengono espansi nella federazione perché gli attori considerano attendibili specifiche VC.
- Il sistema di attendibilità consente l'individuazione dell'identificatore decentralizzato (DID) di qualsiasi attore.
La soluzione consente ai verificatori di convalidare tutte le credenziali verificabili (VC) da qualsiasi autorità emittente.
La soluzione non consente all'autorità emittente di controllare l'autorizzazione del soggetto o del verificatore (relying party).
Gli attori operano in modo disaccoppiato, ognuno è in grado di completare le attività per i propri ruoli.
Le autorità emittenti si occupano di ogni richiesta di VC e non discriminano le richieste gestite.
I soggetti possiedono la propria VC una volta rilasciata e possono presentare la VC a qualsiasi verificatore.
I verificatori possono convalidare le VC di qualsiasi soggetto o autorità emittente.
Passaggi successivi
Altre informazioni sull'architettura per le credenziali verificabili
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per