openFGA ve Go Sunucularında RBAC: Erişim Kontrolünü Yeniden Tanımlamak

Modern uygulama geliştirme dünyasında, kullanıcıların sistem üzerindeki yetkilerini yönetmek giderek daha karmaşık bir hal alıyor. Özellikle mikroservis mimarileri ve dağıtık sistemlerin yaygınlaşmasıyla birlikte, erişim kontrolü artık basit if-else bloklarıyla halledilebilecek bir konu olmaktan çıktı. Peki, bu karmaşıklığın üstesinden nasıl gelebiliriz? openFGA ve Go dilinin gücünü birleştirerek, dinamik ve ölçeklenebilir bir Role-Based Access Control (RBAC) sistemi kurmanın yollarını keşfedeceğiz. Bu makale, yetkilendirme konusundaki temel kavramlardan başlayarak, gerçek dünya senaryolarıyla adım adım openFGA entegrasyonunu Go sunucularında nasıl gerçekleştireceğinizi açıklayacak.

Bir web uygulaması geliştirdiğinizde veya mevcut bir sistemi yönettiğinizde, kullanıcılarınızın neye erişebileceğini, hangi eylemleri gerçekleştirebileceğini belirlemek kritik önem taşır. Bu süreç, yetkilendirme (authorization) olarak adlandırılır. Geleneksel olarak, birçok uygulama Rol Tabanlı Erişim Kontrolü (RBAC) modelini benimsemiştir. RBAC, kullanıcıları belirli rollere (örneğin, ‘Yönetici’, ‘Editör’, ‘Görüntüleyici’) atar ve bu rollere belirli izinler tanımlar. İlk bakışta oldukça mantıklı ve sade görünen bu yaklaşım, uygulamanızın büyüdükçe ve gereksinimleri karmaşıklaştıkça ciddi sorunlar yaratmaya başlayabilir.

Bir düşünün: Bir doküman yönetim sisteminiz var. Başlangıçta yalnızca yöneticiler, editörler ve okuyucular yeterliydi. Ancak zamanla “proje liderleri”, “taslak onaylayıcılar” veya “harici iş ortakları” gibi yeni roller ortaya çıktı. Dahası, her dokümanın kendi özel izinleri olabilir; bir doküman “herkese açık” olabilirken, diğeri sadece belirli bir “takım” üyeleri tarafından görüntülenebilir. Geleneksel RBAC modelleri, bu tür ince taneli (fine-grained) yetkilendirme ihtiyaçlarını karşılamakta zorlanır. Rol sayısı katlanarak artar (role explosion), her bir yeni durum için yeni bir rol tanımlamak bir yönetim kabusuna dönüşür. Bu durum, sadece yönetim yükünü artırmakla kalmaz, aynı zamanda sistemin güvenlik açıklarına karşı daha savunmasız hale gelmesine de neden olabilir, çünkü yetki tanımları iç içe geçerek anlaşılması ve denetlenmesi güç bir hal alır.

Mikroservis mimarileri, bu sorunu daha da derinleştirir. Her servis kendi içinde yetkilendirme mantığını barındırdığında, tutarsızlıklar ve güvenlik açıkları kaçınılmaz hale gelir. Kullanıcı deneyimi açısından da bu durum sıkıntılıdır; bir kullanıcının farklı servislerdeki yetkileri arasında tutarlılık sağlamak, geliştiriciler için sürekli bir baş ağrısıdır. İşte tam da bu noktada, yetkilendirme mantığını uygulamanın ana kod tabanından ayırarak merkezi bir şekilde yönetme ihtiyacı doğar. Bu merkeziyetçi yaklaşım, yetkilendirme kararlarını hızlı, tutarlı ve ölçeklenebilir bir şekilde almayı mümkün kılar. openFGA gibi araçlar, bu zorlukların üstesinden gelmek için geliştirilmiş güçlü çözümler sunar. Geleneksel RBAC’ın ötesine geçerek, nesneler ve aralarındaki ilişkiler üzerinden yetkilendirme yapabilen ReBAC (Relationship-Based Access Control) modelini benimseyen openFGA, modern uygulamaların dinamik ve karmaşık erişim kontrolü gereksinimlerine cevap verir. Bu sayede, “kim, ne üzerinde, ne yapabilir?” sorusunun cevabı, uygulamanızın iş mantığından bağımsız olarak, esnek bir şekilde tanımlanabilir ve yönetilebilir.

RBAC Nedir ve Neden Artık Yeterli Değil?

Rol Tabanlı Erişim Kontrolü (RBAC), uzun yıllardır yazılım sistemlerinde yetkilendirme için standart bir model olmuştur. Temelinde üç ana kavram yatar:

• Kullanıcılar (Users): Sisteme erişen bireyler veya varlıklar.
• Roller (Roles): Bir dizi izin kümesini temsil eden ve kullanıcılara atanan soyut etiketler (örneğin, ‘Admin’, ‘Muhasebeci’, ‘Müşteri Temsilcisi’).
• İzinler (Permissions): Kullanıcının belirli bir kaynak üzerinde gerçekleştirebileceği eylemler (örneğin, ‘belgeyi düzenle’, ‘raporu görüntüle’, ‘kullanıcı oluştur’).

RBAC’ın işleyişi oldukça basittir: Bir kullanıcıya bir veya birden fazla rol atanır. Her rol, belirli izin setlerini içerir. Kullanıcı bir eylem gerçekleştirmeye çalıştığında, sistem kullanıcının sahip olduğu rollerin ilgili izne sahip olup olmadığını kontrol eder. Örneğin, ‘Editör’ rolüne sahip bir kullanıcı ‘yazı düzenleme’ iznine sahipse, bu eylemi gerçekleştirebilir.

RBAC’ın Sınırlılıkları: Neden Yetmez?

RBAC’ın sadeliği, aynı zamanda onun en büyük kısıtlamasıdır. Uygulamanız büyüdükçe ve daha dinamik hale geldikçe, RBAC’ın yetersizlikleri ortaya çıkmaya başlar:

1. Rol Patlaması (Role Explosion): Uygulama, farklı nesneler (belgeler, projeler, takımlar vb.) üzerinde farklı düzeylerde yetkilendirme gerektirdiğinde, yeni roller yaratma ihtiyacı doğar. Örneğin, “Proje A Yöneticisi”, “Proje B Yöneticisi”, “Proje A Editörü” gibi roller tanımlamak zorunda kalırsınız. Bu, yüzlerce, hatta binlerce role yol açarak yönetimi içinden çıkılmaz bir hale getirir.
2. İnce Taneli Yetkilendirme Eksikliği (Lack of Fine-Grained Authorization): RBAC, genellikle sistem genelinde veya belirli modüller üzerinde yetkilendirme yapar. Ancak “Bu belirli belgeyi yalnızca şu kişi düzenleyebilir” veya “Bu dosyayı sadece bu departmandaki çalışanlar görebilir” gibi nesne düzeyinde, koşullu veya bağlama dayalı (context-aware) yetkilendirme yapmak zordur.
3. Dinamik İlişkiler: Gerçek dünyadaki yetkilendirme modelleri genellikle kullanıcılar, gruplar ve nesneler arasındaki karmaşık ilişkilere dayanır. Örneğin, “bir klasörün sahibi, o klasördeki tüm belgelerin de sahibidir.” Bu tür türemiş (derived) ilişkileri RBAC ile modellemek neredeyse imkansızdır ve manuel olarak yönetmek büyük bir hata riskini beraberinde getirir.
4. Çoklu Kiracılık (Multi-Tenancy) Sorunları: Birden fazla müşterinin (kiracının) aynı platformu kullandığı SaaS (Software as a Service) uygulamalarında, her kiracının kendi içinde benzersiz roller ve izinlere sahip olması gerekir. RBAC, her kiracı için ayrı bir rol matrisi oluşturmayı gerektirebilir ki bu da ölçeklenebilirlik açısından büyük bir sorun teşkil eder.
5. Yönetim ve Denetim Zorluğu: Rol sayısı ve karmaşıklığı arttıkça, bir kullanıcının belirli bir kaynağa neden erişebildiğini veya erişemediğini anlamak zorlaşır. Bu da güvenlik denetimlerini ve sorun gidermeyi güçleştirir.

Bu sınırlılıklar, modern uygulamaların Fine-Grained Authorization (İnce Taneli Yetkilendirme) veya Relationship-Based Access Control (İlişki Tabanlı Erişim Kontrolü – ReBAC) gibi daha esnek ve güçlü modellere yönelmesini gerektirir. openFGA, tam da bu noktada devreye girerek, Google’ın Zanzibar makalesinden ilham alan bir yaklaşımla, nesneler ve kullanıcılar arasındaki ilişkiler üzerine kurulu, ölçeklenebilir ve yönetilebilir bir yetkilendirme motoru sunar. Bu sayede, RBAC’ın sağladığı basitliği korurken, aynı zamanda dinamik ve ince taneli yetkilendirme ihtiyaçlarını da karşılayabiliriz.

openFGA Nedir ve Neden Bir Yetkilendirme Motoruna İhtiyacımız Var?

Geleneksel RBAC’ın karşılaştığı zorlukların ve modern uygulamaların dinamik yetkilendirme gereksinimlerinin bir sonucu olarak, yetkilendirme mantığını uygulamanın ana kod tabanından ayırma fikri giderek daha popüler hale geldi. İşte tam da bu ihtiyaca cevap veren güçlü araçlardan biri openFGA’dır. openFGA, Auth0 FGA’nın açık kaynaklı bir versiyonu olup, Google’ın çığır açan Zanzibar: A Comprehensive System for Authorization from Google makalesinde açıklanan prensipleri temel alarak geliştirilmiştir. Kısacası, openFGA, “kimin neye erişimi var?” sorusunu merkezi ve ölçeklenebilir bir şekilde cevaplamak için tasarlanmış, ilişki tabanlı (ReBAC) bir yetkilendirme motorudur.

Neden Bir Yetkilendirme Motoruna İhtiyacımız Var?

Yetkilendirme mantığını uygulamanızın her yerine dağıtmak yerine, neden harici bir yetkilendirme motoruna güvenmelisiniz? İşte temel nedenler:

• Tek Yetki Kaynağı (Single Source of Truth): Tüm yetkilendirme kurallarınızı ve ilişkilerinizi tek bir yerde tanımlamak, yönetmek ve denetlemek, tutarsızlıkları önler ve güvenlik duruşunuzu güçlendirir.
• Ölçeklenebilirlik ve Performans: Yetkilendirme motorları, yüksek hacimli yetki sorgularını düşük gecikmeyle işlemek üzere optimize edilmiştir. Uygulamanızın her mikroservisinde yetkilendirme mantığını yeniden yazmak yerine, merkezi bir motor bu yükü üstlenir.
• Esneklik ve Dinamizm: openFGA’nın ilişki tabanlı modeli, statik rollere bağlı kalmaksızın, nesneler ve kullanıcılar arasındaki dinamik ilişkiler üzerinden yetkilendirme yapılmasına olanak tanır. Bu, uygulamanızın iş mantığı değiştikçe yetkilendirme kurallarını kolayca adapte etmenizi sağlar.
• Geliştirici Verimliliği: Geliştiricilerin her seferinde yetkilendirme mantığını baştan tasarlamasına gerek kalmaz. Sadece “bu kullanıcı bu nesneye erişebilir mi?” diye sormak yeterlidir. Bu, kod tekrarını azaltır ve geliştirme sürecini hızlandırır.
• Güvenlik ve Denetlenebilirlik: Merkezi bir yetkilendirme motoru, tüm erişim kararlarının loglanmasını ve denetlenmesini kolaylaştırır. Bu, uyumluluk gereksinimlerini karşılamanıza ve güvenlik açıklarını daha hızlı tespit etmenize yardımcı olur.

openFGA’nın Temel Kavramları

openFGA’nın kalbinde, yetkilendirme modelinizi tanımlayan basit ama güçlü kavramlar bulunur:

• Yetkilendirme Modeli (Authorization Model – DSL): openFGA, ilişkilerinizi tanımlamak için kendi Alan Özel Dilini (DSL) kullanır. Bu model, hangi “türlerin” (type) olduğunu (örneğin, user, document, folder) ve bu türler arasında hangi “ilişkilerin” (relation) var olabileceğini (örneğin, owner, editor, viewer) belirtir.

  
                  schema 1.1
  
                  type user
  
                  type document
                    relations
                      define editor: [user, group#member] or owner
                      define viewer: [user, group#member] or editor
  
                  type folder
                    relations
                      define owner: [user]
                      define editor: [user, group#member] or owner
                      define viewer: [user, group#member] or editor
                    relations
                      define parent: [folder]
              

  Yukarıdaki örnekte, bir document'ın hem doğrudan bir user veya group#member tarafından editor olabileceği, hem de bir owner ilişkisinden bu yetkiyi miras alabileceği tanımlanmıştır. Bu DSL, yetkilendirme mantığınızı son derece esnek bir şekilde modellemenizi sağlar.

• İlişki Demetleri (Relation Tuples): Bunlar, sistemdeki gerçek ilişkileri temsil eden verilerdir. Örneğin, user:alice'ın document:roadmap üzerinde editor olduğunu belirtmek için { "user": "user:alice", "relation": "editor", "object": "document:roadmap" } şeklinde bir ilişki demeti depolarsınız. openFGA, bu demetleri depolayarak ve sorgulayarak yetkilendirme kararlarını verir.
• Kontrol API'si (Check API): Bir kullanıcının belirli bir eylemi gerçekleştirip gerçekleştiremeyeceğini sorgulamak için kullanılır. Örneğin, Check(user:alice, "viewer", document:roadmap) sorgusu, Alice'in "roadmap" dokümanını görüntüleyip görüntüleyemeyeceğini kontrol eder.
• Yazma API'si (Write API): Yeni ilişki demetleri oluşturmak veya mevcut olanları silmek için kullanılır. Uygulamanızdaki kullanıcılar, roller ve nesneler arasındaki ilişkiler değiştikçe (örneğin, "Alice, roadmap dokümanının editörü oldu"), bu API'yi kullanarak openFGA'ya bu değişiklikleri bildirirsiniz.

openFGA'nın bu temel taşları, dağıtık sistemler için ölçeklenebilir, performanslı ve tutarlı bir yetkilendirme çözümü sunar. Artık yetkilendirme mantığı, uygulamanın işlevselliğinden ayrı, özel bir servis olarak ele alınabilir ve yönetilebilir.

Go Sunucusunda openFGA ile RBAC Nasıl Uygulanır: Adım Adım Rehber

Go, yüksek performansı ve eşzamanlılık yetenekleri sayesinde modern backend uygulamaları geliştirmek için popüler bir dildir. openFGA'yı Go sunucularınıza entegre etmek, yetkilendirme mantığını uygulamanızdan ayırarak daha temiz, ölçeklenebilir ve yönetilebilir bir kod tabanı oluşturmanızı sağlar. Şimdi, adım adım bu entegrasyonu nasıl gerçekleştireceğimize bakalım.

1. Ön Hazırlık: openFGA Sunucusunu Çalıştırma

openFGA, ayrı bir servis olarak çalıştığından, öncelikle bir openFGA sunucusu çalıştırmanız gerekir. En kolay yol Docker kullanmaktır:

        docker pull openfga/openfga:latest
        docker run -p 8080:8080 -p 8081:8081 openfga/openfga:latest
    

Bu komut, openFGA sunucusunu 8080 (HTTP) ve 8081 (gRPC) portlarında çalıştıracaktır. Genellikle gRPC API'sini kullanmak, daha iyi performans ve tip güvenliği sağlar. Go SDK'sı gRPC istemcisini kullanır.

2. Go SDK Entegrasyonu

Go projenize openFGA SDK'sını ekleyin:

        go get github.com/openfga/go-sdk/client
    

Daha sonra, Go kodunuzda bir openFGA istemcisi oluşturun:

        package main

        import (
            "context"
            "fmt"
            "log"

            ofga "github.com/openfga/go-sdk/client"
            "github.com/openfga/go-sdk/credentials"
        )

        func main() {
            ctx := context.Background()

            // openFGA sunucusu bağlantı ayarları
            config := ofga.ClientConfiguration{
                ApiUrl:  "http://localhost:8080", // Veya gRPC için "localhost:8081" ve Scheme: "grpc"
                StoreId: "01H2144Y1J322A0H1Z0G6X85G3", // Kendi Store ID'nizi kullanın
                Auth:    &credentials.Credentials{Method: credentials.None}, // Kimlik doğrulama ayarları (örneğin, None, Bearer, ClientCredentials)
            }

            fgaClient, err := ofga.NewClient(config)
            if err != nil {
                log.Fatalf("openFGA istemcisi oluşturulamadı: %v", err)
            }

            fmt.Println("openFGA istemcisi başarıyla oluşturuldu!")

            // Store ID'yi almak için:
            // Bir defalık bir işlem olarak, Store ID'nizi openFGA API'si üzerinden oluşturabilirsiniz.
            // Örneğin: curl -X POST http://localhost:8080/stores --data-raw '{}'
            // veya SDK ile:
            // response, err := fgaClient.CreateStore(ctx).Execute()
            // if err != nil { /* ... */ }
            // fmt.Printf("Yeni Store ID: %s\n", *response.Id)
        }
    

StoreId, yetkilendirme modelinizin ve ilişkilerinizin depolandığı mantıksal bir alandır. Her uygulamanın genellikle kendi Store ID'si olur. Eğer ilk kez kullanıyorsanız, yukarıdaki curl komutu veya SDK ile yeni bir Store oluşturmanız gerekebilir.

3. Yetkilendirme Modelini Tanımlama ve Yükleme

DSL (Domain Specific Language) ile yetkilendirme modelinizi tanımlayın. Örneğin, bir belge yönetim sistemi için basit bir model:

        schema 1.1

        type user

        type document
          relations
            define viewer: [user, group#member] or owner
            define editor: [user, group#member] or owner or viewer
            define owner: [user]
    

Bu modeli Go koduyla openFGA sunucusuna gönderin:

        package main

        import (
            "context"
            "fmt"
            "log"

            ofga "github.com/openfga/go-sdk/client"
            "github.com/openfga/go-sdk/credentials"
        )

        func main() {
            ctx := context.Background()
            config := ofga.ClientConfiguration{
                ApiUrl:  "http://localhost:8080",
                StoreId: "01H2144Y1J322A0H1Z0G6X85G3", // Kendi Store ID'niz
                Auth:    &credentials.Credentials{Method: credentials.None},
            }
            fgaClient, err := ofga.NewClient(config)
            if err != nil {
                log.Fatalf("openFGA istemcisi oluşturulamadı: %v", err)
            }

            modelDSL := schema 1.1

                type user

                type document
                  relations
                    define viewer: [user, group#member] or owner
                    define editor: [user, group#member] or owner or viewer
                    define owner: [user]

                type group
                  relations
                    define member: [user]

            options := ofga.ClientWriteAuthorizationModelOptions{}
            writeAuthModelResponse, err := fgaClient.WriteAuthorizationModel(ctx).Body(
                ofga.WriteAuthorizationModelRequest{
                    Schema: &modelDSL,
                },
            ).Options(options).Execute()

            if err != nil {
                log.Fatalf("Yetkilendirme modeli yazılamadı: %v", err)
            }
            fmt.Printf("Yetkilendirme modeli başarıyla yüklendi. Model ID: %s\n", *writeAuthModelResponse.AuthorizationModelId)
            // Bu model ID'yi kaydedin, çünkü daha sonraki sorgularınızda kullanmanız gerekebilir.
        }
    

4. İlişki Demetleri (Relation Tuples) Oluşturma

Kullanıcılar ve belgeler arasındaki ilişkileri tanımlayın. Örneğin, 'ali' adlı kullanıcının 'dokuman-123' belgesinin sahibi olduğunu ve 'veli' adlı kullanıcının bu belgeyi görüntüleyebildiğini varsayalım:

        package main

        // ... (önceki import'lar ve main fonksiyonu başlangıcı)

        func main() {
            // ... (client oluşturma ve model yükleme kodları)

            // İlişki demetlerini yazma (Write Tuples)
            // Alice, document:roadmap'in sahibi
            _, err = fgaClient.Write(ctx).Body(ofga.ClientWriteRequest{
                Writes: []ofga.ClientTupleKey{
                    ofga.ClientTupleKey{
                        User:     "user:alice",
                        Relation: "owner",
                        Object:   "document:roadmap",
                    },
                },
            }).Execute()

            if err != nil {
                log.Fatalf("İlişki demetleri yazılamadı (Alice owner): %v", err)
            }
            fmt.Println("Alice, document:roadmap'in sahibi olarak kaydedildi.")

            // Bob, document:roadmap'i görüntüleyebilir
            _, err = fgaClient.Write(ctx).Body(ofga.ClientWriteRequest{
                Writes: []ofga.ClientTupleKey{
                    ofga.ClientTupleKey{
                        User:     "user:bob",
                        Relation: "viewer",
                        Object:   "document:roadmap",
                    },
                },
            }).Execute()

            if err != nil {
                log.Fatalf("İlişki demetleri yazılamadı (Bob viewer): %v", err)
            }
            fmt.Println("Bob, document:roadmap'i görüntüleyici olarak kaydedildi.")
        }
    

5. Yetkilendirme Kontrolü (Check API)

Şimdi en önemli kısım: Bir kullanıcının bir eylemi gerçekleştirip gerçekleştiremeyeceğini kontrol etme. Bu, uygulamanızın API endpoint'lerinde veya iş mantığı katmanında çağıracağınız ana fonksiyondur.

        package main

        // ... (önceki import'lar, main fonksiyonu başlangıcı, client oluşturma ve model/tuple yükleme kodları)

        func main() {
            // ... (önceki kodlar)

            // Yetkilendirme Kontrolü (Check)
            checkUserAccess := func(user, relation, object string) {
                checkResponse, err := fgaClient.Check(ctx).Body(
                    ofga.ClientCheckRequest{
                        User:     user,
                        Relation: relation,
                        Object:   object,
                    },
                ).Execute()

                if err != nil {
                    log.Printf("Check sorgusu başarısız oldu: %v", err)
                    return
                }

                if checkResponse.GetAllowed() {
                    fmt.Printf("%s, %s üzerinde %s yetkisine SAHİP.\n", user, object, relation)
                } else {
                    fmt.Printf("%s, %s üzerinde %s yetkisine SAHİP DEĞİL.\n", user, object, relation)
                }
            }

            // Test sorguları
            checkUserAccess("user:alice", "owner", "document:roadmap")   // Alice owner mı? -> EVET
            checkUserAccess("user:alice", "editor", "document:roadmap")  // Alice editor mı? (owner olduğu için) -> EVET
            checkUserAccess("user:alice", "viewer", "document:roadmap")  // Alice viewer mı? (editor olduğu için) -> EVET
            checkUserAccess("user:bob", "viewer", "document:roadmap")    // Bob viewer mı? -> EVET
            checkUserAccess("user:bob", "editor", "document:roadmap")    // Bob editor mı? -> HAYIR
            checkUserAccess("user:charlie", "owner", "document:roadmap") // Charlie owner mı? -> HAYIR
        }
    

Bu adımlar, Go sunucunuzda openFGA ile temel bir RBAC sistemini nasıl kuracağınızı göstermektedir. Belirli bir kullanıcının belirli bir eylemi gerçekleştirme yetkisine sahip olup olmadığını anında sorgulayabilirsiniz. openFGA, ilişkileri ve modelinizi kullanarak bu kararı sizin için verir, böylece uygulamanızın kod tabanı yetkilendirme mantığından arındırılmış olur.

Gelişmiş openFGA Kullanımı: Dinamik RBAC ve Performans İpuçları

openFGA'nın gücü, sadece statik rolleri yönetmekle sınırlı değildir. Dinamik ilişkiler, türemiş yetkiler ve performans optimizasyonları sayesinde, en karmaşık yetkilendirme senaryolarını bile kolayca modelleyebilirsiniz. Bu bölüm, openFGA'yı daha ileri düzeyde kullanma tekniklerini ve Go uygulamalarınızdaki performansını artırmaya yönelik ipuçlarını ele alacaktır.

Dinamik İlişkiler ve Türemiş Yetkiler

Geleneksel RBAC'ın en büyük zorluklarından biri, hiyerarşik veya türemiş yetkileri yönetmektir. openFGA'nın DSL'i, bu tür karmaşık ilişkileri şema düzeyinde tanımlamanıza olanak tanır. Örneğin, bir "klasör"ün sahibi, o klasördeki tüm "belge"lerin de sahibi olmalıdır. Bu, openFGA'da Computed Users (Hesaplanan Kullanıcılar) ve TupleToUserset (Demetten Kullanıcı Kümesine) kavramlarıyla kolayca başarılır:

        schema 1.1

        type user

        type folder
          relations
            define owner: [user]
            define editor: [user] or owner // Klasörün sahibi aynı zamanda editor'üdür.

        type document
          relations
            define viewer: [user] or editor or parent#viewer // Document'ın viewr'ı; editor'ü veya üst klasörünün viewer'ı olabilir
            define editor: [user] or owner or parent#editor // Document'ın editor'ü; owner'ı veya üst klasörünün editor'ü olabilir
            define owner: [user] // Document'ın doğrudan sahibi
            define parent: [folder] // Document'ın bağlı olduğu klasör
    

Bu modelde:

• Bir folder'ın owner'ı, otomatik olarak editor yetkisini kazanır (owner or editor).
• Bir document'ın viewer'ı, doğrudan tanımlanmış bir user olabileceği gibi, editor ilişkisinden veya bağlı olduğu parent klasörünün viewer'ından da türetilebilir (viewer or editor or parent#viewer).
• parent#viewer ifadesi, document'ın parent ilişkisi aracılığıyla bağlandığı folder nesnesinin viewer ilişkisini temsil eder. Bu, hiyerarşik yetki akışını inanılmaz derecede esnek bir şekilde tanımlamanızı sağlar.

Bu sayede, "bir üst klasörün editörü, altındaki tüm belgelerin de editörüdür" gibi iş kurallarını doğrudan yetkilendirme modelinize dahil edebilir ve her belge için tek tek izin atama yükünden kurtulabilirsiniz.

Performans Optimizasyonu

Yüksek performanslı Go uygulamaları için openFGA entegrasyonunda dikkat etmeniz gereken bazı noktalar:

1. Toplu Kontrol (Batch Check) Kullanımı: Aynı anda birden fazla yetkilendirme sorgusu yapmanız gerektiğinde (örneğin, bir liste ekranında her öğe için yetki kontrolü), tek tek Check çağrıları yerine Batch Check API'sini kullanın. Bu, ağ gecikmesini azaltır ve openFGA sunucusundaki kaynak kullanımını optimize eder.

   
                   // Go SDK'da Batch Check örneği
                   // checks := []ofga.ClientCheckRequest{...}
                   // batchCheckResponse, err := fgaClient.BatchCheck(ctx).Body(checks).Execute()
               

2. Doğru Model Tasarımı: Yetkilendirme modelinizi mümkün olduğunca sade ve anlaşılır tutun. Çok karmaşık ilişkiler veya gereksiz derin türetmeler, sorgu sürelerini uzatabilir. Modelinizi tasarlarken, hangi sorguların en sık yapılacağını ve bunların nasıl en verimli şekilde cevaplanabileceğini düşünün. Örneğin, doğrudan ilişkilere öncelik vermek genellikle daha hızlıdır.
3. Değişiklik Akışı (Change Stream) Kullanımı: Bazı durumlarda, bir kullanıcının yetkileri anlık olarak değiştiğinde uygulamanızın bu değişikliklerden haberdar olması gerekebilir. openFGA'nın Change Stream özelliği (ReadChanges API), ilişki demetlerindeki değişiklikleri gerçek zamanlı olarak dinlemenizi sağlar. Bu, yerel bir önbelleği güncel tutmak veya diğer sistemleri tetiklemek için kullanılabilir, böylece her yetki kontrolünde openFGA'ya gitme ihtiyacını azaltabilirsiniz.
4. Doğru Caching Stratejileri: openFGA sunucusu kendi içinde güçlü bir önbellekleme mekanizmasına sahip olsa da, uygulamanızın belirli yetkilendirme kararlarını (özellikle sık sorgulanan ve nadiren değişenleri) kısa süreli olarak önbelleğe alması performansı artırabilir. Ancak, bu önbelleğin güncel kalmasını sağlamak için Change Stream gibi mekanizmaları kullanmak önemlidir.

Mobil Uyumluluk İçin İpuçları

Yetkilendirme çoğunlukla backend tarafında gerçekleşen bir süreç olduğundan, doğrudan HTML ve CSS ile mobil uyumluluk sağlamak bu bağlamda geçerli değildir. Ancak, openFGA gibi hızlı bir yetkilendirme motoru, mobil uygulamalarınız için dolaylı yoldan önemli faydalar sağlar:

• Hızlı API Yanıtları: openFGA'nın yüksek performanslı yapısı, yetkilendirme sorgularının düşük gecikmeyle sonuçlanmasını sağlar. Mobil uygulamalar, hızlı API yanıtlarına duyarlıdır; gecikmeler kullanıcı deneyimini olumsuz etkiler. Daha hızlı yetkilendirme kararları, genel uygulama yanıt sürelerini iyileştirir.
• Tutarlı Kullanıcı Deneyimi: Merkezi bir yetkilendirme sistemi, mobil uygulama ve diğer istemciler arasında tutarlı yetki uygulamaları sağlar. Bu, kullanıcıların farklı platformlarda aynı erişim kurallarına tabi olmasını garanti eder.
• Güvenli ve Esnek Mobil API'ler: Mobil uygulamalar genellikle sınırlı kaynaklara sahiptir ve her zaman güvenli ağlarda çalışmazlar. openFGA ile yetkilendirme mantığını sunucu tarafında tutmak, mobil uygulamaların kendisinde karmaşık yetki kontrolleri yapma ihtiyacını ortadan kaldırır, bu da güvenlik risklerini azaltır ve istemci kodunu basitleştirir. Mobil kullanıcı arayüzünüzün responsive (duyarlı) olması, backend'inizden gelen verinin hızlı ve doğru olmasını gerektirir; openFGA bu temeli sağlamlaştırır.

Mobil uyumlu HTML ve CSS, frontend geliştiricilerinin işidir. Ancak backend'de openFGA kullanarak sağladığınız hızlı ve tutarlı yetkilendirme kararları, mobil uygulamaların daha duyarlı ve keyifli bir deneyim sunmasına katkıda bulunur.

Gerçek Dünya Vaka Analizi: Çok Katmanlı Bir SaaS Uygulamasında RBAC

openFGA'nın gerçek dünyadaki gücünü daha iyi anlamak için, popüler bir senaryoyu ele alalım: karmaşık yetkilendirme ihtiyaçları olan çok katmanlı bir SaaS (Software as a Service) proje yönetim uygulaması. Bu uygulama, müşterilerine projeleri yönetme, görevler atama, dosya paylaşımı ve iletişim kurma imkanı sunuyor. Uygulamanın farklı abonelik seviyeleri, organizasyonları, projeleri ve bu yapılar içindeki farklı rolleri bulunuyor.

Senaryo: "TaskForge" Proje Yönetim Uygulaması

TaskForge'da aşağıdaki varlıklar ve ilişkiler mevcut:

• Kullanıcılar (User): Sistemdeki bireyler.
• Organizasyon (Organization): Müşterilerin ana yapısı (örneğin, "Acme Corp").
• Proje (Project): Organizasyon içinde yer alan çalışma birimleri (örneğin, "Web Sitesi Lansmanı").
• Görev (Task): Projeler içinde yer alan küçük iş parçaları (örneğin, "Ana Sayfa Tasarımı").
• Abonelik Planı (SubscriptionPlan): Organizasyonların sahip olduğu planlar (Basic, Premium, Enterprise).

Yetkilendirme gereksinimleri:

1. Bir organizasyonun sahibi, o organizasyondaki tüm projeleri ve görevleri yönetebilir, kullanıcı ekleyebilir/çıkarabilir.
2. Bir projenin yöneticisi, sadece kendi projesi içindeki görevleri düzenleyebilir, yeni görevler oluşturabilir ve projeye üyeler ekleyebilir.
3. Bir projenin üyesi, sadece kendi projesi içindeki görevleri görüntüleyebilir ve kendi atandığı görevleri tamamlayabilir.
4. Bir kullanıcının, görev üzerinde "atamalı" (assignee) ilişkisi varsa, o görevi "tamamla" eylemini gerçekleştirebilir.
5. "Enterprise" abonelik planına sahip organizasyonların kullanıcıları, özel "denetçi" (auditor) rolüne sahip olabilir ve tüm projelere salt okunur erişime sahip olabilir.

Geleneksel RBAC Neden Yetersiz Kalırdı?

Bu senaryoda, geleneksel RBAC ile başa çıkmak bir kabus olurdu:

• Her organizasyon için ayrı "Organizasyon X Yöneticisi" gibi roller tanımlamak rol patlamasına yol açar.
• Her proje için ayrı "Proje Y Yöneticisi" gibi roller tanımlamak, yönetimi imkansız kılardı.
• Bir kullanıcının bir görev üzerinde "atamalı" olması gibi nesne düzeyindeki dinamik ilişkileri RBAC ile modellemek imkansıza yakın olurdu.
• Abonelik planlarına göre yetkilerin değişmesi, karmaşık koşullu mantık gerektirirdi.

openFGA ile Çözüm

openFGA, bu senaryoyu ilişkiler üzerinden zarifçe çözer. İşte basitleştirilmiş bir openFGA DSL modeli:

        schema 1.1

        type user

        type organization
          relations
            define owner: [user]
            define member: [user] or owner

        type project
          relations
            define manager: [user] or organization#owner // Proje yöneticisi veya organizasyon sahibi
            define member: [user] or manager or organization#member
            define parent: [organization]

        type task
          relations
            define assignee: [user]
            define editor: [user] or project#manager // Görevin editor'ü, atanan kişi veya proje yöneticisi
            define viewer: [user] or editor or project#member // Görevin görüntüleyicisi
            define complete_task: assignee // Sadece atanan kişi görevi tamamlayabilir
            define parent: [project]
    

Bu modelle:

• project#manager: Bir proje, üst organization'ın owner'ı tarafından yönetilebilir.
• task#editor: Bir görevin editörü, doğrudan atanmış bir kullanıcı olabileceği gibi, o görevin ait olduğu project'in manager'ı da olabilir.
• task#complete_task: Bu, sadece assignee ilişkisine sahip kullanıcıların yapabileceği belirli bir eylemdir.

Go Sunucusunda Entegrasyon

Go backend'inizde, TaskForge'un API endpoint'lerinde bu yetkilendirme modelini kullanırsınız. Örneğin, bir kullanıcının bir görevi tamamlamaya çalıştığı bir API endpoint'i:

        package main

        import (
            "context"
            "log"
            "net/http"

            ofga "github.com/openfga/go-sdk/client"
            "github.com/openfga/go-sdk/credentials"
        )

        // fgaClient global veya dependency injection ile yönetilebilir
        var fgaClient *ofga.OpenFgaClient

        func init() {
            ctx := context.Background()
            config := ofga.ClientConfiguration{
                ApiUrl:  "http://localhost:8080",
                StoreId: "01H2144Y1J322A0H1Z0G6X85G3", // Kendi Store ID'niz
                Auth:    &credentials.Credentials{Method: credentials.None},
            }
            client, err := ofga.NewClient(config)
            if err != nil {
                log.Fatalf("openFGA istemcisi oluşturulamadı: %v", err)
            }
            fgaClient = client

            // Model yükleme ve başlangıç ilişkilerini yazma init() fonksiyonunda yapılabilir.
            // Bu kısım tekrardan kaçınmak için makalede gösterilmemiştir.
        }

        func completeTaskHandler(w http.ResponseWriter, r *http.Request) {
            // Gerçek uygulamada, kullanıcı kimliği bir JWT token'dan veya session'dan alınır.
            userID := "user:john_doe" // Örnek kullanıcı
            taskID := "task:feature_x" // URL params veya request body'den alınan görev ID'si

            checkRequest := ofga.ClientCheckRequest{
                User:     userID,
                Relation: "complete_task",
                Object:   taskID,
            }

            checkResponse, err := fgaClient.Check(r.Context()).Body(checkRequest).Execute()
            if err != nil {
                http.Error(w, "Yetkilendirme kontrolü başarısız: "+err.Error(), http.StatusInternalServerError)
                return
            }

            if !checkResponse.GetAllowed() {
                http.Error(w, "Yetkisiz erişim: Görevi tamamlama yetkiniz yok.", http.StatusForbidden)
                return
            }

            // Yetkilendirme başarılı, görevi tamamlama işlemini gerçekleştir
            log.Printf("%s kullanıcısı %s görevini başarıyla tamamladı.", userID, taskID)
            w.WriteHeader(http.StatusOK)
            w.Write([]byte("Görev başarıyla tamamlandı."))
        }

        func main() {
            http.HandleFunc("/tasks/{taskID}/complete", completeTaskHandler)
            log.Fatal(http.ListenAndServe(":8080", nil))
        }
    

Bu örnekte, completeTaskHandler fonksiyonu, bir kullanıcının bir görevi tamamlayıp tamamlayamayacağını belirlemek için openFGA'ya başvurur. Eğer yetkilendirme motoru izin verirse, işlem devam eder; aksi takdirde bir yetkisiz erişim hatası döndürülür.

Bu vaka analizi, openFGA'nın çok katmanlı ve dinamik bir SaaS uygulamasında nasıl güçlü ve esnek bir yetkilendirme çözümü sunduğunu açıkça göstermektedir. Geliştiriciler, karmaşık yetkilendirme mantığını uygulamanın işlevsel kodundan ayırarak, daha güvenli, bakımı kolay ve ölçeklenebilir sistemler inşa edebilirler.

Sonuç: Geleceğin Yetkilendirme Stratejileri

Erişim kontrolü, modern uygulamaların temel taşlarından biridir ve uygulamanızın boyutu veya karmaşıklığı ne olursa olsun, doğru bir yetkilendirme stratejisi hayati önem taşır. Geleneksel RBAC modelleri, başlangıçta cazip gelse de, dinamik ve ince taneli yetkilendirme gereksinimleriyle karşılaşıldığında hızla yetersiz kalabilir. Bu makalede gördüğümüz gibi, openFGA gibi ilişki tabanlı yetkilendirme motorları, bu zorlukların üstesinden gelmek için güçlü ve ölçeklenebilir bir çözüm sunmaktadır.

openFGA, Google'ın Zanzibar prensiplerinden ilham alarak, "kimin neye erişimi var?" sorusunu merkezi ve tutarlı bir şekilde cevaplama yeteneği sağlar. Go dilinin eşzamanlılık ve performans avantajları ile birleştiğinde, openFGA, mikroservis mimarilerinde veya büyük ölçekli SaaS uygulamalarında bile hızlı ve güvenilir yetkilendirme kararları almanızı mümkün kılar. Yetkilendirme mantığını uygulamanızın kod tabanından ayırmak, geliştirici verimliliğini artırırken, güvenlik duruşunuzu güçlendirir ve sisteminizin daha kolay denetlenebilir olmasını sağlar.

openFGA'nın esnek DSL'i ve güçlü API'leri sayesinde, statik rollere bağlı kalmaksızın, nesneler ve kullanıcılar arasındaki karmaşık ilişkileri modelleyebilirsiniz. Bu da size, kullanıcı grupları, hiyerarşik yapılar veya koşullu erişim gibi dinamik yetkilendirme senaryolarını kolayca implemente etme özgürlüğü verir. Performans ipuçlarıyla birlikte, openFGA entegrasyonu Go sunucularınızın yük altında bile en iyi performansı göstermesini sağlayacaktır.

Gelecekteki uygulama geliştirme projelerinizde yetkilendirmeyi düşünürken, openFGA ve Go kombinasyonunu değerlendirmek, şüphesiz size daha güvenli, daha esnek ve daha bakımı kolay bir sistem kurma yolunda önemli avantajlar sağlayacaktır. Artık yetkilendirme kabus olmaktan çıkıp, uygulamanızın güçlü ve entegre bir parçası haline gelebilir.

Sıkça Sorulan Sorular (SSS)

openFGA sadece RBAC için mi kullanılır?

Hayır, openFGA özellikle ReBAC (Relationship-Based Access Control) için tasarlanmıştır. Ancak, RBAC aslında ReBAC'ın bir alt kümesidir; "kullanıcı, rolün üyesidir" gibi ilişkiler tanımlayarak RBAC modelini kolayca uygulayabilirsiniz. openFGA, ayrıca ABAC (Attribute-Based Access Control) ve CBAC (Context-Based Access Control) gibi daha karmaşık yetkilendirme modellerini de ilişkiler aracılığıyla modellemenize olanak tanır. Yani, RBAC yeteneklerini de kapsayan çok daha esnek bir çözümdür.

openFGA'nın performans açısından durumu nedir?

openFGA, Google Zanzibar'dan ilham alan ve yüksek performans, düşük gecikme ve ölçeklenebilirlik için tasarlanmış bir yetkilendirme motorudur. Dağıtık bir mimariye sahip olup, milyarlarca yetkilendirme sorgusunu saniyeler içinde işleyebilme kapasitesine sahiptir. Optimize edilmiş veri yapıları ve sorgu mekanizmaları sayesinde, büyük ölçekli ve yüksek trafikli uygulamalar için uygundur. Doğru modelleme ve istemci tarafı önbellekleme stratejileriyle performansı daha da artırabilirsiniz.

openFGA diğer yetkilendirme çözümlerinden farkı nedir?

openFGA'yı diğer çözümlerden ayıran temel özellikler şunlardır: İlişki tabanlı model (ReBAC), Google Zanzibar'dan ilham alan kanıtlanmış bir mimari, açık kaynaklı olması, esnek ve anlaşılır DSL'i, dağıtık sistemler için tasarlanmış ölçeklenebilirlik ve yüksek performans. Geleneksel RBAC çözümlerine kıyasla daha ince taneli yetkilendirme ve dinamik ilişki yönetimi sunar. Diğer genel amaçlı yetkilendirme motorlarına kıyasla ise, özellikle ilişkiler üzerine odaklanarak daha basit ve güçlü bir modelleme yaklaşımı sunar.

Go dışında hangi dillerle openFGA kullanabilirim?

openFGA, dil bağımsız bir yetkilendirme motorudur ve RESTful API ile gRPC arayüzleri sunar. Bu sayede HTTP veya gRPC destekleyen herhangi bir programlama diliyle (Python, Java, Node.js, Ruby, C#, PHP vb.) entegre edilebilirsiniz. openFGA ekibi, Go, Node.js, .NET ve Python gibi popüler diller için resmi SDK'lar sağlamaktadır, bu da entegrasyonu oldukça kolaylaştırır.

Kendi yetkilendirme sistemimi yazmak yerine neden openFGA kullanmalıyım?

Kendi yetkilendirme sisteminizi yazmak, genellikle göründüğünden çok daha karmaşık ve riskli bir iştir. Güvenlik, performans, ölçeklenebilirlik, tutarlılık ve denetlenebilirlik gibi birçok boyutu vardır. openFGA gibi uzmanlaşmış bir çözüm kullanmak:

• Güvenlik Risklerini Azaltır: Kendi sisteminizi yazarken güvenlik açıklarını gözden kaçırma olasılığınız yüksektir. openFGA, güvenlik uzmanları tarafından tasarlanmış ve test edilmiştir.
• Geliştirme Süresini Kısaltır: Yetkilendirme mantığını sıfırdan yazmak yerine, openFGA'nın hazır çözümlerini kullanarak uygulamanızın temel iş mantığına odaklanabilirsiniz.
• Ölçeklenebilirlik Sağlar: openFGA, yüksek yük altında bile performansı koruyacak şekilde tasarlanmıştır. Kendi çözümünüzü bu ölçekte test etmek ve optimize etmek çok zaman alabilir.
• Bakım Yükünü Azaltır: Yetkilendirme mantığını merkezi bir servise devretmek, uygulamanızın kod tabanını basitleştirir ve bakım maliyetlerini düşürür.
• Esneklik Sunar: openFGA'nın ilişki tabanlı modeli, gelecekteki yetkilendirme gereksinimlerinize kolayca adapte olmanızı sağlar, bu da kendi statik çözümünüzle mümkün olmayabilir.