5 yaşındaki bir çocuğa "hak talebine dayalı kimlik doğrulamayı" açıklayın


189

Peki, tam olarak 5 yaşında bir çocuğa değil, lütfen mümkünse terzi ve işletmelerden kaçının.

Talep temelli kimlik doğrulaması şimdi tüm öfke gibi görünüyor, ancak gerçekte ne olduğuna dair basit ve toprağa açık bir açıklama bulamadım, şimdi sahip olduğumuzdan ne kadar farklı ("şimdi sahip olduklarımızı varsayıyorum" rol tabanlı kimlik doğrulaması olmak için) kullanmanın yararları nelerdir vb.


1
@Marnix'e katılıyorum. Artık temel bir anlayışa sahip olduğunuza göre, Microsoft'un tanımı / açıklamasıyla daha kolay bağlantı kurabilirsiniz .
FrankO

Biraz daha fazla dikkat ve zaman harcamak istiyorsanız, bu teknik incelemeyi doğrudan buldum. Giriş soruyu cevaplıyor ve diyagramlar bin kelime konuşuyor: download.microsoft.com/download/7/D/0/…
Paweł Bulwan

Yanıtlar:


215

@Marnix'in oldukça iyi bir cevabı var, ancak teknik yönünden uzaklaşmak için:

Talebe Dayalı Kimlik Doğrulama, size kimlik hakkında doğru bilgi vermek için kime güvendiğinizi tanımlamak ve yalnızca verilen bilgileri kullanmakla ilgilidir. Benim go-to örneğim bir barda. Barda bir bira almak istediğinizi düşünün. Teoride barmen sizden yaş kanıtı istemelidir. Bunu nasıl kanıtlıyorsun? Bir seçenek, barmenin sizi yarıya indirmesi ve yüzük sayısını saymasıdır, ancak bununla ilgili bazı sorunlar olabilir. Diğer seçenek, doğum gününü barmenin onayladığı veya onaylamadığı bir kağıda yazmanızdır. Üçüncü seçenek, hükümete gitmek, kimlik kartı almak ve daha sonra kimliği barmene sunmaktır.

Bazıları sadece doğum gününüzü bir kağıda yazma fikrine gülebilir, ancak bu, uygulamanın kendisinde kullanıcıların kimliğini doğruladığınızda, kağıt parçasına güvenmek barmene (veya uygulamanıza) bağlıdır. . Bununla birlikte, hükümetin kimlik üzerindeki doğum gününün geçerli olduğu iddiasına ve kimlik, içki isteyen kişi içindir. Tüm niyet ve amaçlar için, barmen (veya uygulama), kimlik doğrulamasının güven nedeniyle nasıl gerçekleştiğini umursamıyor. Barmen, doğum tarihiniz dışında sizin hakkınızda hiçbir şey bilmiyor çünkü barmenlerin bilmesi gereken tek şey bu. Şimdi, barmen en sevdiğiniz içecek gibi kendileri için önemli olduğunu düşündükleri bilgileri depolayabilir, ancak hükümet umursamaz (yetkili bir kaynak olmadığı için),

FMA'nın anahtarı "kimliğin yetkili kaynağı kimdir?"


20
Mükemmel benzetme! Keşke bir kişinin yaşını belirlemek için "yarıya kadar kes ve halkaları say" yöntemi için fazladan puan verebilseydim. Bunu denemem gerekecek. :-)
Keith Robertson

8
'Tüm yoğun amaçlar için' o kadar sık ​​görüyorum ki, insanlar 'tüm niyet ve amaçlar için' doğru dediğinde gerçekten takdir ediyorum
JoeBrockhaus

3
Kolay: Onlara, karmaşık konularla ilgili analojilerin, ne kadar iyi anladıklarına bakılmaksızın basit kavramlara kolayca damıtılamayacağını açıklayın. Ve ... neden 5 yaşında bir çocuk gerçekten iddia tabanlı kimlik doğrulaması umurunda?
Steve

2
Bu yazıyı okudum ve iddia tabanlı kimlik doğrulama, açık kimlik veya Microsoft Hesabı, Facebook, Twitter, Google gibi sosyal girişler gibi 3. taraf kimlik doğrulama sistemi gibi görünüyor. kimse iddia tabanlı kimlik doğrulamanın açık yetkiden ne kadar farklı olduğunu söyleyebilir mi? çünkü açık yetki çok 3. taraf yetkilendirme sistemidir.
Thomas

1
@Thomas OAuth aslında kimlik doğrulama ile değil yetkilendirme ile ilgilidir ve bu tamamen farklı bir sohbete dönüşür. Kimlik bilgileri sağlarlar, ancak amaç, kullanıcıyı tanımlamak için değil, hizmetlerine erişmek için belirteci kullanmaktır. Bununla ilgili bir uzantı, tanımlanması amaçlanan OpenID'dir. Her iki durumda da, bunu düşünmenin basit yolu (% 100 doğru değilse), sadece CBA uygulamalarıdır.
Steve

131

(Bu benim kişisel görüşüm, diğerleri farklı olabilir. Lütfen diğer bakış açılarını ayrı cevaplar olarak yayınlayın.)

Talep tabanlı kimlik / kimlik doğrulama / yetkilendirme, kimlik doğrulama / yetkilendirmeyi ayrı bir (web) hizmete dönüştürerek kullanıcı yetkilerinin ve kullanıcı oturum açma işlemlerinin bir (web) uygulamasından ayrılmasıyla ilgilidir.

Örneğin, hak talebinde bulunulmuş bir web uygulamasına ilk kez göz attığımda, tarayıcımı güvendiği bir 'oturum açma hizmetine' yönlendirecek. Bu hizmetin kimliğini doğrulayacağım (Windows kimlik doğrulamasını, akıllı kartı veya herhangi bir şeyi kullanarak) ve yanıt olarak tarayıcının web uygulamasına geri gönderdiği bir 'jeton' geri gönderir. Şimdi web uygulaması, belirtecin güvenilir oturum açma hizmeti tarafından dijital olarak imzalanıp imzalanmadığını denetler ve ardından belirteçteki 'taleplere' bakar. Tamamen bu iddialara dayanarak, uygulama kullanıcıya sunulan işlevselliğe karar verir.

Hak talepleri neredeyse her zaman kullanıcının kimliğini içerecektir, genellikle yetkilendirmeyle ilgili hak talepleri de vardır ('bu kullanıcı Satış verilerini görüntüleyebilir, ancak güncelleyemez') ve bazen diğer bilgiler de ('ayakkabı boyutu = 42').

Önemli nokta, uygulamanın kullanıcının nasıl doğrulandığını veya yetkilerin nasıl yönetildiğini bilmemesi veya umursamamasıdır: yalnızca kullanıcının kim olduğunu ve / veya kullanıcının ne yapabileceğini belirlemek için imzalanmış jetondaki taleplerdeki bilgileri kullanır. kullanıcı ile ilgili diğer bilgileri görme veya yapma.

(Evet, burada oldukça zeki ve bilgili 5 yaşında olduğunu varsayıyorum. :-)


5
"Facebook / Google / ... ile giriş yap" gibi iddialara dayalı kimlik doğrulamanın uygulamadaki örnekleri var mı?
Wes

1
Eminim benim 5 yaşındaki tüm bunları anlayacaktı.
Sinaesthetic

@wes sorunuz biraz belirsiz. Facebook veya google ile oturum açmanın basit bir eylemi, iddia tabanlı kimlik doğrulamanın bir örneği değildir. İddialara dayalı kimlik doğrulamanın bir şey olmadığını da iddia ediyorum . Bir şey olursa izin olurdu. CBA'nın devreye gireceği yer, bu sağlayıcılarla oturum açma yetkisi adımıdır. İzin istediğinde ve kabul ettiğinizde, erişim simgenize kapsam ekler . Bu, bir iddiadan anlamsal olarak farklıdır, ancak genellikle çok benzer bir şekilde kullanılır.
Sinaestetik

40

Aşağıdaki gerçek dünya örneği Talep Tabanlı Kimlik ve Erişim Kontrolü Kılavuzu'ndan (2. Baskı) alınmıştır .

Çok tanıdık bir benzetme, bir havaalanını her ziyaretinizde izlediğiniz kimlik doğrulama protokolüdür . Sadece kapıya kadar yürüyemez ve pasaportunuzu veya ehliyetinizi sunamazsınız. Bunun yerine, önce bilet gişesinden check-in yapmanız gerekir. Burada, kimlik bilgilerinin anlamlı olduğu her şeyi sunarsınız. Yurtdışına gidiyorsanız pasaportunuzu gösterirsiniz. İç hat uçuşları için sürücü belgenizi ibraz edersiniz. Resim kimliğinizin yüzünüzle ( kimlik doğrulama ) eşleştiğini doğruladıktan sonra , aracı uçuşunuzu arar ve bilet ( yetkilendirme ) için ödeme yaptığınızı doğrular . Her şeyin yolunda olduğunu varsayarsak, kapıya götürdüğünüz bir biniş kartı alırsınız.

Bir biniş kartı çok bilgilendiricidir. Kapı görevlileri adınızı ve sık uçan yolcu numaranızı (kimlik doğrulama ve kişiselleştirme), uçuş numaranızı ve oturma önceliğinizi (yetkilendirme) ve belki de daha fazlasını bilir. Kapı ajanları işlerini verimli bir şekilde yapmak için ihtiyaç duydukları her şeye sahiptir.

Biniş kartıyla ilgili özel bilgiler de vardır. Barkodda ve / veya arkadaki manyetik şeride kodlanmıştır. Bu bilgiler (biniş seri numarası gibi), geçişin havayolu tarafından verildiğini ve sahte olmadığını kanıtlar.

Temel olarak, bir biniş kartı, havayolu şirketi tarafından sizin hakkınızda yapılan imzalı bir dizi taleptir. . Belirli bir zamanda belirli bir uçuşa binmenize ve belirli bir koltukta oturmanıza izin verildiğini belirtir. Tabii ki, ajanların bu konuda çok derin düşünmelerine gerek yok. Biniş kartınızı doğrularlar, üzerindeki iddiaları okurlar ve uçağa binmenize izin verirler.

Ayrıca, biniş kartınız olan imzalı talep setini elde etmenin birden fazla yolu olabileceğini belirtmek de önemlidir. Havaalanındaki bilet gişesine gidebilir veya havayolunun web sitesini kullanabilir ve biniş kartınızı evde yazdırabilirsiniz. Uçağa binen kapı ajanları, biniş kartının nasıl oluşturulduğu umurumda değil; havayolunun güvendiği sürece hangi ihraççıyı kullandığınız umurumda değil. Onlar sadece uçağa binmek için izin veren otantik bir iddialar kümesi umurumda.

Yazılımda, bu talep paketine güvenlik belirteci denir . Her güvenlik belirteci, onu oluşturan yayıncı tarafından imzalanır . Talebe dayalı bir uygulama, güvenilir bir yayıncıdan geçerli ve imzalı bir güvenlik belirteci sunduğunda kullanıcıların kimliğinin doğrulandığını düşünür .


18

5 yaşında bir çocuk için, başvuruyu ebeveynleri tarafından imzalayarak yeni bir okula katıldığını varsaymasını isteyin. Başvurusu için okul yönetiminin onayından sonra, okula girmek için TALEPLER diyebileceğimiz aşağıdaki tüm bilgileri içeren bir erişim kartı alır.

  1. BOYUN ADI BOB.
  2. OKUL ADI MONTISSORI LİSESİ
  3. SINIF 8. SINIF

Okulunun ilk gününde okula girerken erişim kartını kaydırdı ve kapılar açıldı, okuldan biri olarak TAZMİNİZ anlamına geliyor. Bu şekilde okula girmek için YETKİLİ BİR KİŞİ olur.

Sınıfa ulaştıktan sonra, her sınıfa girmek için erişim kartı kullandı, ancak 8.Sınıfta kapıların 8.Standart olduğunu iddia ettiği gibi açıldı.

Okulda, şu anda 8. Standardı okurken sınıfına girmek için YETKİLİ. Ve 6. Standarda girmeye çalışırsa, okul öğretmeni onu YETKİLEMEZ.


3
Bu sadece genel kimlik doğrulama ve yetkilendirme kavramını açıklar. Özel olarak iddia temelli veya başka türlü değil
Sheepy

Sheepy, şüphesiz iddialar onun 8. sınıf açıklanması ve 6. sınıfa erişim engellendi?
Ian

1
Bu yazıyı okudum ve iddia tabanlı kimlik doğrulama, açık kimlik veya Microsoft Hesabı, Facebook, Twitter, Google gibi sosyal girişler gibi 3. taraf kimlik doğrulama sistemi gibi görünüyor. kimse iddia tabanlı kimlik doğrulamanın açık yetkiden ne kadar farklı olduğunu söyleyebilir mi? çünkü açık yetki çok 3. taraf yetkilendirme sistemidir.
Thomas

9

Mümkün olduğunca teknik olmayan:

Kim olduğunuz ve ne görmenize ya da yapmanıza izin verildiği hakkında bir şey açıklayacak olsaydınız, bu şeylerin her biri "doğru olduğunu" iddia ettiğiniz bir şey olurdu ve bu nedenle bu listedeki her "şey" bir " İddia".

Birisine kendiniz hakkında bir şey söylediğinizde veya bir şey görmenize veya yapmanıza izin verildiğini "iddia ettiğinizde" onlara iddia listenizi verirsiniz. Bir otorite ile taleplerinizin doğru olduğunu doğrulayacaklar ve eğer öyleyse, iddia listesindeki herhangi bir şeye inanacaklardır. Yani Brad Pitt olduğunuzu iddia ederseniz, talep listeniz Brad Pitt olduğunuzu söylüyor ve iddialarınızın hepsinin doğru olduğu otoritesi ile doğrulandı - o zaman Brad Pitt ile birlikte olduğuna inanacaklar listedeki başka herhangi bir şey.

İddia : doğru olduğunu iddia ettiğiniz şey. Bu, bir bilgi parçası veya sahip olduğunuzu iddia ettiğiniz bir iznin açıklaması olabilir. Taleplerinizi sunduğunuz sistemin sadece talebin / araçların ne olduğunu anlaması ve ayrıca otorite ile doğrulayabilmesi gerekir.

Otorite : Talepler listenizi bir araya getiren ve temelde "Yetkime göre, bu listedeki her şey doğrudur" diyen sistem. Talepleri okuyan sistem, imzanın doğru olduğunu otorite ile doğrulayabildiği sürece, talep listesindeki her şey gerçek ve doğru olarak kabul edilecektir.

Ayrıca, buna "talep tabanlı kimlik doğrulama" demeyelim, bunun yerine "talep tabanlı kimlik" diyelim.

Biraz daha teknik:

Şimdi bu süreçte, bir çeşit mekanizma (kullanıcı adı / şifre, istemci sırrı, sertifika vb.) Kullanarak kimlik doğrulaması yaparsınız ve bu size söylediğiniz kişi olduğunuzu kanıtlayan bir jeton verir. Ardından, bir erişim belirteci için bu erişim belirtecini alıp verirsiniz. Bu işlem, bir talep listesi bulmak ve oluşturmak, imzalamak ve ardından tüm taleplerinizin bulunduğu bir kimlik belirtecini size geri vermek için kimliğinizi kullanır.

Gibi yetkilendirme aşaması, nasıl uygulandığı bağlı olarak kaynak, kimlik jetonu (iddialar) bakmak ve kaynak olduğunu erişim için gerekli iddiaları varsa o zaman kontrol edecektir.

Örneğin, "CastleBlack / CommandersTower" kaynağı "kale karasına erişmeniz ve efendi komutan olmanız gerektiğini söylüyorsa, o zaman her ikisinin de doğru olup olmadığını görmek için talepler listenize bakacaktır.

Gördüğünüz gibi, "iddialar" herhangi bir şey olabilir. Bir rol olabilir, bir gerçek olabilir, bir bayrak olabilir. Bu sadece anahtar / değer çiftlerinin bir listesidir ve "değer" isteğe bağlıdır. Bazen sadece iddianın var olup olmadığını görmekle ilgilidir:

claims : [
    {"type": "name", "value": "Jon Snow"},
    {"type": "home", "value": "Winterfell, The North, Westeros"},   
    {"type": "email", "value": "jon@nightswatch-veterans.org"},
    {"type": "role", "value": "veteran;deserter;"},
    {"type": "department", "value": "none"},    
    {"type": "allowEntry", "value": "true"},
    {"type": "access", "value": "castleblack;eastwatch;"}
]

Jon giriş yaptıysa ve yukarıda açıklanan kaynağa erişmeye çalışırsa, reddedilecekti, çünkü onun söylediği kişi olduğu ve kale karasına erişimi olduğu için artık lord komutanı değil, komutanın kulesi ve dolayısı ile lord komutanın kulesine dolaylı olarak giremez.

Daha spesifik olarak, "CastleBlack" muhtemelen [daha geniş] bir kapsam olacaktır ve her alan belirli bir izin olacaktır, ancak bu farklı bir tartışmadır.

Her uygulamanın erişim ile nasıl başa çıkacağı farklı olacaktır, ancak bunu yapmak için talepleri kullanacaktır.


5

Bir hak talebinin, bu hak taleplerini doğrulamak için bir güvenlik belirteci hizmetine karşı çalıştığınız ve kimlik doğrulama dışında yetkilendirme için kullandığınız kullanıcı hakkında bir şey (ad, yaş, etnik köken, vb.) Anlatan bir özellik olduğunu göz önünde bulundurmak.

Aşağıdaki alıntı Wikipedia'dan alınmıştır ( http://en.wikipedia.org/wiki/Claims-based_identity ) ve şimdiye kadar bulduğum en iyi benzetme

"Güvenlik belirteci hizmeti kavramını daha iyi anlamak için, bir kapıcı ile bir gece kulübünün benzetmesini düşünün. Kapıcı, yaşın altındaki kullanıcıların girişini önlemek istiyor. Bunu kolaylaştırmak için bir kullanıcıdan sürücü belgesi, sağlık sigortası kartı sunmasını istiyor veya il veya eyalet taşıt lisansı departmanı, sağlık departmanı veya sigorta şirketi gibi güvenilir bir üçüncü taraf (güvenlik jetonu servisi) tarafından verilen başka bir kimlik (jeton) Gece kulübü bu nedenle patronun belirlenmesinden sorumludur. Sadece veren otoriteye güvenmek zorundadır (ve tabii ki sunulan tokenin gerçekliği hakkında kendi kararını vermelidir) Bu iki adım tamamlandığında gece kulübü patronu, iddiasıyla ilgili olarak başarıyla doğrulamıştır. yasal içme yaşı.

Benzetmeye devam ederken, gece kulübünün bir üyelik sistemi olabilir ve bazı üyeler düzenli veya VIP olabilir. Kapıcı, başka bir iddiada bulunabilecek başka bir belirteç, üyelik kartı isteyebilir; üyenin bir VIP olduğunu. Bu durumda, jetonun güvenilir düzenleme yetkilisi muhtemelen kulübün kendisi olacaktır. Üyelik kartı hamilinin VIP olduğu iddiasında bulunursa, kulüp buna göre tepki gösterebilir ve kimliği doğrulanmış VIP üyelik talebini hamilinin özel lounge alanında oturmasına ve ücretsiz içecek servisine izin verilmesi gibi bir izne çevirebilir. "

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.