Kavramlar, Fikirler, Stratejiler
Kavramlar, Fikirler, StratejilerErişim Kontrolü Yoluyla Yetkilendirme

Erişim Kontrolü Yoluyla Yetkilendirme

Yetkilendirme, web uygulamasının farklı bölümlerine ve kaynaklarına kullanıcılara erişim izni verme sürecidir. Kullanıcıları yetkilendirmenin yaygın bir yolu erişim kontrolüdür; bu yöntemde site yöneticisi, kullanıcıların ve diğer varlıkların hangi kaynaklara erişebilmesi için hangi izinlerin verilmesi gerektiğini tanımlar.

Yetkilendirme, kimlik doğrulamayla karıştırılmamalıdır. Kimlik doğrulama, kullanıcının iddia ettiği kişi olduğunu genellikle hesap kimlik bilgileri sağlayarak doğrulama sürecidir. Kullanıcının kimliği doğrulandıktan sonra, kullanıcının istenen kaynağa erişimi olduğundan emin olmak için yetkilendirme süreci her istekte yeniden gerçekleştirilmelidir.

Uygulamaya GraphQL aracılığıyla erişildiğinde, kullanıcının şemadan istenen öğelere erişim iznine sahip olup olmadığını doğrulamamız gerekir. Yetkilendirme mantığı GraphQL katmanında mı kodlanmalıdır?

Cevap hayır. graphql.org'daki belgelerin de açıkça belirttiği gibi, yetkilendirme mantığı iş mantığı katmanına aittir ve GraphQL buradan erişir. Bu sayede uygulama, yetkilendirme için tek bir gerçek kaynağına sahip olabilir (yani WordPress'in sunduğu):

Uygulama diyagramı

Gato GraphQL bu ilkeye saygı göstererek WordPress tarafından sağlanan yetkilendirme mekanizmasını yansıtır (ve motor altında ona devreder).

Erişim Kontrolü Politikaları

Uygulamamız için uygulayabileceğimiz çeşitli erişim kontrolü politikaları arasında en yaygın ikisi Rol Tabanlı Erişim Kontrolü (RBAC) ve Öznitelik Tabanlı Erişim Kontrolü (ABAC)'dır.

WordPress ve Gato GraphQL her ikisini de destekler.

Rol Tabanlı Erişim Kontrolü ile izinleri rollere göre veririz, ardından rolleri kullanıcılara atarız. Örneğin WordPress'te tüm kaynaklara erişimi olan bir administrator rolü ve bir blog yazısı oluşturup yayınlayabilme, yalnızca oluşturabilme veya yalnızca okuyabilme gibi değişen derecelerde kısıtlı izinlere sahip editor, author, contributor ve subscriber rolleri bulunur.

Öznitelik Tabanlı Erişim Kontrolü ile izinler, kullanıcılar, kaynaklar ve ortam koşulları (günün saati veya ziyaretçinin IP adresi gibi) dahil farklı varlıklara atanabilen meta verilere göre verilir. Örneğin WordPress'te edit_others_posts yeteneği, kullanıcının diğer kullanıcıların yazılarını düzenleyip düzenleyemeyeceğini doğrulamak için kullanılır.

Genel anlamda, ABAC, RBAC'a tercih edilir çünkü izinleri ince taneli kontrolle yapılandırmamızı sağlar ve iznin amacı açıktır.

Örneğin WordPress'te editor rolü edit_others_posts yeteneğine sahiptir, ancak author rolündeki bir kişinin başka bir yazarın yazısını düzenlemesine izin vermek isteyebiliriz; bunu yaparken editöre verilen tüm izin kümesini (diğer yazarların yazılarını silme gibi) vermek istemeyebiliriz. Bu nedenle, edit_others_posts yeteneğini vermek ve bu koşulu kontrol etmek, editor rolünü kontrol etmekten daha uygundur.

Görünürlüğü Tanımlama

Kullanıcı, GraphQL şemasından istenen alana erişim iznine sahip olmadığında, döndürülen hata ne olmalıdır?

Şema için istenen görünürlüğe uygun olarak iki olasılık vardır: genel veya özel.

Genel şemada, açıklanan GraphQL şeması tüm kullanıcılar için aynıdır ve her alan erişim için hangi izinlerin gerektiğini açıklar. Erişilemeyen bir alan istendiğinde, hata mesajı kullanıcıya neden erişim verilmediğini açıklar.

Genel şema: Alana erişim başarısız olduğunda hata mesajı nedeni açıklar

Özel şemada, GraphQL şeması her kullanıcıya göre özelleştirilir ve yalnızca erişebildiği alanlar gösterilir. Erişilemeyen bir alan istendiğinde, hata mesajı alanın mevcut olmadığını belirtir.

Özel şema: Alan şemada mevcut değil

Kullanıcı Arayüzü Aracılığıyla Erişim Kontrolü

Gato GraphQL'de erişim kontrolü kuralları, access control list'ler aracılığıyla kullanıcı tanımlı yapılandırma olarak çalışma zamanında şemaya enjekte edilir. Bu sayede GraphQL katmanı, herhangi bir kod güncellemesine veya şemanın yeniden derlenmesine gerek kalmadan erişim kontrolü politikasındaki değişiklikleri anında yansıtır:

Kullanıcı arayüzü aracılığıyla erişim kontrolü

Site yöneticisi ACL'yi şunları seçerek yapılandırır:

  • Doğrulanacak alanlar
  • Doğrulanacak bir kural, şunlar arasından:
    • kullanıcı oturum açmış olmalı mı?
    • kullanıcı oturum kapatmış olmalı mı?
    • kullanıcının belirli bir rolü olmalı mı?
    • kullanıcının belirli bir yeteneği olmalı mı?
  • Kurala özgü yapılandırma:
    • hangi roller?
    • hangi yetenekler?
  • Görünürlük:
    • varsayılan (yani şemaya atanan)?
    • genel?
    • özel?

Bir access control list yapılandırma