Firezone, neden SCIM'i atlayıp kendi directory sync motorunu geliştirdiğini anlatıyor

Erişim modelini kimlik sağlayıcı grupları üzerine kuran Firezone, bir kurumdaki kullanıcı ve grupların uygulamanızın içinde güncel tutulmasını sağlayan mekanizma olan directory sync üzerine bir mühendislik yazısı yayımladı. Yazıya göre bu iş, SCIM standardının ima ettiğinden çok daha zor ve şirket, protokolü uygulamak yerine neden kendi sync motorunu yazmayı seçtiğini açıklıyor. Yazı, Hacker News'te geniş bir tartışma başlattı.

Directory sync nedir, ne değildir

Firezone'a göre bir kurumun dizini, kimlik sağlayıcısında — Entra, Google, Okta ve benzerlerinde — yaşar ve üç parçadan oluşur: isim, e-posta ve aktif-askıya alınmış durumu gibi niteliklere sahip kullanıcılar; Engineering veya Product gibi adlandırılmış gruplar; ve kullanıcıları ya da diğer grupları bu gruplara bağlayan üyelik kayıtları. Erişim, bir kullanıcının üye olduğu her gruptan, doğrudan veya iç içe geçmiş biçimde akar.

Directory sync, bu dizini uygulamanıza kopyalayıp insanlar katıldıkça, ayrıldıkça veya ekipler arasında geçtikçe kopyayı güncel tutmak anlamına gelir. Firezone bunu single sign-on'dan dikkatlice ayırır: OpenID Connect, kullanıcıların bir uygulamaya nasıl dahil edildiği konusunda hiçbir şey söylemez ve directory sync tam olarak o kimlik doğrulama akışı değil, sağlama (provisioning) mekanizmasıdır.

Yazı ayrıca veri modeli zorluğunu da taslak halinde çiziyor. İç içe gruplarla, belirli bir kullanıcının belirli bir gruba ait olup olmadığına karar vermek, özyinelemeli sorgularla üst grupları takip etmek demektir. Firezone'un çözümü üyelikleri düzleştirmek — her kullanıcının doğrudan ya da dolaylı olarak üye olduğu her grup için tek bir satır saklamak — böylece aynı soru tek bir sorguya dönüşür.

SCIM vaadi

SCIM, System for Cross-domain Identity Management, bu alandaki yerleşik standarttır. Uygulama, kullanıcıları ve grupları kapsayan bir dizi REST endpoint'i açığa çıkarır ve kimlik sağlayıcıları değişiklikleri bunlara iter. Cazibesi iki yönlüdür: push tabanlı güncellemeler zamanlanmış yoklamadan daha hızlı sonuçlanabilir ve prensipte tek bir standart API her sağlayıcıya hizmet eder.

SCIM'in dağıldığı yer

Firezone sorunları iki türe ayırıyor. İlki operasyonel. Push tabanlı bir tasarım, verileri alan uygulamanın fiilen her an ayakta ve hazır olmasını gerektirir; birkaç saniyelik kesinti veya aşırı yük, kritik bir güncellemeyi kaçırmak anlamına gelebilir ve uygulamanın kendisi tam bir resync tetikleme yolu yoktur — sağlayıcının veriyi tekrar göndermesini beklemek zorundadır.

İkincisi, sadece ismen standardizasyon. SCIM iletişim formatını tanımlar ama Firezone'un anlatımına göre endpoint'lerin nasıl çağrılacağını, hangi yaşam döngüsü olaylarına karşılık geldiklerini veya her isteğin hangi verileri taşıdığını hiçbir şekilde belirtmez. Yazıdaki örnekler:

• Okta, grup üyesi eklemelerini ve çıkarmalarını tek bir PATCH isteğinde birlikte gönderebilirken, Entra bunların ayrılmasını gerektirir ve PATCH başına yalnızca tek bir üye çıkarmaya izin verir.
• Entra geçmişte active bayrağını SCIM'in tanımladığı boolean yerine 'False' dizgisi olarak gönderiyordu; uyumlu davranış için bir uyumluluk bayrağını ancak sonradan ekledi.
• Okta birkaç SCIM özelliğini tamamen atlıyor; bunlar arasında toplu işlemler, POST aramaları, ServiceProviderConfig ve meta.lastModified üzerinde filtreleme var.

Deprovisioning en fazla ayrışıyor

Tutarsızlıklar, ayrılan bir çalışanın erişimini kapatma olan deprovisioning çevresinde en keskin haliyle görülüyor. Firezone, sağlayıcıların ne kadar farklı davrandığını sayıyor:

• Okta sıralamaya dayanır: kullanıcıyı grup üyeliklerinden çıkarmadan önce atamayı kaldırın, yoksa bu üyelikler aşağı akışta varlığını sürdürebilir.
• Entra, bir grup kaldırıldığında kullanıcıyı zorunlu olarak devre dışı bırakmaz; atanmış başka bir grup hâlâ erişim veriyorsa erişim sürer.
• JumpCloud, deprovisioning'i yalnızca bir provisioning grubundan çıkarma yoluyla değil, uygulama bağlantısını kaldırma, askıya alma veya silme yollarıyla da yapabilir.
• OneLogin, bir kullanıcı silinmesine, uygulamanın provisioning ayarlarına bağlı olarak silme, askıya alma veya hiçbir şey yapmayarak yanıt verebilir.

Sonuç olarak, Firezone'a göre umut edilen tek bir uygulama, sağlayıcıya özgü SCIM kod yollarının bir koleksiyonuna dönüşüyor — fiilen her kimlik sağlayıcı için ayrı bir shim. Bununla yüzleşen şirket, SCIM'i tamamen bir kenara bırakıp kendi sync motorunu sıfırdan inşa ettiğini söylüyor.

Neden önemli

Kimlik, kurumsal yazılımın temelidir ve çoğu kurum kimin neye dokunabileceğine gruplar üzerinden karar verir. SCIM provisioning için varsayılan cevaptır; ne var ki Firezone'un anlatısı, uygulamada 'SCIM desteği'nin her sağlayıcı için ayrı bir takım tuhaflıkları sindirmek anlamına geldiğini gösteriyor — en yüksek risk de, kaçırılan ya da yanlış sıralanan bir olayın eski bir çalışanın erişimini ayakta tutabildiği deprovisioning anında. Kurumsal kimlik özellikleri ekleyen her ekip için yazı, test edilecek sağlayıcı davranışlarının somut bir kontrol listesi — ve standardı benimsemenin, önlenmesi amaçlanan sağlayıcı başına işi ortadan kaldırmayabileceğinin kanıtı olarak okunabilir.