## Arka Plan [Önceki makalede](/ciam-101-intro-authn-sso/), kimlik doğrulama (AuthN) ve yetkilendirme (AuthZ) kavramlarını tanıttık, baş ağrısı yaratan bazı terimlerle birlikte: Kimlik, Organizasyon, Tenant, vb. Organizasyon ve Tenant, Kimlikleri gruplamak için harikadır, ancak bunlar kesin bir demokrasiye yol açar: herkes bu sistemde her şeyi yapabilir. Ütopya hala bir gizemken, erişimin yönetimine bir bakış atalım: Yetkilendirme (AuthZ). ### Neden yetkilendirmeye ihtiyacımız var? Yetkilendirme (AuthZ), "Ne yapabilirsin?" sorusunu cevaplar Notion harika bir örnektir. Sahip olduğunuz her sayfayı, yalnızca size özel tutabilir, arkadaşlarınızla paylaşabilir veya halka açabilirsiniz. Veya, bir çevrimiçi kitapçı için, herkesin tüm kitapları görüntülemesini, ancak müşterilerin sadece kendi siparişlerini görüntülemesini ve satıcıların sadece kendi mağazalarındaki kitapları yönetmesini istersiniz. AuthZ ve AuthN, karmaşık bir iş modelinin temel bileşenleridir. Çoğu zaman el ele giderler; AuthZ bir kullanıcının erişimini doğrular, AuthN ise kimlikleri doğrular. Her ikisi de güvenli bir sistem için gereklidir. ## Temel yetkilendirme modeli İşte en yaygın AuthZ modellerinden biri: Eğer **KİMLİK** **EYLEM** gerçekleştirirse **KAYNAK** üzerinde, o zaman **KABUL** veya **RED**. Notion örneğinde, model şu şekildedir: **KİŞİ** **GÖRÜNTÜ** gerçekleştirir **SAYFASI** üzerinde. Eğer sayfa özel ise: - Kendi **SAYFANIZ** üzerinde **GÖRÜNTÜ** gerçekleştirirken **KABUL** alırsınız. - Diğer herkesin, sizin **SAYFANIZ** üzerinde **GÖRÜNTÜ** gerçekleştirirken **RED** alması gerekir. Bazılarına göre, sektör Rol Tabanlı Erişim Kontrolü (RBAC), Özellik Tabanlı Erişim Kontrolü (ABAC) gibi çeşitli yetkilendirme teknolojileri geliştirdi. Bugün, [NIST RBAC modeli](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) Seviye 1: Düz RBAC üzerinde duracağız. ## Rol Tabanlı Erişim Kontrolü NIST RBAC modeli, çeşitli senaryolarda esneklik ve uyumluluk sağlamak için birçok şeyi açık bıraktı. Logto şimdi, "Kaynak" (yani API Kaynağı) adı verilen ek bir kavramla 1. Seviye tanımını benimser. Kitapçı örneğini genişletelim. Diyelim ki birçok müşterimiz var ama yalnızca bir satıcımız var: - Müşteriler kitapları görüntüleyebilir ve sipariş verebilir, ayrıca kendi siparişlerini görüntüleyebilirler. - Satıcı kitapları görüntüleyebilir, oluşturabilir ve silebilir, müşteri siparişlerini yönetebilir. ### Kaynaklarını tanımla Logto'da, bir kaynak (yani API Kaynağı) genellikle bir varlık kümesini veya öğeleri temsil eder, çünkü geçerli bir URL kullanmak gereklidir. Bu yüzden iki kaynak tanımlıyoruz: - Kitaplar: `https://api.bookstore.io/books` - Siparişler: `https://api.bookstore.io/orders` URL biçimini zorlama avantajlarından biri, URL'nin sistemin diğer bileşenleriyle entegrasyon sırasında okunabilirliği ve tanınabilirliği artırmasıdır. 🤔 Kaynaklar, işletmenin ihtiyaçlarına göre bölünmelidir. Her duruma uyan bir yöntem yoktur; karar duruma göre verilmelidir. Bu makaledeki örnekte Kitapları ve Siparişleri bölmek, mikro hizmetler için uygun olabilir, ancak monolitik bir mimari için uygun olmayabilir. ### Yetkileri tanımlar Kaynak kavramını tanıttığımızdan beri, Logto'da, yetkilerin bir kaynağa ait olması gerektiğini, tersine, kaynakların yetkileri olabileceğini belirttik. Şimdi, kaynaklara bazı yetkiler ekleyelim: - Kitaplar: `okuma`, `oluşturma`, `silme` - Siparişler: `okuma`, `kendine:okuma`, `kendine:oluşturma`, `silme` Bir yetkinin adı konusunda hiçbir gereklilik olmamakla birlikte, aşağıdaki sözleşmeyi benimseriz: ``` [:] ``` Bir yetkiyi tanımlamak için `` gerekliyken, `:` genel bir hedefi tanımlamak için yok sayılabilir, yani kaynadaki tüm varlıklar veya öğelere. ## Uygulamada Teorinin yanı sıra, modelin beklendiği gibi çalışması için ağır teknik çalışmaları tamamlamamız gerekiyor: - İstemci ve yetki sunucusu geliştirmesi - RBAC için veritabanı tasarımı - Farklı hizmetler arası doğrulama - Güvenlik ve açık standart uyumluluğu - Rol, yetki, kaynak yönetimi ve atama Ping examples: - Alice satılık yeni bir kitap eklemek ister: - Kullanıcı Alice, Kitaplar kaynağında (`https://api.bookstore.io/books`) `oluşturma` işlemini gerçekleştirir. - Alice'nin `satıcı` rolüne göre Kitapların `oluşturma` yetkisine sahip olduğuna göre sonuç ✅ **KABUL**'dır. - Alice tüm siparişleri görüntülemek ve satışın beklentilerini karşılayıp karşılamadığını görmek ister: - Kullanıcı Alice, Siparişler kaynağında (`https://api.bookstore.io/orders`) `okuma` işlemini gerçekleştirir. - Alice'nin `satıcı` rolüne göre Siparişlerin `okuma` yetkisine sahip olduğuna göre sonuç ✅ **KABUL**'dır. - Bob kitap listesine göz atmak ve satın almak istediği herhangi bir kitap olup olmadığını görmek ister. - Kullanıcı Bob, Kitaplar kaynağında (`https://api.bookstore.io/books`) `okuma` işlemini gerçekleştirir. - Bob'un `müşteri` rolüne göre Kitapların `okuma` yetkisine sahip olduğuna göre sonuç ✅ **KABUL**'dır. - Bob, Carol’un siparişini görüntülemek ister. - Bu başkasının siparişi olduğu için, `Siparişler`in `kendine:okuma` yetkisi burada işe yaramaz. - Kullanıcı Bob, Siparişler kaynağında (`https://api.bookstore.io/order`) `okuma` işlemini gerçekleştirir. - Bob'un Siparişlerin `okuma` yetkisi olmadığına göre sonuç ❌ **RED**'dir. ### Diğer RBAC seviyeleri NIST RBAC modelinde dört seviye vardır: - Düz RBAC - Hiyerarşik RBAC - Kısıtlı RBAC - Simetrik RBAC İlgileniyorsanız detaylar için [makaleye](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) bakınız. Logto şu anda 1. Seviye uygulamasına sahip ve topluluk geri bildirimine dayalı olarak daha yüksek seviyelere ilerleyecektir. Daha yüksek bir seviyenin ihtiyaçlarınıza uygun olduğunu bize bildirmekten çekinmeyin! ## Uygulamada Teorinin yanı sıra, modelin beklendiği gibi çalışması için ağır teknik çalışmaları tamamlamamız gerekiyor: - İstemci ve yetkilendirme sunucusu geliştirme - RBAC için veritabanı tasarımı - Farklı hizmetler arası doğrulama - Güvenlik ve açık standart uyumluluğu - Rol, izin, kaynak yönetimi ve atama Endişelenmeyin. Bunu göz önünde bulundurduk ve tüm bunları kapsayacak şekilde kutudan çıkar desteği ekledik. RBAC'nin Logto'da nasıl kullanılacağını öğrenmek için [🔐 RBAC tarifini](https://docs.logto.io/docs/recipes/rbac/) kontrol edin. ## Kapanış notları RBAC, çoğu durum için güçlü bir erişim yönetimi modelidir, ancak gümüş bir kurşun yoktur. Hala bazı sorularımız var: - Yüksek RBAC seviyelerine ihtiyacım var mı? - RBAC diğer yetkilendirme modelleriyle nasıl karşılaştırılır? - Farklı Organizasyonlar arasında yetkilendirme modeli nasıl tanımlanır? 🔥 Takipte kalın. CIAM 103'te görüşmek üzere!