Microsoft Entra Kimlik Doğrulama mimarisine genel bakış
Kimlik bilgilerini vermenin ve doğrulamanın yanı sıra çözümünüzün mimari ve iş etkilerini tam olarak görebilmeniz için doğrulanabilir kimlik bilgileri çözümünüzü planlamanız önemlidir. Henüz gözden geçirmediyseniz, Microsoft Entra Kimlik Doğrulama ve SSS'ye giriş bölümünü gözden geçirmenizi ve ardından Başlarken öğreticisini tamamlamanızı öneririz.
Bu mimariye genel bakış, Microsoft Entra Kimlik Doğrulama hizmetinin özelliklerini ve bileşenlerini tanıtır. Verme ve doğrulama hakkında daha ayrıntılı bilgi için bkz.
Kimlik yaklaşımları
Günümüzde çoğu kuruluş, çalışanların kimlik bilgilerini sağlamak için merkezi kimlik sistemleri kullanmaktadır. Ayrıca müşterileri, iş ortaklarını, satıcıları ve bağlı olan tarafları kuruluşun güven sınırlarına getirmek için çeşitli yöntemler kullanır. Bu yöntemler arasında federasyon, Microsoft Entra B2B gibi sistemlerle konuk hesapları oluşturma ve yönetme ve bağlı olan taraflarla açık güven oluşturma yer alır. Çoğu iş ilişkisi dijital bir bileşene sahiptir, bu nedenle kuruluşlar arasında bir tür güven sağlamak için önemli bir çaba gerekir.
Merkezi kimlik sistemleri
Uygulamaların, hizmetlerin ve cihazların bir etki alanı veya güven sınırı içinde kullanılan güven mekanizmalarına güvenmesi gibi birçok durumda merkezi yaklaşımlar hala iyi sonuç verir.
Merkezi kimlik sistemlerinde kimlik sağlayıcısı (IDP), kimlik bilgilerinin yaşam döngüsünü ve kullanımını denetler.
Ancak, doğrulanabilir kimlik bilgileriyle merkezi olmayan bir mimari kullanmanın, örneğin önemli senaryoları artırarak değer sağlayabildiği senaryolar vardır:
uzak senaryolar dahil olmak üzere çalışanların ve başkalarının kimliklerinin güvenli bir şekilde eklenmesi.
belirli ölçütlere göre kuruluş güven sınırı içindeki kaynaklara erişim.
kuruluş tarafından verilen taşınabilir kimlik bilgileriyle iş ortaklarının kaynaklarına erişme gibi güven sınırının dışındaki kaynaklara erişme.
Merkezi olmayan kimlik sistemleri
Merkezi olmayan kimlik sistemlerinde kimlik bilgilerinin yaşam döngüsü ve kullanımı denetimi veren, sahip ve kimlik bilgilerini kullanan bağlı olan taraf arasında paylaşılır.
Diyagramda, bir e-ticaret web sitesi olan Proseware'in Woodgrove çalışanlarına kurumsal indirimler sunmak istediği senaryoyu düşünün.
Doğrulanabilir kimlik bilgileri (VC) terminolojisi, VM'leri bilmiyorsanız kafa karıştırıcı olabilir. Aşağıdaki tanımlar Doğrulanabilir Kimlik Bilgileri Veri Modeli 1.0 terminolojisi bölümündendir. Her birinin ardından, bunları önceki diyagramdaki varlıklarla ilişkilendiriyoruz.
"Veren, bir varlığın bir veya daha fazla konu hakkında beyanda bulunarak, bu taleplerden doğrulanabilir bir kimlik bilgisi oluşturarak ve doğrulanabilir kimlik bilgilerini bir sahipe ileterek gerçekleştirebileceği bir roldür."
- Yukarıdaki diyagramda Woodgrove, çalışanlarına doğrulanabilir kimlik bilgileri verendir.
"Sahip, bir varlığın bir veya daha fazla doğrulanabilir kimlik bilgilerine sahip olup onlardan sunular oluşturarak gerçekleştirebileceği bir roldür. Sahipler genellikle, ancak her zaman değil, tuttukları doğrulanabilir kimlik bilgilerinin bir konusudur. Sahipler kimlik bilgilerini kimlik bilgileri depolarında depolar."
- Yukarıdaki diyagramda Alice bir Woodgrove çalışanıdır. Woodgrove verenden doğrulanabilir bir kimlik bilgisi edindiler ve bu kimlik bilgilerinin sahibidir.
"Doğrulayıcı, bir varlığın, isteğe bağlı olarak işlenmek üzere doğrulanabilir bir sunu içinde bir veya daha fazla doğrulanabilir kimlik bilgisi alarak gerçekleştirdiği bir roldür. Diğer belirtimler bu kavramı bağlı olan taraf olarak adlandırabilir."
- Yukarıdaki diyagramda Proseware, Woodgrove tarafından verilen kimlik bilgilerinin doğrulayıcısıdır.
"Kimlik bilgisi , veren tarafından yapılan bir veya daha fazla talep kümesidir. Doğrulanabilir kimlik bilgileri, kriptografik olarak doğrulanabilen yazarlığa sahip kurcalamaya karşı korumalı bir kimlik bilgisidir. Doğrulanabilir kimlik bilgileri, kriptografik olarak da doğrulanabilen doğrulanabilir sunular oluşturmak için kullanılabilir. Kimlik bilgilerindeki talepler farklı konular hakkında olabilir."
"Merkezi olmayan tanımlayıcı, bir varlıkla ilişkilendirilmiş, BIR DID olarak da bilinen taşınabilir URI tabanlı bir tanımlayıcıdır. Bu tanımlayıcılar genellikle doğrulanabilir bir kimlik bilgisinde kullanılır ve konular, verenler ve doğrulayıcılarla ilişkilendirilir."
"DID belgesi olarak da adlandırılan merkezi olmayan tanımlayıcı belgesi, doğrulanabilir bir veri kayıt defteri kullanılarak erişilebilen ve ilişkili depo ve ortak anahtar bilgileri gibi belirli bir merkezi olmayan tanımlayıcıyla ilgili bilgileri içeren bir belgedir."
Senaryoda hem verenin hem de doğrulayıcının DID ve DID belgesi vardır. DID belgesi ortak anahtarı ve DID ile ilişkili DNS web etki alanlarının listesini (bağlı etki alanları olarak da bilinir) içerir.
Woodgrove (veren), çalışanlarının sanal bilgisayarlarını özel anahtarıyla imzalar; Benzer şekilde, Proseware (doğrulayıcı) da KENDI DID ile ilişkili anahtarını kullanarak bir VC sunmak için istekleri imzalar.
Güven sistemi , merkezi olmayan sistemler arasında güven oluşturmanın temelini oluşturur. Dağıtılmış bir kayıt defteri veya DID Web gibi merkezi bir şey olabilir.
"Dağıtılmış kayıt defteri, olayları kaydetmek için merkezi olmayan bir sistemdir. Bu sistemler, katılımcıların operasyonel kararlar almak için başkaları tarafından kaydedilen verilere güvenmesi için yeterli güven sağlar. Genellikle farklı düğümlerin şifreli olarak imzalanan işlemlerin sırasını onaylamak için bir konsensüs protokolü kullandığı dağıtılmış veritabanlarını kullanırlar. Dijital olarak imzalanan işlemlerin zaman içinde bağlanması genellikle kayıt defterinin geçmişini etkili bir şekilde sabit hale getirir."
Merkezi ve merkezi olmayan kimlik mimarilerini birleştirme
Doğrulanabilir bir kimlik bilgisi çözümünü incelediğinizde, merkezi olmayan kimlik mimarilerinin merkezi kimlik mimarileriyle birleştirilerek riski azaltan ve önemli operasyonel avantajlar sunan bir çözüm sağlanması yararlı olur.
Kullanıcı yolculuğu
Bu mimariye genel bakış, bir kuruluş için başvuruda bulunan ve bir kuruluşa iş kabul eden bir iş adayının ve çalışanın yolculuğunu izler. Daha sonra doğrulanabilir kimlik bilgilerinin merkezi süreçleri artırabileceği değişiklikler aracılığıyla çalışan ve kuruluşu izler.
Bu kullanım örneklerindeki aktörler
Alice, Woodgrove, Inc. ile iş başvurusunda bulunan ve kabul eden bir kişi.
Woodgrove, Inc, kurgusal bir şirket.
Woodgrove'un kurgusal kimlik doğrulama ortağı Adatum.
Proseware, Woodgrove'un kurgusal ortak kuruluşu.
Woodgrove hem merkezi hem de merkezi olmayan kimlik mimarilerini kullanır.
Kullanıcı yolculuğundaki adımlar
Alice Woodgrove, Inc. ile bir pozisyona başvurup kabul ediyor ve bu pozisyona ekleniyor.
Woodgrove'un güven sınırındaki dijital kaynaklara erişme.
Woodgrove veya iş ortaklarının güven sınırlarını genişletmeden Woodgrove'un güven sınırının dışında dijital kaynaklara erişme.
Woodgrove işlerini yürütmeye devam ettikçe, kimlikleri sürekli olarak yönetmesi gerekir. Bu kılavuzdaki kullanım örnekleri, Alice'in tanımlayıcılarını elde etmek ve korumak için self servis işlevlerini nasıl kullanabileceğini ve Woodgrove'un çeşitli güven gereksinimlerine sahip işletmeler arası ilişkileri nasıl ekleyebileceğini, değiştirebildiğini ve sonlandırabileceğini açıklar.
Bu kullanım örnekleri, merkezi kimliklerin ve merkezi olmayan kimliklerin daha sağlam ve verimli bir kimlik ve güven stratejisi ve yaşam döngüsü sağlamak için nasıl birleştirilebileceğini gösterir.
Kullanıcı yolculuğu: Woodgrove'a ekleme
Farkındalık: Alice Woodgrove, Inc. için çalışmakla ilgileniyor ve Woodgrove'un kariyer web sitesini ziyaret ediyor.
Etkinleştirme: Woodgrove sitesi, Alice'e bir QR kodu veya güvenilir kimlik doğrulama ortağı Adatum'u ziyaret etmek için ayrıntılı bir bağlantı göndererek kimliğini kanıtlamak için bir yöntem sunar.
İstek ve karşıya yükleme: Adatum, Alice'ten kimlik kanıtı isteğinde bulunur. Alice bir özçekim ve bir ehliyet resmi alır ve bunları Adatum'a yükler.
Verme: Adatum, Alice'in kimliğini doğruladıktan sonra, Adatum Alice'e kimliğini doğrulayan doğrulanabilir bir kimlik bilgisi (VC) verir.
Sunu: Alice (kimlik bilgilerinin sahibi ve konusu) daha sonra başvuru sürecini tamamlamak için Woodgrove kariyer portalına erişebilir. Alice portala erişmek için VC'yi kullandığında Woodgrove, Adatum'daki kanıtlamaya güvenerek doğrulayıcı ve bağlı olan tarafın rollerini alır.
İlk kimlik bilgilerini dağıtma
Alice Woodgrove'la çalışma kabul eder. Ekleme işleminin bir parçası olarak Alice'in Woodgrove güven sınırının içinde kullanması için bir Microsoft Entra hesabı oluşturulur. Alice'in yöneticisi, uzaktan çalışan Alice'in ilk oturum açma bilgilerini güvenli bir şekilde almasını nasıl etkinleştireceklerini bulmalıdır. Geçmişte BT departmanı bu kimlik bilgilerini yöneticilerine sağlamış ve bu kimlik bilgilerini yazdırıp Alice'e teslim edebilirdi. Kimlik bilgilerini yazdırmak uzak çalışanlarla çalışmaz.
VM'ler, kimlik bilgisi dağıtım işlemini artırarak merkezi sistemlere değer katabilir. Alice, yöneticinin kimlik bilgilerini sağlamasına ihtiyaç duyması yerine VC'sini kimlik kanıtı olarak kullanarak merkezi sistemlere erişim için ilk kullanıcı adını ve kimlik bilgilerini alabilir. Alice, ekleme işleminin bir parçası olarak cüzdanına ekledikleri kimlik kanıtını sunar.
Ekleme kullanım örneğinde güven ilişkisi rolleri veren, doğrulayıcı ve sahip arasında dağıtılır.
Veren, verdikleri VC'nin parçası olan talepleri doğrulamakla sorumludur. Adatum, VC'yi vermek için Alice'in kimliğini doğrular. Bu durumda, vm'ler bir doğrulayıcı veya bağlı olan taraf dikkate alınmadan verilir.
Sahip, VC'ye sahiptir ve doğrulama için VC'nin sunumunu başlatır. Sahip olduğu sanal makineleri yalnızca Alice sunabilir.
Doğrulayıcı, güvendikleri verenlerin VC'deki taleplerini kabul eder ve doğrulanabilir kimlik bilgileri veri modelinde açıklanan merkezi olmayan kayıt defteri özelliğini kullanarak VC'yi doğrular. Woodgrove, Adatum'un Alice'in kimliği hakkındaki iddialarına güvenir.
Ekleme için merkezi ve merkezi olmayan kimlik mimarilerini birleştirerek, Kimlik doğrulama için gerekli Olan Alice hakkında kamu kimlik numarası gibi ayrıcalıklı bilgilerin Woodgrove tarafından depolanması gerekmez, çünkü Alice'in kimlik doğrulama ortağı (Adatum) tarafından verilen VC'sinin kimliğini onayladığına güvenirler. Eforun yinelenmesi en aza indirilir ve ilk ekleme görevlerine programlı ve öngörülebilir bir yaklaşım uygulanabilir.
Kullanıcı yolculuğu: Güven sınırının içindeki kaynaklara erişme
Bir çalışan olarak Alice, Woodgrove'un güven sınırının içinde faaliyet gösterir. Woodgrove, kimlik sağlayıcısı (IDP) görevi görür ve Alice'in Woodgrove güven sınırı içinde etkileşimde bulunurken kullandığı uygulamaların kimliği ve yapılandırmasında tam denetime sahip olur. Microsoft Entra ID güven sınırındaki kaynakları kullanmak için Alice, Woodgrove'un güven sınırında oturum açmak ve Woodgrove'un teknoloji ortamındaki kaynaklara erişmek için olası olarak birden çok kimlik kanıtı biçimi sağlar. Birden çok kanıt, merkezi bir kimlik mimarisi kullanılarak iyi sunulan tipik bir senaryodur.
Woodgrove güven sınırını yönetir ve iyi güvenlik uygulamalarının kullanılması, gerçekleştirilen işe göre Alice'e en az ayrıcalıklı erişim düzeyini sağlar. Güçlü bir güvenlik duruşu sağlamak ve uyumluluk nedenleriyle Woodgrove'un çalışanların izinlerini ve kaynaklara erişimini de izleyebilmesi ve çalışma sonlandırıldığında izinleri iptal edebilmesi gerekir.
Alice yalnızca Woodgrove kaynaklarına erişmek için Woodgrove'un koruduğu kimlik bilgilerini kullanır. Woodgrove kimlik bilgilerini yönettiğinden ve yalnızca Woodgrove kaynaklarıyla kullanıldığından Alice'in kimlik bilgilerinin ne zaman kullanıldığını izlemesi gerekmez. Kimlik yalnızca Woodgrove kaynaklarına erişim gerektiğinde Woodgrove güven sınırının içinde geçerlidir, bu nedenle Alice'in kimlik bilgilerine sahip olması gerekmez.
Güven sınırının içinde VM'leri kullanma
Tek tek çalışanların değişen kimlik gereksinimleri vardır ve VM'ler bu değişiklikleri yönetmek için merkezi sistemleri genişletebilir.
Woodgrove Alice tarafından çalıştırılan ancak belirli gereksinimlerin karşılanması temelinde kaynaklara erişim elde etmeniz gerekebilir. Örneğin, Alice gizlilik eğitimini tamamladığında, bu taleple yeni bir çalışan VC'sine sahip olabilir ve bu VC kısıtlanmış kaynaklara erişmek için kullanılabilir.
Vm'ler, hesap kurtarma için güven sınırının içinde kullanılabilir. Örneğin, çalışan telefon ve bilgisayarını kaybettiyse, Woodgrove tarafından güvenilen kimlik doğrulama hizmetinden yeni bir VC alarak yeniden erişim elde edebilir ve ardından yeni kimlik bilgilerini almak için bu VC'yi kullanabilir.
Kullanıcı yolculuğu: Dış kaynaklara erişme
Woodgrove, Proseware ile ürün satın alma indirimi anlaşması yaptı. Tüm Woodgrove çalışanları indirimden yararlanabilir. Woodgrove, Alice'e Proseware'in web sitesine erişmek ve satın alınan ürünlerde indirim almak için bir yol sağlamak istiyor. Woodgrove merkezi bir kimlik mimarisi kullanıyorsa Alice'e indirim sağlamanın iki yaklaşımı vardır:
Alice, Proseware ile hesap oluşturmak için kişisel bilgiler sağlayabilir ve ardından Proseware'in Alice'in Woodgrove ile çalıştığını doğrulaması gerekir.
Woodgrove güven sınırını Proseware'i bağlı olan taraf olarak içerecek şekilde genişletebilir ve Alice de genişletilmiş güven sınırını kullanarak indirimi alabilir.
Merkezi olmayan tanımlayıcılarla Woodgrove, Alice'e, Alice'in Proseware'in web sitesine ve diğer dış kaynaklara erişmek için kullanabileceği doğrulanabilir bir kimlik bilgisi (VC) sağlayabilir.
Woodgrove, VC'yi Alice'e sağlayarak Alice'in bir çalışan olduğunu doğrular. Woodgrove, Proseware'in doğrulama çözümünde güvenilir bir VC verendir. Woodgrove'un verme sürecine olan bu güven, Proseware'in VC'yi Alice'in bir Woodgrove çalışanı olduğunun kanıtı olarak elektronik olarak kabul etmesine ve Alice'e indirim sağlamasına olanak tanır. VC Alice'in sunduğu doğrulamanın bir parçası olarak, Proseware güven sistemini kullanarak VC'nin geçerliliğini denetler. Bu çözümde:
Woodgrove, Alice'in, Woodgrove'un güven sınırını genişletmek zorunda kalmadan Proseware'in çalışma kanıtı sağlamasına olanak tanır.
Proseware'in Alice'in Woodgrove çalışanı olduğunu doğrulamak için güven sınırını genişletmesi gerekmez. Proseware, Woodgrove'un sağladığı VC'yi kullanabilir. Güven sınırı genişletilmediğinden, güven ilişkisini yönetmek daha kolaydır ve Proseware artık VM'leri kabul etmeyerek ilişkiyi kolayca sonlandırabilir.
Alice'in e-posta gibi Proseware kişisel bilgilerini sağlaması gerekmez. Alice, VC'yi kişisel bir cihazdaki bir cüzdan uygulamasında tutar. VC'yi kullanabilen tek kişi Alice'tir ve Alice'in kimlik bilgilerinin kullanımını başlatması gerekir. VC'nin her kullanımı cüzdan uygulaması tarafından kaydediliyor, bu nedenle Alice'in VC'nin ne zaman ve nerede kullanıldığına ilişkin bir kaydı var.
Woodgrove'da güven sınırları içinde ve dışında çalışacak merkezi ve merkezi olmayan kimlik mimarileri birleştirilerek karmaşıklık ve risk azaltılabilir ve sınırlı ilişkilerin yönetilmesi kolaylaşır.
Zaman içindeki değişiklikler
Woodgrove yeni ekler ve diğer kuruluşlarla mevcut iş ilişkilerini sonlandırır ve merkezi ve merkezi olmayan kimlik mimarilerinin ne zaman kullanıldığını belirlemesi gerekir.
Merkezi ve merkezi olmayan kimlik mimarileri birleştirilerek kimlik ve kimlik kanıtıyla ilişkili sorumluluk ve çaba dağıtılır ve risk azaltılır. Kullanıcı, özel bilgilerini sık sık veya bilinmeyen doğrulayıcılara yayınlama riskini almaz. Özellikle:
- Merkezi kimlik mimarilerinde, IDP kimlik bilgilerini verir ve verilen bu kimlik bilgilerinin doğrulamasını gerçekleştirir. IDP, tüm kimliklerle ilgili bilgileri işler. Bunları bir dizinde depolar veya bir dizinden alır. İsteğe bağlı olarak, IDP'ler sosyal oturum açma işlemleri veya iş ortakları gibi diğer IDP sistemlerinden güvenlik belirteçlerini kabul edebilir. Bağlı olan bir tarafın kimlikleri IDP güven sınırında kullanması için, IDP tarafından verilen belirteçleri kabul etmek üzere yapılandırılması gerekir.
Merkezi olmayan kimlik sistemleri nasıl çalışır?
Merkezi olmayan kimlik mimarilerinde, verenin, kullanıcının ve bağlı olan tarafın (RP) her birinin birbirlerinin kimlik bilgilerinin sürekli güvenilir değişimini oluşturma ve sağlama konusunda bir rolü vardır. Aktörlerin DD'lerinin ortak anahtarları güven sistemi aracılığıyla çözülebilir ve bu da imza doğrulamasına ve bu nedenle doğrulanabilir kimlik bilgileri de dahil olmak üzere herhangi bir yapıtın güvene sahip olmasına olanak tanır. Bağlı olan taraflar, verenle güven ilişkileri kurmadan doğrulanabilir kimlik bilgilerini kullanabilir. Bunun yerine veren, bağlı olan taraflara kanıt olarak sunmak için konuya bir kimlik bilgisi sağlar. Aktörler arasındaki tüm iletiler aktörün DID'siyle imzalı; Verenlerin ve doğrulayıcıların DID'lerinin de istekleri oluşturan DNS etki alanlarına sahip olması gerekir.
Örneğin: VC sahiplerinin bir kaynağa erişmesi gerektiğinde, VC'yi bağlı olan tarafa sunmaları gerekir. Bunu, RP'nin VC sunma isteğini okumak için bir cüzdan uygulaması kullanarak yapar. İsteği okumanın bir parçası olarak cüzdan uygulaması, güven sistemini kullanarak RP'nin ortak anahtarlarını bulmak için RP'nin DID'sini kullanır ve VC'yi sunma isteğinin üzerinde oynanmadığını doğrular. Cüzdan, etki alanı sahipliğini kanıtlamak için RP'nin DNS etki alanında barındırılan bir meta veri belgesinde DID'ye başvurulduğunu da denetler.
Akış 1: Doğrulanabilir kimlik bilgisi verme
Bu akışta, kimlik bilgisi sahibi, aşağıdaki diyagramda gösterildiği gibi doğrulanabilir bir kimlik bilgisi istemek için verenle etkileşim kurar
Tutucu, verenin web ön ucuna erişmek için bir tarayıcı veya yerel uygulama kullanarak akışı başlatır. Burada, veren web sitesi kullanıcıyı veri toplamaya yönlendirir ve kimlik bilgilerinin ve içeriğinin verilip verilemeyeceğini belirlemek için verene özgü mantık yürütür.
Veren web ön ucu, bir VC verme isteği oluşturmak için Microsoft Entra Kimlik Doğrulama hizmetini çağırır.
Web ön ucu, isteğe bir bağlantıyı QR kodu veya cihaza özgü bir ayrıntılı bağlantı (cihaza bağlı olarak) olarak işler.
Tutucu, Microsoft Authenticator gibi bir Cüzdan uygulamasını kullanarak 3. adımdaki QR kodunu veya ayrıntılı bağlantıyı tarar
Cüzdan, isteği bağlantıdan indirir. İstek şunları içerir:
Verenin DID'i. Verenin DID'i cüzdan uygulaması tarafından ortak anahtarları ve bağlı etki alanlarını bulmak üzere güven sistemi aracılığıyla çözümlemek için kullanılır.
VC'yi vermek için sözleşme gereksinimlerini belirten VC bildirimine sahip URL. Sözleşme gereksinimi, sağlanması gereken id_token, kendi kendini doğrulayan öznitelikleri veya başka bir VC'nin sunumunu içerebilir.
VC'nin (logo dosyasının URL'si, renkler vb.) görünümü ve görünümü.
Cüzdan, verme isteklerini doğrular ve sözleşme gereksinimlerini işler:
Verme isteği iletisinin, güven sistemi aracılığıyla çözümlenen DID belgesinde bulunan verenin anahtarları tarafından imzalandığını doğrular. İmzayı doğrulamak, iletinin üzerinde oynanmamasını sağlar.
Verenin DID belgesinde başvurulan DNS etki alanına sahip olduğunu doğrular.
VC sözleşme gereksinimlerine bağlı olarak cüzdan, sahibinin kendi kendine verilen öznitelikler isteme veya id_token almak için OIDC akışında gezinme gibi ek bilgiler toplamasını gerektirebilir.
Sözleşmenin gerektirdiği yapıtları Microsoft Entra Kimlik Doğrulama hizmetine gönderir. Microsoft Entra Kimlik Doğrulama hizmeti verenin DID anahtarıyla imzalanan VC'yi döndürür ve cüzdan VC'yi güvenli bir şekilde depolar.
Verme çözümü oluşturma ve mimari konuları hakkında ayrıntılı bilgi için bkz. Microsoft Entra Kimlik Doğrulama verme çözümünüzü planlama.
Akış 2: Doğrulanabilir kimlik bilgisi sunusu
Bu akışta bir sahip, yetkilendirme gereksinimleri kapsamında bir VC sunmak için bağlı olan tarafla (RP) etkileşim kurar.
Tutucu, bağlı olan tarafın web ön ucuna erişmek için bir tarayıcı veya yerel uygulama kullanarak akışı başlatır.
Web ön ucu, bir VC sunu isteği oluşturmak için Microsoft Entra Kimlik Doğrulama hizmetini çağırır.
Web ön ucu, isteğe bir bağlantıyı QR kodu veya cihaza özgü bir ayrıntılı bağlantı (cihaza bağlı olarak) olarak işler.
Tutucu, Microsoft Authenticator gibi bir cüzdan uygulamasını kullanarak 3. adımdaki QR kodunu veya ayrıntılı bağlantıyı tarar
Cüzdan, isteği bağlantıdan indirir. İstek şunları içerir:
bir şemanın veya kimlik bilgisi türünün kimlik bilgileri için standartlara dayalı istek.
Cüzdanın güven sisteminde baktığı RP'nin DID'i.
Cüzdan, sunu isteğini doğrular ve isteği karşılayan depolanmış VC'leri bulur. Gerekli sanal makinelere bağlı olarak cüzdan, konuyu sanal makinelerin kullanılması için seçme ve onay konusunda yönlendirir.
- Konu, VC'yi RP ile paylaşmayı kabul eder
Ardından cüzdan, konu tarafından imzalanan Microsoft Entra Kimlik Doğrulama hizmetine bir sunum yanıtı yükü gönderir. Şunları içerir:
Konunun onaylandığı VC'ler.
Konu DID.
RP, yükün "hedef kitlesi" olarak YAPTı.
Microsoft Entra Kimlik Doğrulama hizmeti, cüzdan tarafından gönderilen yanıtı doğrular. Bazı durumlarda, VC veren VC'yi iptal edebilir. VC'nin hala geçerli olduğundan emin olmak için, doğrulayıcının VC vereni denetlemesi gerekir. Bu, doğrulayıcının 2. adımda VC'yi nasıl sorduğuna bağlıdır.
Doğrulamadan sonra, Microsoft Entra Kimlik Doğrulama hizmeti sonuçla birlikte RP'yi geri çağırır.
Doğrulama çözümü oluşturma ve mimari konuları hakkında ayrıntılı bilgi için bkz. Microsoft Entra Kimlik Doğrulama doğrulama çözümünüzü planlama.
Önemli Kalkışlar
Merkezi olmayan mimariler mevcut çözümleri geliştirmek ve yeni özellikler sağlamak için kullanılabilir.
Merkezi Olmayan Kimlik Vakfı (DIF) ve W3C Tasarım hedeflerinin hedeflerini sağlamak için doğrulanabilir bir kimlik bilgisi çözümü oluşturulurken aşağıdaki öğeler dikkate alınmalıdır:
Sistemdeki aktörler arasında merkezi bir güven kurulması noktası yoktur. Yani, aktörler belirli sanal makinelere güvendiği için güven sınırları federasyon aracılığıyla genişletilir.
- Güven sistemi, herhangi bir aktörün merkezi olmayan tanımlayıcısının (DID) bulunmasını sağlar.
Çözüm, doğrulayıcıların herhangi bir verenden doğrulanabilir kimlik bilgilerini (VC) doğrulamasını sağlar.
Çözüm, verenin konunun veya doğrulayıcının (bağlı olan taraf) yetkilendirmesini denetlemesini sağlamaz.
Aktörler, her biri rolleri için görevleri tamamlayabilen ayrılmış bir şekilde çalışır.
Verenler her VC isteğine hizmet eder ve hizmet verilen isteklerde ayrım yapmaz.
Denekler VC'lerinin sahibidir ve VC'lerini herhangi bir doğrulayıcıya sunabilir.
Doğrulayıcılar herhangi bir konudan veya verenden herhangi bir VC'leri doğrulayabilir.
Sonraki adımlar
Doğrulanabilir kimlik bilgileri için mimari hakkında daha fazla bilgi edinin