Rol Tabanlı Erişim Kontrolü (RBAC) ile ilgili eksiksiz kılavuz: İzin tasarımında ustalaşın, rol yönetimi ve pratik bir CMS uygulaması ile güvenli yetkilendirme sağlayın.
Uygulamanız için güvenli ve ölçeklenebilir bir yetkilendirme sistemi uygulamakta zorlanıyor musunuz? Rol Tabanlı Erişim Kontrolü (RBAC), kullanıcı izinlerini yönetmek için endüstri standardıdır, ancak bunu doğru bir şekilde uygulamak zor olabilir. Bu eğitim, gerçek bir İçerik Yönetim Sistemi (CMS) örneğini kullanarak sağlam bir RBAC sistemi nasıl oluşturulacağını gösterecektir.
Bu kılavuzu izleyerek, şunları öğreneceksiniz:
Bu eğitimin tam kaynak kodu GitHub adresinde mevcuttur.
Rol Tabanlı Erişim Kontrolü, kullanıcılara izin atamaktan daha fazlasıdır. Güvenliği sürdürülebilirlikle dengeleyen yapılandırılmış bir yetkilendirme yaklaşımı yaratmaktır.
RBAC Nedir hakkında Auth Wiki'de daha fazla bilgi edinebilirsiniz.
Uygulama sırasında takip edeceğimiz ana ilkeler şunlardır:
İnce taneli izinler, sisteminizde kullanıcıların ne yapabileceği üzerinde size kesin kontrol verir. "admin" veya "kullanıcı" gibi geniş erişim düzeyleri yerine, kullanıcıların kaynaklar üzerinde gerçekleştirebileceği belirli eylemleri tanımlarız. Örneğin:
read:articles - Sistem içerisindeki herhangi bir makaleyi görüntüleyincreate:articles - Yeni makaleler oluşturunupdate:articles - Mevcut makaleleri değiştirinpublish:articles - Makalelerin yayın durumunu değiştirinKaynak mülkiyeti, CMS'mizin yetkilendirme tasarımındaki temel bir kavramdır. RBAC farklı rollerin gerçekleştirebileceği eylemleri tanımlarken, mülkiyet erişim kontrolüne kişisel bir boyut katar:
update:articles izni olmadan bile, bir yazar kendi makalelerini düzenlemeye devam edebilirBu çift katmanlı yaklaşım (roller + mülkiyet), daha sezgisel ve güvenli bir sistem oluşturur. Yayımlar ve yöneticiler, rol izinleri aracılığıyla tüm içeriği yönetebilirken, yazarlar kendi çalışmaları üzerinde kontrol sahibi olurlar.
Öncelikle CMS'mizin çekirdek işlevselliğini API uç noktaları aracılığıyla tasarlamaya başlayalım:
Her bir uç nokta için erişim kontrolünün iki yönünü düşünmeliyiz:
Her uç nokta için erişimi nasıl ele alacağımız:
| Uç Nokta | Erişim kontrol mantığı |
|---|---|
| GET /api/articles | - list:articles izni olan herkes, veya yazarlar kendi makalelerini görebilir |
| GET /api/articles/:id | - read:articles izni olan herkes, veya makalenin yazarı |
| POST /api/articles | - create:articles izni olan herkes |
| PATCH /api/articles/:id | - update:articles izni olan herkes, veya makalenin yazarı |
| DELETE /api/articles/:id | - delete:articles izni olan herkes, veya makalenin yazarı |
| PATCH /api/articles/:id/published | - Sadece publish:articles izni olan kullanıcılar |
API erişim gereksinimlerimize dayanarak, bu izinleri tanımlayabiliriz:
| İzin | Açıklama |
|---|---|
| list:articles | Sistemdeki tüm makalelerin listesini görüntüleyin |
| read:articles | Herhangi bir makalenin tam içeriğini okuyun |
| create:articles | Yeni makaleler oluşturun |
| update:articles | Herhangi bir makaleyi tadil edin |
| delete:articles | Herhangi bir makaleyi silin |
| publish:articles | Yayın durumunu değiştirin |
Unutmayın, bu izinler yalnızca sizin sahip olmadığınız kaynaklara erişirken gereklidir. Makale sahipleri otomatik olarak:
read:articles gerekmez)update:articles gerekmez)delete:articles gerekmez)API ve izinlerimizi tanımladığımıza göre, bu izinleri mantıksal olarak gruplandıran roller oluşturabiliriz:
| İzin/Rol | 👑 Admin | 📝 Editör | ✍️ Yazar |
|---|---|---|---|
| Açıklama | Tüm içerik yönetimi için tam sistem erişimi | Tüm makaleleri görüntüleyebilir ve yayın durumunu kontrol edebilir | Sistemde yeni makaleler oluşturabilir |
| list:articles | ✅ | ✅ | ❌ |
| read:articles | ✅ | ✅ | ❌ |
| create:articles | ✅ | ❌ | ✅ |
| update:articles | ✅ | ❌ | ❌ |
| delete:articles | ✅ | ❌ | ❌ |
| publish:articles | ✅ | ✅ | ❌ |
Not: Yazarlar, rol izinlerinden bağımsız olarak kendi makaleleri için okuma/güncelleme/silme izinlerine sahiptir.
Her rol belirli sorumluluklarla tasarlanmıştır:
Bu rol yapısı açık bir iş dağılımı yaratır:
Öncelikle, Logto Cloud üzerinde bir hesap oluşturmanız veya Logto OSS sürümünü kullanarak bir kendi barındırılan Logto instance'ı kullanmanız gerekmektedir.
Ancak bu eğitim için basitlik adına Logto Cloud'u kullanacağız.
list:articlesread:articlescreate:articlesupdate:articlespublish:articlesdelete:articles
CMS için Logto Konsolunda Rollere giderek aşağıdaki rolleri oluşturun
read:articles, list:articles, publish:articles ilecreate:articles ile
Logto Konsolunda "Kullanıcı yönetimi" bölümüne giderek kullanıcılar oluşturun.
Kullanıcı detaylarının "Roller" sekmesinde, kullanıcıya roller atayabilirsiniz.
Örneğimizde, şu rollerle 3 kullanıcı oluşturuyoruz:
Artık Logto'da RBAC yapılandırdık, bunu frontend'imize entegre etmeye başlayabiliriz.
Öncelikle, uygulamanıza Logto entegrasyonu için Logto Hızlı Başlangıçlarını izleyin.
Örneğimizde, gösterim için React kullanıyoruz.
Uygulamanızdan Logto'yu yapılandırdıktan sonra, Logto'nun çalışması için RBAC yapılandırmalarını eklememiz gerekiyor.
Zaten oturum açtıysanız, bu değişikliğin etkili olması için oturumu kapatıp tekrar oturum açmayı unutmayın.
Kullanıcı, yukarıda belirtilen API kaynaklarına erişim jetonu talep ederek Logto ile giriş yaptığında, Logto, kullanıcının rolüyle ilgili kapsamları (izinleri) erişim jetonuna ekleyecektir.
Erişim jetonundan kapsamları almak için useLogto hookundan getAccessTokenClaims'i kullanabilirsiniz.
Ve userScopes'u kullanarak kullanıcının kaynağa erişim iznine sahip olup olmadığını kontrol edebilirsiniz.
Şimdi, Logto RBAC'i backend'inize entegre etme zamanı.
İlk olarak, kullanıcı izinlerini kontrol etmek, kullanıcının oturum açıp açmadığını doğrulamak ve belirli API'lere erişmek için gerekli izinlere sahip olup olmadığını belirlemek için bir middleware eklememiz gerekiyor.
Gördüğünüz gibi, bu arabirimde, frontend isteğinin geçerli bir erişim belirteci içerip içermediğini doğruluyoruz ve erişim jetonunun hedef kitlesinin Logto Konsolunda oluşturduğumuz API kaynağıyla eşleşip eşleşmediğini kontrol ediyoruz.
API kaynağını doğrulamanın nedeni, API kaynağımız aslında CMS backend'imizin kaynaklarını temsil eder ve tüm CMS izinlerimiz bu API kaynağı ile ilişkilendirilmiştir.
Bu API kaynağı Logto'da CMS kaynaklarını temsil ettiğinden, frontend kodumuzda API isteklerini backend'e yaparken ilgili Erişim jetonunu ekleriz:
Artık requireAuth middleware'ini API uç noktalarımızı korumak için kullanabiliriz.
Belirli izinlere sahip kullanıcılar için yalnızca erişilebilir olması gereken API'lar için, kısıtlamaları doğrudan arabirimde ekleyebiliriz. Örneğin, makale oluşturma API'si yalnızca create:articles iznine sahip kullanıcılar için erişilebilir olmalıdır:
Hem izinleri hem de kaynak mülkiyetini kontrol etmesi gereken API'ler için hasScopes işlevini kullanabilirsiniz. Örneğin, makale listeleme API'sinde, list:articles iznine sahip kullanıcılar tüm makalelere erişebilirken, yazarlar sadece kendi oluşturdukları makalelere erişebilir:
Bu noktada, RBAC uygulamasını tamamladık. Tam uygulamayı görmek için tam kaynak kodunu inceleyebilirsiniz.
Şimdi, oluşturduğumuz üç kullanıcıyı kullanarak CMS RBAC uygulamamızı test edelim.
Önce, Alex ve Charles olarak oturum açalım ve bazı makaleler oluşturalım.
Alex, Admin rolüne sahip olduğundan, tüm makaleleri oluşturabilir, silebilir, güncelleyebilir, yayınlayabilir ve görüntüleyebilir.
Charles, Yazar rolüne sahip olduğundan, yalnızca kendi makalelerini oluşturabilir ve yalnızca sahip olduğu makaleleri görüntüleyebilir, güncelleyebilir ve silebilir.
Bob, Editör rolüne sahip olup tüm makaleleri görüntüleyip yayımlayabilir ama oluşturan, güncelleyip silme yeteneğine sahip değildir.
Tebrikler! Uygulamanızda sağlam bir RBAC sistemi nasıl uygulanacağını öğrendiniz.
Daha karmaşık senaryolar için, örneğin çok kiracılı uygulamalar oluşturmak gibi, Logto kapsamlı organizasyon desteği sağlamaktadır. Organizasyon çapında erişim kontrolü uygulamak hakkında daha fazla bilgi edinmek için Çok Kiracılı SaaS uygulaması kurma: Tasarımdan uygulamaya eksiksiz bir kılavuz rehberimizi inceleyin.
Kodlamalarınızda başarılar! 🚀