Güvenlik modellerini defalarca uyguladım ve bu kavramların etrafına da sarılmak zorunda kaldım. Bunu birçok kez yaptıktan sonra, işte bu kavramları anlıyorum.
Roller Nelerdir
Rol = Kullanıcılar ve İzinlerin birleşimi .
Bir yandan, Rol, İzinler koleksiyonudur. Ben buna İzin Profili demeyi seviyorum. Bir Rolü tanımlarken, temelde bu Role bir dizi İzin eklersiniz, yani bu anlamda bir Rol bir İzin Profilidir.
Öte yandan, Rol de bir Kullanıcılar koleksiyonudur. Bob ve Alice'i Rol "Yöneticiler" e eklersem, "Yöneticiler" artık bir Grup gibi iki Kullanıcıdan oluşan bir koleksiyon içerir.
Gerçek şu ki, bir Rol HEM bir Kullanıcı koleksiyonu ve bir araya getirilmiş bir İzin koleksiyonudur. Görsel olarak bu bir Venn diyagramı olarak görülebilir.
Grup nedir
Grup = Kullanıcı Koleksiyonu
Bir "Grup" kesinlikle bir Kullanıcılar koleksiyonudur. Bir Grup ve Rol arasındaki fark, bir Rolün ayrıca bir İzin koleksiyonuna sahip olması, ancak bir Grubun yalnızca bir Kullanıcı koleksiyonuna sahip olmasıdır.
İzin nedir
İzin = Bir konu ne yapabilir
İzin Seti nedir
İzin Seti = İzinlerin Koleksiyonu
Sağlam bir RBAC sisteminde İzinler, Kullanıcılar gibi gruplandırılabilir. Gruplar yalnızca Kullanıcılardan oluşan bir koleksiyon iken, bir İzin Kümesi yalnızca İzinlerin bir koleksiyonudur. Bu, bir yöneticinin tüm İzin koleksiyonlarını tek seferde Rollere eklemesine olanak tanır.
Kullanıcılar, Gruplar, Roller ve İzinler Nasıl Bir Araya Gelir?
Güçlü bir RBAC sisteminde, Kullanıcılar, Rol içindeki Kullanıcıların koleksiyonunu oluşturmak için bir Rol'e ayrı ayrı eklenebilir veya Gruplar, Rol'e bir defada bir Kullanıcı koleksiyonu eklemek için bir Rol'e eklenebilir. Her iki durumda da Rol, Kullanıcı koleksiyonunu tek tek eklenerek veya Role Gruplar ekleyerek veya Role bir Kullanıcı ve Grup karışımı ekleyerek alır. İzinler aynı şekilde düşünülebilir.
İzinler, Rollerin içindeki İzinlerin koleksiyonunu oluşturmak için Rollere ayrı ayrı eklenebilir veya bir Role İzin Kümeleri eklenebilir. Son olarak, bir Role İzin ve İzin Kümelerinin bir karışımı eklenebilir. Her iki durumda da Rol, İzin koleksiyonunu tek tek eklenerek veya bir Rol için İzin Kümeleri ekleyerek alır.
Rollerin tüm amacı, Kullanıcıları İzinlerle birleştirmektir. Bu nedenle, Rol, Kullanıcıların ve İzinlerin BİRLİĞİ'dir.
İddialar Nelerdir
Claim = Konu "nedir"
İddialar İzin DEĞİLDİR. Önceki cevaplarda belirtildiği gibi, İddia, öznenin "öznenin" yapabildiği şey olmadığıdır ".
Talepler, Rollerin veya İzinlerin yerini almaz, bunlar bir kişinin bir Yetkilendirme kararı vermek için kullanabileceği ek bilgi parçalarıdır.
Hak Talepleri Ne Zaman Kullanılmalı
Kullanıcı bir Role eklenemediğinde veya karar Kullanıcının İzin ile ilişkilendirilmesine dayanmadığında bir Yetkilendirme kararının verilmesi gerektiğinde İddiaların yararlı olduğunu buldum. Bir Facebook Kullanıcısı örneği buna neden olur. Bir Facebook Kullanıcısı, "Rol" 'e eklenen biri olmayabilir ... onlar sadece Facebook aracılığıyla kimliği doğrulanmış bazı Ziyaretçilerdir. RBAC'a tam olarak uymasa da, bir yetkilendirme kararı vermek için bir bilgi parçasıdır.
@CodingSoft, gece kulübü metaforunu bir önceki cevapta kullandı, ben bunu genişletmek istiyorum. Bu cevapta, Sürücü Belgesi, Doğum Tarihinin Taleplerden birini temsil ettiği ve Doğum Tarihi Talebinin değerinin yetkilendirme kuralına karşı test etmek için kullanıldığı bir dizi Talep içeren bir örnek olarak kullanılmıştır. Ehliyetini veren hükümet, Talebin gerçekliğini veren makamdır. Bu nedenle, bir gece kulübü senaryosunda, kapıdaki fedai kişinin Ehliyetine bakar, sahte kimlik olup olmadığını inceleyerek güvenilir bir makam tarafından verilmiş olmasını sağlar (yani, geçerli devlet tarafından verilmiş kimlik olmalıdır), daha sonra Doğum Tarihine bakar (Ehliyetle ilgili birçok iddiadan biri), ardından bu değeri kişinin kulübe girecek kadar yaşlı olup olmadığını belirlemek için kullanır. Öyleyse,
Şimdi, bu temeli aklımda tutarak şimdi bunu daha da genişletmek istiyorum. Gece kulübünün bulunduğu binada, sadece kulüp çalışanlarının girebileceği ofisler, odalar, mutfak, diğer katlar, asansörler, bir bodrum vb. İçerdiğini varsayalım. Ayrıca, bazı çalışanların, diğer çalışanların erişemeyeceği belirli yerlere erişimi olabilir. Örneğin, bir Yönetici, diğer çalışanların erişemeyeceği bir üst kattaki bir ofis katına erişebilir. Bu durumda iki Rol vardır. Yönetici ve Çalışan.
Ziyaretçilerin kamuya açık gece kulübü alanına erişimi yukarıda açıklandığı gibi tek bir taleple yetkilendirilirken, çalışanların Rol tarafından diğer halka açık olmayan kısıtlanmış odalara erişmesi gerekir. Onlar için ehliyet yeterli değil. İhtiyaç duydukları şey, kapılara girmek için taradıkları bir Çalışan Rozeti. Bir yerlerde, Yönetici Rolünde en üst kata erişim rozetleri ve diğer odalara Çalışan Rolü erişiminde rozetler sağlayan bir RBAC sistemi vardır.
Herhangi bir nedenle belirli odaların Rol tarafından eklenmesi / kaldırılması gerekiyorsa, bu RBAC kullanılarak yapılabilir, ancak bu bir Talep için uygun değildir.
Yazılımdaki İzinler
Rolleri uygulamaya kodlamak kötü bir fikirdir. Bu donanım, Rolün amacını uygulamaya kodlar. Uygulamanın sahip olması gereken şey, Özellik İşaretleri gibi davranan İzinlerdir. Özellik Bayraklarının konfigürasyonla erişilebilir hale getirildiği yerlerde İzinler, Kullanıcının yerleştirildiği tüm Rollerden toplanan İzinlerin DISTINCT koleksiyonundan türetilen Kullanıcı Güvenlik Bağlamı tarafından erişilebilir hale getirilir. Ben buna "Etkili İzinler" diyorum. Uygulama yalnızca bir menü sunmalıdırÖzelliklere / eylemlere olası İzinler. RBAC sistemi, bu İzinleri Roller aracılığıyla Kullanıcılarla birleştirme işini yapmalıdır. Bu şekilde, Rollerin sabit kodlaması yoktur ve bir İznin değiştiği tek zaman kaldırıldığında veya yenisinin eklendiği zamandır. Yazılıma bir İzin eklendikten sonra asla değiştirilmemelidir. Yalnızca gerektiğinde kaldırılmalıdır (yani, yeni bir sürümde bir özellik sona erdiğinde) ve yalnızca yenileri eklenebilir.
Son bir not.
Verme ve Reddetme
Sağlam bir RBAC sistemi ve hatta bir CBAC sistemi Hibeler ve Redler arasında ayrım yapmalıdır.
Bir Rol için İzin eklemek, HİBE veya RED ile birlikte gelmelidir. İzinler işaretlendiğinde, VERİLEN tüm İzinler, Etkili İzinler Kullanıcılar listesine eklenmelidir. Tüm bu yapıldıktan sonra, REDDEDİLEN İzinler listesi, sistemin bu İzinleri Etkin İzinler listesinden kaldırmasına neden olmalıdır.
Bu, yöneticilerin bir konunun son İzinlerini "değiştirmesine" olanak tanır. İzinlerin doğrudan Kullanıcılara da eklenebilmesi en iyisidir. Bu şekilde, Yönetici Rolüne bir Kullanıcı ekleyebilir ve her şeye erişebilirler, ancak belki de Bayan Tuvaletine erişimi REDDETmek istersiniz çünkü Kullanıcı bir erkek. Dolayısıyla, erkek Kullanıcıyı Yönetici Rolüne eklersiniz ve Kullanıcı nesnesine DENY ile bir İzin eklersiniz, böylece yalnızca o Leydinin oda erişimini kaldırır.
Aslında, bu bir İddia için iyi bir aday olacaktır. Kullanıcının bir "cinsiyet = erkek" İddiası varsa, Yönetici Rolünde olmak tüm odalara erişim sağlar, ancak Hanımın tuvaleti ayrıca Cinsiyet = kadın Talep ve Erkekler tuvaleti Cinsiyet talep et = erkek gerektirir. Bu şekilde, tek bir yetkilendirme kuralı ile herkes için İddia yaptırımı bunu hallettiğinden, erkek Kullanıcılar için bir REDDET izni yapılandırmak zorunda kalmazsınız. Ancak her iki şekilde de yapılabilir.
Mesele şu ki, İzinlerin REDDEDİLMESİ, istisnalar uygulanabildiği için Rollerin yönetimini kolaylaştırır.
Aşağıda, RBAC modelini gösteren uzun zaman önce yaptığım bir şema var. Talepler için bir grafiğim yok, ancak bunların, nerede olurlarsa olsunlar Kullanıcılara eklenmiş nitelikler olduğunu hayal edebilirsiniz. Ayrıca, diyagram Grupları göstermiyor (bir noktada güncellemem gerekiyor).
Umarım bu yardımcı olur.
Bu, Yukarıda Anlatılan RBAC Şemasıdır
7 Nisan 2019'da güncelleme
@Brent'ten gelen geri bildirimlere dayanarak (teşekkür ederim) ... önceki cevaplara yapılan gereksiz referansları kaldırdı ve bu cevabı anlaşılabilir kılmak için @CodingSoft tarafından sağlanan "gece kulübü" metaforunun orijinal temelini açıkladı. diğer cevapları okumak için.