SCIM sağlama temelleri: akışlar, alanlar ve güvenli test

SCIM sağlama nedir ve ekipler neden kullanır?

SCIM sağlama basit ama can sıkıcı bir problemi çözer: bir uygulamaya erişebilen kişiler listesi zamanla kimlik sağlayıcınızdaki (IdP) listeyle eşleşmeyi bırakır. Birisi işe alınır, adı değişir, takım değiştirir veya ayrılır ve uygulama her zaman bu değişikliği hemen yansıtmaz.

Sağlama, IdP'nin kullanıcı değişikliklerini uygulamaya otomatik olarak itmesi demektir. Bir yönetici kullanıcıları elle davet etmek, profilleri güncellemek ve erişimi kaldırmak yerine değişiklikler IdP'de başlar ve uygulama buna uyar.

Davetiye ve işten çıkarma elle yapıldığında aynı hatalar tekrar tekrar görülür. Yeni işe alınanlar erişim bekler çünkü birisi davetiye göndermeyi unutmuştur. Eski çalışanlar erişimi korur çünkü işten çıkarma atlanmıştır. İsimler, e-postalar ve departmanlar araçlar arasında kayar. Denetimler zorlaşır çünkü uygulamanın kullanıcı listesine güvenemezsiniz. Destek talepleri birikir (giriş yapılamıyor, yanlış erişim, eski veriler görünmeye devam ediyor).

SCIM, özellikle erişimin İK ve BT kararlarını yansıtması gereken iç araçlar, yönetici panelleri ve müşteri portalları için ölçeklenebilir ve güvenilir kullanıcı yaşam döngüsü kontrolü gerektiğinde uygundur.

SSO tek başına genellikle yeterli değildir. SSO “Bir kullanıcı nasıl oturum açar?” sorusunu yanıtlar. SCIM ise “Bu kullanıcı uygulamada var mı ve şu anda hesabı nasıl görünmeli?” sorusunu yanıtlar.

Temel fikir: kullanıcılar için tek doğru kaynak

Bir kuralla başlayın: bir sistemi, kullanıcının kim olduğunu ve neler yapabileceğini “doğru” kabul edin. Çoğu şirkette bu sistem IdP'dir (Okta, Azure AD, Google Workspace).

IdP, insanların oluşturulduğu, devre dışı bırakıldığı ve gruplara atandığı yerdir. Hizmet sağlayıcı (SP) ise bu kararları alıp kendi kullanıcı veritabanında uygulayan uygulamadır. Bu bir SaaS ürünü veya sizin geliştirdiğiniz özel iç uygulama olabilir.

IdP doğru kaynak olduktan sonra uygulama bununla tartışmamalıdır. Bir yönetici IdP'de bir kullanıcıyı devre dışı bırakırsa, uygulama aynı kullanıcıyı yerel olarak tekrar etkinleştirmeye çalışan birine rağmen devre dışı kabul etmelidir. Gruplar erişimi tetikliyorsa grup üyeliği için de aynı şey geçerlidir.

Sağlama genellikle push tabanlıdır: bir şey olduğunda IdP değişiklikleri uygulamaya gönderir. Bu, uygulamanın periyodik olarak ne değiştiğini sorduğu pull tabanlı dizin senkronizasyonundan farklıdır. Push daha hızlı ve daha nettir, ancak hatalar anında etkili olabilir; bu yüzden varsayılanlar ve eşleştirme kuralları önem kazanır.

Çoğu aktivite normal İK ve BT olaylarından kaynaklanır: yeni işe alımlar, rol değişiklikleri, izinli ayrılıklar ve işten çıkarmalar. Durumu ve grup atamalarını IdP'de kontrol altına alırsanız, çoğaltmaları, “hayalet” hesapları ve birinin takım değiştirirken son dakika erişim boşluklarını azaltırsınız.

Kullanıcı yaşam döngüsü akışları: oluşturma, güncelleme, devre dışı bırakma

Çoğu sağlama kurulumu bir vaazın etrafında döner: IdP uygulamanıza kimlerin var olduğunu ve oturum açıp açamayacaklarını söyler. Uygulamanızın birkaç yaşam döngüsü durumunu tutarlı şekilde ele alması gerekir.

Önemli üç durum

Çoğu ekip üç durumda düşünür:

• Aktif: kullanıcı kimlik doğrulaması yapabilir ve ürünü kullanabilir.
• Pasif (devre dışı): hesap kalır, ancak erişim engellenir.
• Silinmiş: kayıt kaldırılır (birçok uygulama sert silmeden kaçınır ve bunu pasife benzetir).

Oluşturma genellikle bir yöneticinin IdP'de uygulamayı bir kişiye atamasıyla veya senkronize bir gruba katılmalarıyla olur. SCIM uç noktanız, o kişiyi daha sonra eşleştirmek için ihtiyaç duyduğunuz bilgileri saklamalıdır: IdP'den gelen sabit benzersiz bir kimlik (genellikle SCIM idsi) ve bir oturum açma değeri (çoğunlukla userName). Uygulamanız e-posta gerektiriyorsa, oluşturmanın ortada başarısız olmaması için bunu haritalamada açıkça belirtin.

Güncelleme, IdP bir profil alanını veya atamayı değiştirdiğinde olur. İsim, e-posta, departman gibi kimlik ve iletişim alanlarını beklenmedik şekilde erişimi değiştirmeden uygulayın. En hassas alan oturum açma tanımlayıcısıdır. Eğer userName değişebiliyorsa, aynı kişiyi değişmez bir tanımlayıcıyla eşlemeniz gerekir; aksi takdirde çoğaltmalar oluşur.

Devre dışı bırakma erişimi hızla engellemeli ama iş verilerini kaybettirmemelidir. IdP genelde active=false olarak ayarlar. Uygulamanız bunu “oturum açılamaz, API kullanamaz” olarak ele almalı, sahip olunan kayıtları, denetim geçmişini ve referansları korumalıdır.

Yeniden etkinleştirme tersidir. active=true aynı hesabın erişimini geri getirmeli, yeni bir hesap oluşturulmamalıdır. IdP aynı kişi olarak kabul ediyorsa, uygulamanız da aynı şekilde kabul etmelidir; uzak oldukları sürede e-posta veya görünür ad değişmiş olsa bile.

Sürprizlerden kaçınan alan eşleştirme ve gerekli öznitelikler

Sağlama, uygulama ve IdP'nin iki konuda anlaşmasıyla çalışır: bir kullanıcıyı nasıl tanımlayacağını ve hangi özniteliklerin IdP tarafından üzerine yazılabileceğini.

Genellikle ihtiyaç duyulan minimum

SCIM esnektir, ama çoğu uygulama aynı temel özniteliklere dayanır:

• Sabit benzersiz bir tanımlayıcı (SCIM kaynak idsi, genelde IdP'nin externalIdsi ile eşleştirilir)
• E-posta veya kullanıcı adı (çoğunlukla userName, genelde oturum açma için kullanılır)
• İsim (name.givenName ve name.familyName ya da displayName)
• Aktif durumu (active: true/false)
• Zaman damgaları veya meta veriler (isteğe bağlı, ama denetimler ve hata ayıklama için faydalı)

Tanımlayıcı anahtar detaydır. E-posta benzersiz gibi hissedilir ama değişir. Eğer kullanıcılara sadece e-posta ile eşleşirseniz ve biri soyadı değişikliği yaşar (evlilik, yeniden markalaşma, domain geçişi), IdP eski kişiyi güncellemek yerine yeni bir kişi oluşturuyormuş gibi görünebilir. Bu, çoğaltmaların yaygın bir yoludur.

IdP'nin neleri üzerine yazabileceğini kararlaştırın

Açık bir kural seçin: hangi alanlar IdP'nin (IdP her zaman kazansın) ve hangi alanlar uygulamanın (uygulama bunları değiştirebilir) olduğunu belirleyin.

Yaygın ve güvenli bir ayrım:

• IdP-tek sahip: active, e-posta/kullanıcı adı, verilen ve soyadı, displayName
• Uygulama-tek sahip: uygulamaya özgü profil alanları (tercihler, dahili notlar)

Uygulamanız kullanıcıların isimlerini düzenlemesine izin veriyorsa, bu düzenlemelerin kalıcı olup olmayacağını kararlaştırın. Her iki seçim de işe yarar; problem öngörülemez olduğunda başlar.

Eksik ve dağınık veriyi ele alma

Boşluklar ve tutarsız formatlar bekleyin. Bazı dizinler sadece displayName gönderir. Diğerleri verilen ve soyadı gönderir ama displayName yoktur. Pratik bir geri dönüş, gerektiğinde displayNamei verilen ve soyadı birleştirerek oluşturmak ve eksik soyadlarını nazikçe ele almaktır.

Kritik alanları doğrulayın. Eğer userName boşsa veya oturum açma için e-posta gerekiyorsa e-posta değilse isteği açık bir hata ile reddedin ve kaydedin. Oturum açamayan bir kullanıcıyı sessizce oluşturmak, yavaş bir kesintiye dönüşür.

Hesaplar nasıl eşleştirilir ve neden çoğaltmalar olur

“Eşleşme”, IdP ile uygulamanızın iki kaydın aynı kişiyi temsil ettiğinde anlaşmasıdır. Çoğu sağlama sorunu, IdP güncelleme gönderdiğinde uygulamanızın mevcut kullanıcıyı bulmak için hangi alanları kullandığına indirgenir.

Eşleştirme için ne kullanılmalı

Önce sabit, insan tarafından değiştirilmeyen bir tanımlayıcı ile eşleştirin. E-posta ve kullanıcı adını profil verisi olarak ele alın; değişebilir.

Yaygın eşleştirme anahtarları (en güvenilenden en az güvenilene):

• IdP'den değişmez dışsal ID
• SCIM id (kullanıcı için stabil)
• E-posta (faydalı ama değişebilir)
• Kullanıcı adı (çoğunlukla yeniden adlandırılır, yeniden kullanılır veya farklı formatlarda olur)

Uygulamanız sadece e-posta ile eşleşiyorsa, bir e-posta değişikliği yeni bir kişi gibi görünür ve ikinci bir kullanıcı yaratır. Bunun yerine dışsal ID'yi birincil anahtar tutun ve e-postanın kimliği değiştirmeden güncellenmesine izin verin.

Çoğaltmalar neden oluşur

Çoğaltmalar genelde üç durumda ortaya çıkar:

1. Uygulama net bir eşleşme döndürmediği için IdP bir “oluştur” gönderir; genelde gerekli özniteliklerin eksik olması veya bir eşleme hatası nedeniyle.
2. Uygulama e-posta'yı benzersiz tanımlayıcı olarak kabul eder, böylece e-posta değişikliği ikinci bir kullanıcı yaratır.
3. Aynı kişi iki yerden sağlanır (iki IdP veya manuel davetler artı SCIM).

Çakışan güncellemeleri azaltmak için temel profil alanları için bir sahibi seçin. Eğer IdP isimleri, e-postayı ve aktif durumu yönetiyorsa, bu alanlar için uygulama içi manuel düzenlemelere güvenmeyin (veya açıkça “IdP tarafından yönetiliyor” olarak etiketleyin).

Eğer iki IdP kullanıcısı bir uygulama kullanıcısına işaret ediyorsa, otomatik olarak birleştirmeyin. Bu hesaplar için SCIM'i duraklatın, hangi IdP kimliğinin doğru olduğunu belirleyin, dışsal ID kullanarak yeniden bağlayın ve yanlış olanı devre dışı bırakın. Bu, denetim geçmişinin tutarlı kalmasını sağlar.

Gruplar, roller ve erişim: kuralları öngörülebilir tutun

SCIM kullanıcı ve grupları göndermeye başladığında en büyük risk sürpriz erişimdir. Modeli basit tutun: erişimi IdP gruplarına göre verin veya uygulama içinde yönetilen rollere göre verin. Her ikisini de açık bir kural olmadan karıştırmak “neden erişim aldılar?” olaylarına yol açar.

Grup tabanlı erişim, IdP'nin zaten yöneticilerin takım üyeliklerini yönettiği durumlarda iyi çalışır. Rol tabanlı erişim, uygulama sahiplerinin IdP'ye dokunmadan izinleri ince ayarlaması gerektiğinde daha uygundur. Birleştirmeniz gerekiyorsa, çakıştıklarında hangisinin kazanacağını tanımlayın.

Varsayılanlarla muhafazakar olun. Grup verisi ilk senkron sırasında gecikirse veya eksikse (yaygın), hesabı oluşturun ama beklenen grup gelene kadar hassas erişim vermeyin. “Grup yok”u tahmin etmek yerine “erişim yok” olarak değerlendirin.

Öngörülebilir bir kural seti:

• Kullanıcı oluştur: minimal erişimle bir temel rol ata veya rol atama.
• Gruba ekle: o grubun sağladığı erişimi ver.
• Gruptan çıkar: o erişimi hemen kaldır.
• Kullanıcıyı devre dışı bırak: oturumu engelle ve tüm erişimi iptal et, grup üyeliğine bakmaz.
• Yeniden etkinleştir: yalnızca mevcut grup üyeliğinin izin verdiğini geri ver.

Grup kaldırma ile devre dışı bırakma farklıdır. Grup kaldırma erişimi azaltmalı ama kullanıcı hesabını diğer gruplara ait olmaya devam ediyorsa kullanılabilir tutmalıdır. Devre dışı bırakma ise işten çıkarma için sert bir durdurmadır.

Dokümantasyonu kısa tutun ama spesifik olun: hangi gruplar hangi izinlere eşlenir, gruplar eksikse ne olur, grup değişikliklerinin sahibi kimdir (BT vs uygulama sahibi) ve değişikliklerin görünmesi yaklaşık ne kadar sürer.

Adım adım: insanları kilitlemeden SCIM'i test etme

Önce ayrı bir üretim dışı ortamda (ayrı tenant, workspace veya staging örneği) temiz bir dizin ve birkaç test hesabı ile başlayın. Orada sağlamayı açın.

Bağlamadan önce SCIM tarafından yönetilmeyen bir acil erişim yöneticisi hesabı oluşturun. Bu hesaba güçlü bir parola verin ve IdP SCIM atamalarının dışında tutun. Bu, sağlama normal yöneticilerinizi devre dışı bırakırsa geri dönüş yolunuzdur.

Küçük bir pilot grup kullanın (2–5 kişi). Bir yönetici ve bir normal kullanıcı dahil edin. Pilot tam olarak beklendiği gibi davranana kadar tüm şirket için sağlamayı etkinleştirmeyin.

Riskli parçaları kapsayan basit bir test planı:

• Oluşturma: IdP'de yeni bir test kullanıcı atayın ve hesabın uygulamada doğru ad, e-posta ve durumla göründüğünü doğrulayın.
• Güncelleme: Bir alanı (çoğunlukla e-posta) değiştirin ve uygulamanın aynı kullanıcıyı güncellediğini, ikinci bir kullanıcı yaratmadığını doğrulayın.
• Devre dışı bırakma: Atamayı kaldırın (veya kullanıcıyı devre dışı bırakın) ve uygulamanın erişimi engellediğini fakat iş verilerini silmediğini doğrulayın.
• Yeniden etkinleştirme: Kullanıcıyı yeniden atayın ve aynı hesabın tekrar aktif olduğunu doğrulayın.
• Tekrar: İlk çalıştırma davranışını yakalamak için aynı adımları tekrar edin.

Sadece kullanıcı arayüzüne güvenmeyin. Her iki taraftaki SCIM günlüklerini kontrol edin ve zaman damgalarını doğrulayın: IdP değişikliği ne zaman gönderdi, uygulama ne zaman işledi ve hangi alanlar değişti.

Herhangi bir adım ikinci bir hesap yaratıyorsa, yanlış kullanıcıyı devre dışı bırakıyorsa veya yönetici erişimini kaybettiriyorsa, uygulamayı genişletmeden önce eşleştirme ve öznitelik haritalamasını düzeltin.

Kilitlenmelere veya dağınık dizinlere yol açan yaygın hatalar

Çoğu sorun “SCIM hatası” değildir. Kurulum sırasında masum görünen küçük varsayımlardan kaynaklanır ve ölçeklendiğinde bozulur. Eşleştirme kuralları ve varsayılanlar konnektörden daha önemlidir.

Genelde kilitlenmelere neden olan hatalar

Yaygın kalıplar şunlardır:

• Gevşek eşleştirme (örneğin sadece e-posta ile eşleştirme veya aynı tanımlayıcıya birden fazla kullanıcının izin verilmesi).
• E-posta'yı kalıcı ID olarak görmek; oysa e-postalar yeniden adlandırılır, taşınır ve bazen yeniden kullanılır.
• SCIM'in manuel düzeltmeleri kimsenin fark etmediği şekilde üzerine yazmasına izin vermek (IdP kendi doğrularını yeniden uygular).
• Oluşturma sırasında geniş erişim verme ve sonrasında sıkılaştırmayı unutma.
• Pilot yapmadan herkes için sağlamayı açmak; böylece bir eşleme hatası tüm şirkete etki eder.

Gerçek hayattan bir başarısızlık modu: bir domain değişikliği sırasında BT e-postaları yeniden adlandırır. Uygulama e-posta ile eşleşiyorsa, SCIM mevcut hesabı bulamaz, yeni bir hesap oluşturur ve sonra eski hesabı devre dışı bırakır. Kullanıcı en kötü anda iki profile, bozuk geçmişe ve erişim sorunlarına sahip olur.

Karışıklığı nasıl önlersiniz

Değişmez benzersiz bir tanımlayıcı ile eşleştirin (genelde IdP'nin değişmez kullanıcı ID'si) ve e-postayı değişebilir olarak ele alın.

Kimin kullanıcı alanlarını düzenleyebileceğine karar verin. SCIM doğru kaynaksa, IdP-tek sahip alanları uygulamada engelleyin veya bu alanların üzerine yazılacağını açıkça gösterin.

Küçük bir pilot ve en az ayrıcalık varsayılanlarıyla başlayın. Bir akışı güvenilir hale getirip sonra erişim eklemek, aşırı sağlama veya kötü bir devre dışı bırakma çalışmasının ardından temizlik yapmaktan daha kolaydır.

Canlıya geçmeden önce kısa kontrol listesi

Pilottan daha geniş bir açılıma geçmeden önce tam yaşam döngüsünü doğrulayın: doğru hesabı oluşturma, daha sonra aynı hesabı güncelleme ve gerektiğinde erişimi kaldırma.

IdP'de yeni, taze bir test kimliği (gerçek bir çalışan değil) kullanın. Onu sağlayın ve hesabın beklenen kullanıcı adı, e-posta, görüntü adı ve durumla uygulamada göründüğünü doğrulayın.

Sonra değişiklik testi yapın. IdP'de kişinin adını ve e-postasını güncelleyin ve uygulamada ne olduğunu izleyin. Bir kullanıcı kaydının güncellenmesini istiyorsunuz, ikinci bir kullanıcı yaratılmasını değil.

Son olarak, kaldırma ve geri getirmeyi test edin. IdP'de kullanıcıyı devre dışı bırakın ve giriş yapılamadığını ve erişimin kalktığını doğrulayın. Sonra yeniden etkinleştirin ve erişimin öngörülebilir şekilde geri geldiğini doğrulayın (doğru roller, doğru gruplar, istemeden yönetici hakları yok).

Kısa bir canlıya geçiş kontrol listesi:

• Yeni kullanıcı doğru anahtar alanlarla doğru şekilde sağlanıyor ve doğru erişim durumuyla başlıyor.
• Profil değişiklikleri aynı kişiyi güncelliyor (çoğaltma yok).
• Devre dışı bırakma oturumu engelliyor ve erişimi hızlıca kaldırıyor.
• Yeniden etkinleştirme erişimi güvenli şekilde geri getiriyor.
• Yönetici kurtarma yolları mevcut (break-glass yönetici, SCIM'i duraklatma imkanı, son değişikliklerin denetim günlüğü).

Gerçekçi bir örnek: bir ekip üyesinin işe alınması ve işten çıkarılması

200 kişilik bir şirketi düşünün; bir IdP ve SCIM kullanılarak bir iç araca erişim yönetiliyor.

Pazartesi günü Maya Sales Ops'e katılır. BT, IdP'de Maya'ya uygulamayı atadığında SCIM bir Oluşturma gönderir. Uygulamada doğru benzersiz kimlik, e-posta ve “Sales Ops” departman değeriyle yeni bir kullanıcı görülür. Gruplar erişimi yönetiyorsa, uygulama doğru rolü veren grup üyeliğini de alır.

Perşembe günü Maya RevOps'a geçer. Bu bir Güncelleme tetikler. Maya aynı kişi kalır (aynı dışsal ID), ancak öznitelikler değişir. İzinler departman veya gruplara bağlıysa, hatalar burada ortaya çıkar; bu yüzden hemen doğrulayın.

Ay sonunda Maya ayrılır. IdP hesabı devre dışı bırakır veya uygulama atamasını kaldırır ve SCIM bir Devre dışı bırakma gönderir (çoğunlukla active=false gibi bir güncelleme). Maya oturum açamaz, ancak geçmiş verileri işletme tarafından korunur.

Bir yönetici hızla doğrulayabilir:

• Oluşturma: kullanıcı bir kez var, oturum açabiliyor ve beklenen varsayılan rolü alıyor.
• Güncelleme: aynı kullanıcı kaydı güncelleniyor (çoğaltma yok) ve erişim doğru şekilde değişiyor.
• Devre dışı bırakma: giriş engellendi, oturumlar sonlandırıldı, yeni API erişimi yok, denetim geçmişi sağlam.
• Denetim: SCIM olayları zaman damgaları ve sonuçlarla kaydedilir.

Bir yüklenici geçici erişime ihtiyaç duyuyorsa, Maya'nın hesabını yeniden kullanmayın. IdP'de ayrı bir yüklenici kimliği oluşturun, onu zaman kutulu bir gruba koyun ve sağlama kaldırmayı yönetir.

Sonraki adımlar: güvenli açılım ve sürdürülebilirlik

Sağlama çalışmaya başlamak kolay olabilir ama sonra iyi işletmek zor olabilir. Bunu kurallar, sahipler ve bir değişiklik günlüğü olan küçük bir sistem gibi yönetin.

Öznitelik haritalamanızı ve erişim kurallarınızı tek bir yerde yazın: hangi IdP alanlarının kullanıcı adı, e-posta, isim, departman, yöneticiyi doldurduğu ve hangi grupların hangi erişimi verdiği. Birisi neden bir kişinin devre dışı bırakıldığını sorduğunda bir cevap olmasını istersiniz, beş tahmin değil.

Gerçekçi ama geri alınabilir bir pilot seçin. Kontrol noktaları (gün 1, hafta 1, hafta 2) tanımlayın, geri alma adımlarını açıkça belirtin (atamaları duraklat, SCIM'i durdur, erişimi geri ver) ve break-glass yönetici hesabını SCIM dışı tutun.

İzleme, sorunları sinirli kullanıcılardan duymayı engeller. Ne izleyeceğinize ve kimin bildirim alacağına karar verin: devre dışı bırakma veya yeniden etkinleştirmede ani artışlar, çoğaltma artışı, olağandışı yüksek güncelleme hacmi (çoğunlukla bir eşleme döngüsü) ve gerekli özniteliksiz oluşturulan kullanıcılar.

Uygulamayı kendiniz inşa ediyorsanız, kullanıcı yönetimini erken planlayın: kullanıcı oluşturma, profil güncelleme, hesap devre dışı bırakma ve rol atama. Bu işlevler ilk sınıf özellikler olduğunda çok daha kolay olur.

Prototipleme yapıyorsanız, AppMaster (appmaster.io) backend, web ve mobil uygulamayı bir arada oluşturmanın pratik bir yolu olabilir; kullanıcı modeliniz ve erişim kurallarınız stabil olduğunda SCIM'i API'leriniz aracılığıyla bağlayabilirsiniz.