översikt över Microsoft Entra – verifierat ID arkitektur
Det är viktigt att planera din verifierbara lösning för autentiseringsuppgifter så att du, förutom att utfärda och eller verifiera autentiseringsuppgifter, har en fullständig vy över arkitektur- och affärseffekterna av din lösning. Om du inte redan har granskat dem rekommenderar vi att du läser Introduktion till Microsoft Entra – verifierat ID och vanliga frågor och svar och slutför sedan självstudien Komma igång.
Den här arkitekturöversikten beskriver funktionerna och komponenterna i Microsoft Entra – verifierat ID-tjänsten. Mer detaljerad information om utfärdande och validering finns i
Metoder för identitet
Idag använder de flesta organisationer centraliserade identitetssystem för att ge anställda autentiseringsuppgifter. De använder också olika metoder för att föra in kunder, partner, leverantörer och förlitande parter i organisationens förtroendegränser. Dessa metoder omfattar federation, skapande och hantering av gästkonton med system som Microsoft Entra B2B och att skapa explicita förtroenden med förlitande parter. De flesta affärsrelationer har en digital komponent, så att aktivera någon form av förtroende mellan organisationer kräver betydande arbete.
Centraliserade identitetssystem
Centraliserade metoder fungerar fortfarande bra i många fall, till exempel när program, tjänster och enheter förlitar sig på de förtroendemekanismer som används inom en domän eller förtroendegräns.
I centraliserade identitetssystem styr identitetsprovidern (IDP) livscykeln och användningen av autentiseringsuppgifter.
Det finns dock scenarier där användning av en decentraliserad arkitektur med verifierbara autentiseringsuppgifter kan ge värde genom att utöka viktiga scenarier som
säker registrering av anställdas och andras identiteter, inklusive fjärrscenarier.
åtkomst till resurser inom organisationens förtroendegräns baserat på specifika kriterier.
åtkomst till resurser utanför förtroendegränsen, till exempel åtkomst till partnerresurser, med en portabel autentiseringsuppgift utfärdad av organisationen.
Decentraliserade identitetssystem
I decentraliserade identitetssystem delas kontrollen över livscykeln och användningen av autentiseringsuppgifterna mellan utfärdaren, innehavaren och den förlitande parten som använder autentiseringsuppgifterna.
Tänk på scenariot i diagrammet där Proseware, en e-handelswebbplats, vill erbjuda Woodgrove-anställda företagsrabatter.
Terminologi för verifierbara autentiseringsuppgifter (VCs) kan vara förvirrande om du inte är bekant med virtuella datorer. Följande definitioner kommer från terminologiavsnittet Verifierbara autentiseringsuppgifter datamodell 1.0 . Efter var och en relaterar vi dem till entiteter i föregående diagram.
"En utfärdare är en roll som en entitet kan utföra genom att hävda anspråk om ett eller flera ämnen, skapa en verifierbar autentiseringsuppgift från dessa anspråk och överföra de verifierbara autentiseringsuppgifterna till en innehavare."
- I föregående diagram är Woodgrove utfärdare av verifierbara autentiseringsuppgifter till sina anställda.
"En innehavare är en roll som en entitet kan utföra genom att ha en eller flera verifierbara autentiseringsuppgifter och generera presentationer från dem. En innehavare är vanligtvis, men inte alltid, föremål för de verifierbara autentiseringsuppgifter som de innehar. Innehavare lagrar sina autentiseringsuppgifter i lagringsplatser för autentiseringsuppgifter."
- I föregående diagram är Alice en Woodgrove-anställd. De fick en verifierbar autentiseringsuppgift från Woodgrove-utfärdaren och är innehavare av den autentiseringsuppgiften.
"En kontrollant är en roll som en entitet utför genom att ta emot en eller flera verifierbara autentiseringsuppgifter, eventuellt i en verifierbar presentation för bearbetning. Andra specifikationer kan referera till det här begreppet som en förlitande part."
- I föregående diagram är Proseware en kontrollant av autentiseringsuppgifter som utfärdats av Woodgrove.
"En autentiseringsuppgift är en uppsättning av ett eller flera anspråk som görs av en utfärdare. En verifierbar autentiseringsuppgift är en manipuleringssäker autentiseringsuppgift som har redigering som kan verifieras kryptografiskt. Verifierbara autentiseringsuppgifter kan användas för att skapa verifierbara presentationer, som också kan verifieras kryptografiskt. Anspråken i en autentiseringsuppgift kan handla om olika ämnen."
"En decentraliserad identifierare är en portabel URI-baserad identifierare, även kallad DID, som är associerad med en entitet. Dessa identifierare används ofta i en verifierbar autentiseringsuppgift och är associerade med ämnen, utfärdare och verifierare."
"Ett decentraliserat ID-dokument, även kallat ett DID-dokument, är ett dokument som är tillgängligt med hjälp av ett verifierbart dataregister och som innehåller information som rör en specifik decentraliserad identifierare, till exempel den associerade lagringsplatsen och information om offentlig nyckel."
I scenariot har både utfärdaren och verifieraren ett DID och ett DID-dokument. DID-dokumentet innehåller den offentliga nyckeln och listan över DNS-webbdomäner som är associerade med DID (kallas även länkade domäner).
Woodgrove (utfärdare) signerar sina anställdas virtuella datorer med sin privata nyckel; På samma sätt signerar Proseware (verifierare) begäranden om att presentera en VC med hjälp av dess nyckel, som också är associerad med dess DID.
Ett förtroendesystem är grunden för att upprätta förtroende mellan decentraliserade system. Det kan vara ett distribuerat transaktionsregister eller något centraliserat, till exempel DID Web.
"Ett distribuerat transaktionsregister är ett icke-decentraliserat system för inspelning av händelser. Dessa system ger deltagarna tillräckligt förtroende för att förlita sig på de data som registrerats av andra för att fatta operativa beslut. De använder vanligtvis distribuerade databaser där olika noder använder ett konsensusprotokoll för att bekräfta ordningen på kryptografiskt signerade transaktioner. Länkningen av digitalt signerade transaktioner över tid gör ofta historiken för transaktionsregistret effektivt oföränderlig."
Kombinera centraliserade och decentraliserade identitetsarkitekturer
När du undersöker en verifierbar lösning för autentiseringsuppgifter är det bra att förstå hur decentraliserade identitetsarkitekturer kan kombineras med centraliserade identitetsarkitekturer för att tillhandahålla en lösning som minskar risken och ger betydande driftfördelar.
Användarens resa
Den här arkitekturöversikten följer en jobbkandidats och medarbetares resa, som ansöker om och accepterar anställning hos en organisation. Den följer sedan medarbetaren och organisationen genom ändringar där verifierbara autentiseringsuppgifter kan utöka centraliserade processer.
Aktörer i dessa användningsfall
Alice, en person som ansöker om och accepterar anställning hos Woodgrove, Inc.
Woodgrove, Inc, ett fiktivt företag.
Adatum, Woodgroves fiktiva identitetsverifieringspartner.
Proseware, Woodgroves fiktiva partnerorganisation.
Woodgrove använder både centraliserade och decentraliserade identitetsarkitekturer.
Steg i användarresan
Alice ansöker om, accepterar och registrerar sig för en tjänst hos Woodgrove, Inc.
Åtkomst till digitala resurser inom Woodgroves förtroendegräns.
Åtkomst till digitala resurser utanför Woodgroves förtroendegräns utan att utöka Woodgrove eller partnerns förtroendegränser.
Eftersom Woodgrove fortsätter att driva sin verksamhet måste det kontinuerligt hantera identiteter. Användningsfallen i den här vägledningen beskriver hur Alice kan använda självbetjäningsfunktioner för att hämta och underhålla sina identifierare och hur Woodgrove kan lägga till, ändra och avsluta affärs-till-företag-relationer med olika förtroendekrav.
Dessa användningsfall visar hur centraliserade identiteter och decentraliserade identiteter kan kombineras för att ge en mer robust och effektiv identitets- och förtroendestrategi och livscykel.
Användarresa: Registrering till Woodgrove
Medvetenhet: Alice är intresserad av att arbeta för Woodgrove, Inc. och besöker Woodgroves karriärwebbplats.
Aktivering: Woodgrove-webbplatsen presenterar Alice med en metod för att bevisa sin identitet genom att uppmana dem med en QR-kod eller en djuplänk för att besöka sin betrodda identitetsbevispartner, Adatum.
Begäran och uppladdning: Adatum begär identitetsbevis från Alice. Alice tar en selfie och en körkortsbild och laddar upp dem till Adatum.
Utfärdande: När Adatum verifierar Alices identitet utfärdar Adatum Alice en verifierbar autentiseringsuppgift (VC) som intygar deras identitet.
Presentation: Alice (innehavaren och ämnet för autentiseringsuppgifterna) kan sedan komma åt Woodgrove-karriärportalen för att slutföra ansökningsprocessen. När Alice använder VC för att komma åt portalen tar Woodgrove rollerna som kontrollant och förlitande part och litar på attesteringen från Adatum.
Distribuera inledande autentiseringsuppgifter
Alice accepterar anställning med Woodgrove. Som en del av registreringsprocessen skapas ett Microsoft Entra-konto som Alice kan använda i Woodgrove-förtroendegränsen. Alice chef måste ta reda på hur alice, som arbetar via fjärranslutning, kan ta emot initial inloggningsinformation på ett säkert sätt. Tidigare kan IT-avdelningen ha tillhandahållit dessa autentiseringsuppgifter till sin chef, som skulle skriva ut dem och överlämna dem till Alice. Att skriva ut autentiseringsuppgifterna fungerar inte med distansanställda.
Virtuella datorer kan lägga till värde i centraliserade system genom att utöka distributionsprocessen för autentiseringsuppgifter. I stället för att behöva chefen för att ange autentiseringsuppgifter kan Alice använda sin VC som identitetsbevis för att ta emot sitt första användarnamn och sina autentiseringsuppgifter för centraliserad systemåtkomst. Alice presenterar identitetsbeviset som de lade till i plånboken som en del av registreringsprocessen.
I registreringsanvändningsfallet distribueras förtroenderelationsrollerna mellan utfärdaren, kontrollanten och innehavaren.
Utfärdaren ansvarar för att verifiera de anspråk som ingår i den VC som de utfärdar. Adatum validerar Alices identitet för att utfärda VC. I det här fallet utfärdas virtuella datorer utan hänsyn till en kontrollant eller förlitande part.
Innehavaren har VC och initierar presentationen av VC för verifiering. Det är bara Alice som kan presentera de virtuella datorer hon har.
Verifieraren accepterar anspråken i VC från utfärdare som de litar på och verifierar VC med hjälp av den decentraliserade transaktionsregisterfunktionen som beskrivs i datamodellen för verifierbara autentiseringsuppgifter. Woodgrove litar på Adatums påståenden om Alice identitet.
Genom att kombinera centraliserade och decentraliserade identitetsarkitekturer för registrering behöver privilegierad information om Alice som krävs för identitetsverifiering, till exempel ett myndighets-ID-nummer, inte lagras av Woodgrove, eftersom de litar på att Alices VC som utfärdats av identitetsverifieringspartnern (Adatum) bekräftar deras identitet. Dubblering av arbete minimeras och en programmatisk och förutsägbar metod för inledande registreringsuppgifter kan implementeras.
Användarresa: Åtkomst till resurser inom förtroendegränsen
Som anställd arbetar Alice inom woodgroves förtroendegräns. Woodgrove fungerar som identitetsprovider (IDP) och har fullständig kontroll över identiteten och konfigurationen av de appar som Alice använder för att interagera inom Woodgrove-förtroendegränsen. Om du vill använda resurser i Microsoft Entra ID-förtroendegränsen tillhandahåller Alice potentiellt flera former av identifieringsbevis för att logga in på Woodgroves förtroendegräns och få åtkomst till resurserna i Woodgroves teknikmiljö. Flera bevis är ett typiskt scenario som hanteras väl med hjälp av en centraliserad identitetsarkitektur.
Woodgrove hanterar förtroendegränsen och med hjälp av bra säkerhetsmetoder får du den lägsta behörighetsnivån för åtkomst till Alice baserat på det jobb som utförts. För att upprätthålla en stark säkerhetsstatus, och eventuellt av efterlevnadsskäl, måste Woodgrove också kunna spåra anställdas behörigheter och åtkomst till resurser och måste kunna återkalla behörigheter när anställningen avslutas.
Alice använder bara de autentiseringsuppgifter som Woodgrove underhåller för att få åtkomst till Woodgrove-resurser. Alice behöver inte spåra när autentiseringsuppgifterna används eftersom Woodgrove hanterar autentiseringsuppgifterna och endast används med Woodgrove-resurser. Identiteten är endast giltig inuti Woodgrove-förtroendegränsen när åtkomst till Woodgrove-resurser är nödvändig, så Alice behöver inte ha autentiseringsuppgifterna.
Använda virtuella datorer inom förtroendegränsen
Enskilda anställda har föränderliga identitetsbehov och virtuella datorer kan utöka centraliserade system för att hantera dessa ändringar.
Även om Woodgrove Alice är anställd kan det behövas åtkomst till resurser baserat på att de uppfyller specifika krav. När Alice till exempel slutför sekretessutbildningen kan hon få en ny anställds VC med det anspråket och att VC kan användas för att få åtkomst till begränsade resurser.
Virtuella datorer kan användas inuti förtroendegränsen för kontoåterställning. Om den anställde till exempel har förlorat sin telefon och dator kan de återfå åtkomsten genom att hämta en ny VC från identitetsverifieringstjänsten, som är betrodd av Woodgrove, och sedan använda den VC:n för att få nya autentiseringsuppgifter.
Användarresa: Åtkomst till externa resurser
Woodgrove förhandlar om en produktköpsrabatt med Proseware. Alla Woodgrove-anställda är berättigade till rabatten. Woodgrove vill ge Alice ett sätt att komma åt Prosewares webbplats och få rabatten på köpta produkter. Om Woodgrove använder en centraliserad identitetsarkitektur finns det två sätt att ge Alice rabatten:
Alice kan tillhandahålla personlig information för att skapa ett konto med Proseware, och sedan skulle Proseware behöva verifiera Alice anställning med Woodgrove.
Woodgrove kan utöka sin förtroendegräns till att omfatta Proseware som förlitande part och Alice kan använda den utökade förtroendegränsen för att få rabatten.
Med decentraliserade identifierare kan Woodgrove ge Alice en verifierbar autentiseringsuppgift (VC) som Alice kan använda för att komma åt Prosewares webbplats och andra externa resurser.
Genom att tillhandahålla Alice VC intygar Woodgrove att Alice är anställd. Woodgrove är en betrodd VC-utfärdare i Prosewares valideringslösning. Detta förtroende för Woodgroves utfärdandeprocess gör det möjligt för Proseware att elektroniskt acceptera VC som bevis på att Alice är en Woodgrove-anställd och ge Alice rabatten. Som en del av valideringen av VC Alice presenterar kontrollerar Proseware giltigheten för VC med hjälp av förtroendesystemet. I den här lösningen:
Woodgrove gör det möjligt för Alice att tillhandahålla Proseware-anställningsbevis utan att Woodgrove behöver utöka sin förtroendegräns.
Proseware behöver inte utöka sin förtroendegräns för att verifiera att Alice är anställd i Woodgrove. Proseware kan använda den VC som Woodgrove tillhandahåller i stället. Eftersom förtroendegränsen inte utökas är det enklare att hantera förtroenderelationen, och Proseware kan enkelt avsluta relationen genom att inte acceptera de virtuella datorerna längre.
Alice behöver inte ange personlig information om Proseware, till exempel ett e-postmeddelande. Alice underhåller VC:n i ett plånboksprogram på en personlig enhet. Den enda person som kan använda VC är Alice och Alice måste initiera användningen av autentiseringsuppgifterna. Varje användning av VC registreras av plånboksprogrammet, så Alice har en post om när och var VC används.
Genom att kombinera centraliserade och decentraliserade identitetsarkitekturer för att arbeta inom och utanför förtroendegränser i Woodgrove kan komplexitet och risk minskas och begränsade relationer blir enklare att hantera.
Ändringar över tid
Woodgrove lägger till nya och avslutar aktuella affärsrelationer med andra organisationer och måste avgöra när centraliserade och decentraliserade identitetsarkitekturer används.
Genom att kombinera centraliserade och decentraliserade identitetsarkitekturer fördelas ansvaret och arbetet med identitets- och identitetsbeviset och risken sänks. Användaren riskerar inte att släppa sin privata information så ofta eller till så många okända verifierare. Specifikt:
- I centraliserade identitetsarkitekturer utfärdar IDP autentiseringsuppgifter och utför verifiering av de utfärdade autentiseringsuppgifterna. IDP bearbetar information om alla identiteter. Den lagrar dem antingen i en katalog eller hämtar dem från en katalog. Alternativt kan IDP:er acceptera säkerhetstoken från andra IDP-system, till exempel sociala inloggningar eller affärspartners. För att en förlitande part ska kunna använda identiteter i IDP-förtroendegränsen måste de konfigureras för att acceptera de token som utfärdats av IDP.
Så här fungerar decentraliserade identitetssystem
I decentraliserade identitetsarkitekturer har utfärdaren, användaren och den förlitande parten (RP) en roll i att upprätta och säkerställa ett kontinuerligt betrott utbyte av varandras autentiseringsuppgifter. De offentliga nycklarna för aktörernas DID kan matchas via förtroendesystemet, vilket möjliggör signaturverifiering och därför förtroende för alla artefakter, inklusive en verifierbar autentiseringsuppgift. Förlitande parter kan använda verifierbara autentiseringsuppgifter utan att upprätta förtroenderelationer med utfärdaren. I stället ger utfärdaren ämnet en autentiseringsuppgift som ska presenteras som bevis för förlitande parter. Alla meddelanden mellan skådespelare signeras med skådespelarens DID; DID:er från utfärdare och verifierare måste också äga DE DNS-domäner som genererade begäranden.
Till exempel: När VC-innehavare behöver komma åt en resurs måste de presentera VC för den förlitande parten. De gör det genom att använda ett plånboksprogram för att läsa RP:s begäran om att presentera en VC. Som en del av att läsa begäran använder plånboksprogrammet RP:s DID för att hitta RP:ns offentliga nycklar med hjälp av förtroendesystemet, vilket validerar att begäran om att presentera VC inte har manipulerats. För att bevisa domänägarskap kontrollerar plånboken också att DID refereras i ett metadatadokument som finns i DNS-domänen för RP.
Flöde 1: Verifierbar utfärdande av autentiseringsuppgifter
I det här flödet interagerar autentiseringsinnehavaren med utfärdaren för att begära en verifierbar autentiseringsuppgift enligt följande diagram
Innehavaren startar flödet med hjälp av en webbläsare eller ett internt program för att få åtkomst till utfärdarens webbklientdel. Där styr utfärdarens webbplats användaren att samla in data och kör utfärdarspecifik logik för att avgöra om autentiseringsuppgifterna kan utfärdas och dess innehåll.
Utfärdarwebbklienten anropar Microsoft Entra – verifierat ID-tjänsten för att generera en begäran om VC-utfärdande.
Webbklientdelen återger en länk till begäran som en QR-kod eller en enhetsspecifik djuplänk (beroende på enheten).
Innehavaren söker igenom QR-koden eller djuplänken från steg 3 med hjälp av en Plånbok-app, till exempel Microsoft Authenticator
Plånboken laddar ned begäran från länken. Begäran innehåller:
DID av utfärdaren. Utfärdarens DID används av plånboksappen för att lösa problemet via förtroendesystemet för att hitta offentliga nycklar och länkade domäner.
URL med VC-manifestet, som anger kontraktskrav för att utfärda VC. Kontraktskravet kan innehålla id_token, självattesterade attribut som måste tillhandahållas eller presentationen av en annan VC.
Look and feel of the VC (URL för logotypfilen, färger osv.).
Plånboken validerar utfärdandebegäranden och bearbetar kontraktskraven:
Verifierar att meddelandet om utfärdandebegäran signeras av utfärdarens nycklar som finns i DID-dokumentet som löstes via förtroendesystemet. Om du verifierar signaturen ser du till att meddelandet inte har manipulerats.
Verifierar att utfärdaren äger DNS-domänen som refereras i utfärdarens DID-dokument.
Beroende på kraven för VC-kontrakt kan plånboken kräva att innehavaren samlar in ytterligare information, till exempel att be om självtillde utfärdade attribut eller navigera genom ett OIDC-flöde för att få en id_token.
Skickar de artefakter som krävs av kontraktet till Microsoft Entra – verifierat ID-tjänsten. Tjänsten Microsoft Entra – verifierat ID returnerar VC:en, signerad med utfärdarens DID-nyckel och plånboken lagrar VC på ett säkert sätt.
Detaljerad information om hur du skapar en utfärdandelösning och arkitekturöverväganden finns i Planera din Microsoft Entra – verifierat ID utfärdandelösning.
Flöde 2: Verifierbar presentation av autentiseringsuppgifter
I det här flödet interagerar en innehavare med en förlitande part (RP) för att presentera en VC som en del av sina auktoriseringskrav.
Innehavaren startar flödet med hjälp av en webbläsare eller ett internt program för att få åtkomst till den förlitande partens webbklientdel.
Webbklientdelen anropar Microsoft Entra – verifierat ID-tjänsten för att generera en VC-presentationsbegäran.
Webbklientdelen återger en länk till begäran som en QR-kod eller en enhetsspecifik djuplänk (beroende på enheten).
Innehavaren söker igenom QR-koden eller djuplänken från steg 3 med hjälp av en plånboksapp som Microsoft Authenticator
Plånboken laddar ned begäran från länken. Begäran innehåller:
en standardbaserad begäran om autentiseringsuppgifter av en schema- eller autentiseringstyp.
DID för RP, som plånboken letar upp i förtroendesystemet.
Plånboken verifierar att presentationsbegäran och hittar lagrade VC:er som uppfyller begäran. Baserat på de virtuella datorer som krävs vägleder plånboken ämnet för att välja och samtycka till att använda de virtuella datorerna.
- Ämnesmedgivande för att dela VC med RP
Sedan skickar plånboken en nyttolast för presentationssvar till den Microsoft Entra – verifierat ID tjänst som har signerats av ämnet. Den innehåller:
De VC(er) som ämnet samtyckt till.
Ämnet GJORDE.
RP gjorde som "publik" av nyttolasten.
Tjänsten Microsoft Entra – verifierat ID verifierar svaret som skickas av plånboken. I vissa fall kan VC-utfärdaren återkalla VC. För att säkerställa att VC fortfarande är giltig måste kontrollanten kontrollera med VC-utfärdaren. Detta beror på hur kontrollanten bad om VC i steg 2.
Vid validering anropar Microsoft Entra – verifierat ID-tjänsten RP:en med resultatet.
Detaljerad information om hur du skapar en valideringslösning och arkitekturöverväganden finns i Planera din Microsoft Entra – verifierat ID verifieringslösning.
Viktiga lärdomar
Decentraliserade arkitekturer kan användas för att förbättra befintliga lösningar och tillhandahålla nya funktioner.
För att uppfylla målen för decentraliserad identitetsgrund (DIF) och W3C-design bör följande objekt beaktas när du skapar en verifierbar lösning för autentiseringsuppgifter:
Det finns inga centrala förtroendepunkter mellan aktörer i systemet. Det vill:s förtroendegränser utökas inte via federation eftersom aktörer litar på specifika virtuella datorer.
- Förtroendesystemet möjliggör identifiering av alla aktörers decentraliserade identifierare (DID).
Lösningen gör det möjligt för verifierare att verifiera alla verifierbara autentiseringsuppgifter (VCs) från alla utfärdare.
Lösningen gör det inte möjligt för utfärdaren att kontrollera auktoriseringen av ämnet eller kontrollanten (förlitande part).
Aktörerna verkar på ett frikopplat sätt, var och en kan utföra uppgifterna för sina roller.
Utfärdare betjänar varje VC-begäran och diskriminerar inte de begäranden som betjänas.
Försökspersoner äger sin VC när de har utfärdats och kan presentera sin VC för alla verifierare.
Kontrollanter kan verifiera alla VC från valfritt ämne eller utfärdare.
Nästa steg
Läs mer om arkitektur för verifierbara autentiseringsuppgifter