İç uygulamalar için SSO: SAML/OIDC özniteliklerini rollere ve takımlara eşleştirin

Neden claim eşleştirme iç uygulamalar için önemli?

Tek bir tıklamayla "Sign in with Okta" veya "Sign in with Azure AD" diyip oturum açmak basit gibi görünür. Zor olan kısım ise bundan sonra olanlardır. Net bir claim eşleştirme olmazsa, kişiler gereğinden fazla erişime sahip olabilir (destek personeli maaş bilgilerini görebilir) ya da yetersiz erişim alabilir (yeni bir çalışan ilk gün ihtiyaç duyduğu aracı açamaz).

İç uygulamalar, herkese açık uygulamalardan daha karmaşıktır çünkü ekipler arasında paylaşılır ve sürekli değişir. Tek bir araç aynı anda Support, Finance ve Sales tarafından kullanılabilir. Organizasyon yapıları kayar, sözleşmeli çalışanlar gelir gider ve takımlar yeniden adlandırılır veya bölünür. Erişim kuralları sadece insanların kafasında saklanıyorsa, SSO bu karmaşayı uygulamanıza olduğu gibi kopyalayacaktır.

Claim eşleştirme, kimlik sağlayıcınızdan (IdP) gelen verileri—gruplar, departman veya iş unvanı gibi—uygulamanızın anlayacağı izinlere nasıl dönüştüreceğinizi belirler. Bu genellikle şunların kararını gerektirir:

• Uygulamada hangi rollerin var olduğu (admin, yönetici, görüntüleyici vb.)
• Kullanıcıların hangi takımlara veya çalışma alanlarına ait olduğu
• Her rolün neler yapabileceği ve her takımın neleri görebileceği
• Kimin otomatik erişim kazandığı ve kimin onaya ihtiyaç duyduğu

Çoğu problemi iki risk yaratır:

• Yanlış eşlemeler. Bir grup adı yanlış role uyar veya geniş bir "All Employees" grubu yanlışlıkla admin yetkisi verir.
• Eksik claim'ler. IdP bazı kullanıcılar için grupları göndermiyor, bir öznitelik boş geliyor veya token çok büyük olduğu için kırpılıyor.

Eksik veya beklenmeyen veriler asla kazara erişime dönüşmemesi için uygulamanızın güvenli varsayılanları olmalı.

SAML ile OIDC claim'leri basitçe

SSO ile oturum açtığınızda, IdP uygulamanıza hakkınızda küçük bir veri paketi gönderir. Her bir veri parçası bir claim'dir; temel olarak "email = [email protected]" veya "department = Finance" gibi etiketli bir alandır.

SAML ve OIDC benzer verileri taşıyabilir, ama paketleme biçimleri farklıdır.

SAML, daha eski kurumsal kurulumlarda yaygındır. Genellikle bir XML belgesi (assertion) ile attribute'lar gönderir. Bu attribute'lar uygulamanızın okuduğu claim'lerdir.

OIDC daha yenidir ve OAuth 2.0 üzerine kuruludur. Genellikle imzalı bir JSON token (ID token) ve isteğe bağlı kullanıcı bilgisi gönderir; token içindeki alanlar claim'lerdir.

İç uygulamalar için genelde küçük bir claim seti önemlidir:

• E-posta adresi
• IdP'den gelen kalıcı kullanıcı kimliği (subject)
• Tam ad (veya isim ve soyisim)
• Grup üyelikleri (takımlar, güvenlik grupları)
• Departman veya iş unvanı

Bir ayrım birçok karışıklığı önler:

Kimlik doğrulama (authentication) "bu kullanıcı kim?" sorusunu cevaplar. sub gibi kalıcı kullanıcı kimlikleri ve e-posta, SSO oturumunu doğru hesaba bağlamanıza yardım eder.

Yetkilendirme (authorization) "ne yapabilir?" sorusunu cevaplar. Grup veya departman gibi claim'ler, kullanıcıyı uygulama içi rollere ve takımlara eşleştirmenize yardım eder.

İki kişi başarılı şekilde kimlik doğrulayabilir, ama yalnızca "Finance" grubuna ait claim olan kişi fatura ekranına erişebilmelidir.

Roller ve takımlar: neye eşleştireceğinize karar verin

SAML attribute'larını eşleştirmeden veya OIDC claim'lerini izinlere dönüştürmeden önce uygulamanızın bilmesi gereken iki farklı şeyi netleştirin:

• Roller, birinin ne yapabileceğini (izinleri) tanımlar.
• Takımlar, nerede yer aldıklarını (kapsam) belirtir.

Roller şu tür soruları yanıtlar: bu kişi görüntüleyebilir, düzenleyebilir, onaylayabilir, dışa aktarabilir, kullanıcıları yönetebilir veya ayarları değiştirebilir mi?

Takımlar ise şu tür soruları yanıtlar: bu kişi hangi departman, bölge, kuyruk veya maliyet merkezinde çalışıyor ve hangi kayıtları görmeli?

Rolleri küçük ve stabil tutun. Çoğu iç uygulama, insanlar yer değiştirip gitseler bile nadiren değişen birkaç role ihtiyaç duyar. Takımlar ise günlük gerçekliği yansıtmalı: Support Tier 2, EMEA kapsama alanı, geçici bir kuyruk sahibi gibi.

En az ayrıcalık (least privilege) en güvenli varsayılandır. Birçok iç uygulama üç rol ile iyi işler:

• Viewer: verileri okuyabilir ve arama yapabilir
• Editor: kayıt oluşturabilir ve güncelleyebilir
• Admin: ayarları, kullanıcıları ve erişim kurallarını yönetebilir

Her rolün ne yaptığını açık ve sade bir dille yazın. Bu, bir grup adı değiştiğinde "sürpriz admin" erişimini önler ve ileride incelemeleri kolaylaştırır.

Grup tabanlı erişim: IdP grupları hakkında nasıl düşünmelisiniz

Grup tabanlı erişim, uygulamanızın izinleri kişi bazında karar vermemesi anlamına gelir. Bunun yerine IdP, grup üyeliğini yönetir ve uygulamanız bu grupları rollere ve takımlara eşler.

Önce bir grubun ne sağladığını karar verin. Birçok araçta bir grup tek bir role (ör. "Support Agent") ve isteğe bağlı olarak bir takıma (ör. "Tier 2") eşlenir. Önemli olan eşlemenin sıkıcı ve öngörülebilir olmasıdır: aynı grup her zaman aynı erişimi vermelidir.

Kullanıcılar birden çok gruba ait olduğunda

Kullanıcılar sıklıkla birden fazla IdP grubuna ait olur. Bunu nasıl çözeceğinize dair bir kuralınız olmalı ve bu kural sabit kalmalıdır.

Yaygın yaklaşımlar:

• Toplayıcı (additive) kurallar: tüm eşleşen grupların izinlerini birleştir (izinler dar kapsamlıysa işe yarar)
• Öncelik kuralları: en yüksek öncelikli grubu seç ve diğerlerini görmezden gel (roller çatıştığında kullanışlıdır)
• Hibrit: takımlar için ekleyici, roller için öncelik

Ne seçerseniz seçin, belgeleyin. Sonradan bunu değiştirmek kullanıcıların aniden erişim kazanmasına veya kaybetmesine neden olabilir.

Ölçeklenebilir bir adlandırma konvansiyonu kullanın

Açık grup isimleri hataları azaltır ve denetimleri kolaylaştırır. Pratik bir örüntü:

• --

Örneğin support-tool-prod-agent veya finance-tool-staging-viewer. Bu, "Admins" gibi belirsiz isimlerin farklı uygulamalarda tekrar kullanılmasını önlemeye yardımcı olur.

Bir kullanıcı ilgili hiçbir gruba ait değilse, varsayılan olarak erişim vermeyin (veya açıkça sınırlı bir misafir durumu) ve erişim talep etme yolunu gösteren bir mesaj gösterin.

Hesap bağlantısı: SSO kullanıcılarını uygulama hesaplarına eşleme

SSO birinin kim olduğunu kanıtlar, ama uygulamanız yine de o kimliği hangi mevcut hesaba bağlayacağını kararlaştırmalıdır. Hesap bağlantısı yapılmazsa, aynı kişi zaman içinde birden fazla hesaba sahip olabilir çünkü tanımlayıcılar değişir: yeni e-posta, isim güncellemesi, farklı bağlı kuruluşlara geçiş, IdP değişikliği.

Birincil eşleme için tek, kararlı bir anahtar seçin.

• OIDC için genellikle IdP'nin sub claim'i kullanılır.
• SAML için genellikle kalıcı bir NameID veya özel, değişmez bir kullanıcı ID özniteliği kullanılır.

Bu değeri "IdP kullanıcı ID'si" olarak saklayın ve IdP issuer/entity ID ile eşleştirin, böylece aynı sub farklı bir IdP'den gelirse çakışma olmaz.

E-posta faydalıdır ama onu kesin gerçek (source of truth) olarak kabul etmeyin. İnsanlar yeniden adlandırma, domain göçleri veya birleşmeler sırasında e-posta değiştirir. Alias'lar ve paylaşılan posta kutuları da beklenmedik eşleşmelere neden olabilir. E-posta ile eşleme yapıyorsanız, bunu sadece IdP sinyali doğrulandığında ve tek seferlik onay adımı düşünerek yapın.

İlk oturumda, çoğu iç araç şu işe alım (onboarding) desenlerinden birini seçer:

• Otomatik oluşturma: hemen bir hesap oluştur ve minimum erişim ver.
• Davetiye-only: sadece uygulamada önceden oluşturulmuş (veya ön onaylı) kullanıcıların girişine izin ver.
• Onay akışı: hesabı oluştur, fakat rol/takım ataması bir yönetici veya admin onayına kadar etkinleştirme.

Güvenli bir varsayılan, otomatik oluşturma ama varsayılan olarak izin vermeme, sonra gruplara veya onay adımına göre erişim vermektir.

Adım adım: claim'leri rollere ve takımlara eşleyin

İyi claim eşleştirme, SSO'yu görünmez kılmalıdır: insanlar oturum açar ve doğru yerde, doğru erişimle karşılaşır.

Başlarken erişim modelinizi sade bir dille yazın. Her rolü (Viewer, Agent, Manager, Admin) ve her takımı (Support, Finance, IT) listleyin; kimlerin neden bu role/takıma sahip olması gerektiğini belirtin.

Sonra IdP'nin gerçekte neler gönderebileceğini doğrulayın. SAML veya OIDC için genelde kararlı bir kullanıcı ID'si (subject veya NameID), e-posta ve bir veya daha fazla grup attribute'u istersiniz. Grup değerlerini tam olarak IdP'de göründüğü şekilde kaydedin; büyük-küçük harf farkına dikkat edin. "Support" ve "support" aynı şey değildir.

Pratik bir akış:

• Roller ve takımları tanımlayın ve her biri için bir sahibi atayın (değişiklikleri onaylayabilecek bir kişi).
• IdP'den gelen kullanılabilir claim'leri ve tam grup isimlerini listeleyin; uç durumları (sözleşmeli çalışanlar, paylaşılan posta kutuları) dahil edin.
• Eşleme kurallarını yazın: grup->rol, grup->takım ve birden fazla grup eşleştiğinde geçerli olacak öncelik sırası.
• 3–5 gerçek kullanıcı tipi ile test edin (yeni çalışan, yönetici, sözleşmeli çalışan, admin) ve gerçek IdP hesaplarını kullanın.
• Her test kullanıcısı için beklenen rol/takım sonucunu önce yazın, sonra oturum açıp karşılaştırın.

Kuralları somutlaştırmak için küçük bir örnek tutun. Bir kullanıcı okta-support içindeyse, Support takımı ve Agent rolü verilsin. Eğer aynı kullanıcı okta-support-managers içindeyse Manager rolü Agent'ın yerine geçsin.

Son olarak, basit bir hata ayıklama (debug) yolu ekleyin. Alınan ham claim'leri güvenli şekilde loglayın, hangi kuralların eşleştiğini ve son rol/takım sonucunu kaydedin. Birisi "oturum açtım ama aracımı göremiyorum" dediğinde bu, tahmine dayalı bir süreç yerine hızlı bir kontrole dönüşür.

Claim eksik olduğunda güvenli varsayılanlar

Eksik claim'ler normaldir. IdP hizmet hesapları için grupları göndermeyebilir, bir bağlayıcı (connector) bir alanı atlayabilir veya bir kullanıcı geçiş sürecinde olabilir. "Veri yok"u "güven yok" olarak ele alın.

En güvenli varsayılan reddetmek olmalıdır: rol yok, takım yok, erişim yok. Birinin erişim isteğinde bulunabilmesi için girişe izin vermeniz gerekiyorsa, bunu salt-okuma ve açıkça sınırlı tutun.

Bir davranış seçin ve belgeleyin:

• Girişi engelle ve net bir mesaj göster: "Hesabınıza atanan erişim yok. Destek ile iletişime geçin."
• Uyarı ile sınırlı erişime izin verin ve hassas işlemleri devre dışı bırakın.
• Kullanıcı kaydını oluşturun ama rol veya takım atamayın; onay beklesin.

Hiçbir zaman geçici bile olsa admin'i varsayılan yapmayın.

Kısmi verilere hazırlıklı olun. E-posta var ama grup yoksa hâlâ hesap oluşturup onaya yönlendirebilirsiniz. Grup var ama kalıcı bir kimlik yoksa otomatik eşlemeyin; yanlış kişiye bağlama riski vardır.

Arıza durumları için bir yükseltme yolu belirleyin:

• Atanmış bir sahip (IT veya uygulama yöneticisi) who can approve access
• Denetim notu ile manuel rol atama akışı
• Bir sonraki oturumda claim'leri yeniden kontrol etme yolu
• "Beklemede" hesaplar için zaman aşımı

Değişiklikleri, kaldırmaları ve offboarding'i (işten ayrılma) yönetme

İnsanlar takım değiştirir, yönetici değiştirir ve şirketten ayrılır. SSO kurulumunuz bunu normal olarak kabul etmelidir.

Birisi takım değiştirdiğinde, erişimi bir sonraki oturumda güncelleyin: grup claim'lerini yeniden değerlendirin ve mevcut eşlemeyi uygulayın. Bir kere verildi diye erişimin sonsuza dek kalmasına izin vermeyin.

Ayrılanlar farklıdır. Sadece bir sonraki oturumu beklemek yeterli değildir. Erişiminin hızlıca sonlanmasını istersiniz, hatta aktif bir oturumları olsa bile. Bu genelde hesabı IdP'de devre dışı bırakmak anlamına gelir ve uygulamanız devre dışı veya eksik kimlik geldiyse hemen engellemelidir.

Deprovisioning (erişimi kaldırma) öngörülebilir olmalıdır: kullanıcıyı devre dışı bırakın, takım üyeliklerini kaldırın ve denetim verilerini saklayın. Genellikle onaylar, yorumlar ve geçmiş gibi kayıtları uyumluluk için korurken yeni işlemleri engellemek istersiniz.

Sözleşmeli çalışanlar ve geçici erişim ekstra dikkat ister. IdP'de zamanlı gruplara koyun veya rollere bir inceleme tarihi ekleyin ki proje bittikten sonra erişim sürüp gitmesin.

Pratik bir offboarding politikası:

• Her oturumda claim'leri tekrar kontrol edin ve takım üyeliğini IdP'den yenileyin
• Kullanıcı gerekli gruplardan çıkarıldığında yetkileri hemen düşürün (bir sonraki oturum veya senkron)
• Hesabı devre dışı bırakın ama denetim kayıtlarını ve sahiplik geçmişini koruyun
• Sözleşmeli erişim için bir bitiş tarihi zorunlu kılın ve yenileme öncesi gözden geçirin
• Finans veya admin gibi hassas roller için periyodik erişim incelemeleri yapın

Sık yapılan hatalar ve tuzaklar

Çoğu SSO kesintisi SAML veya OIDC'nin "zor" olmasından değil, uygulamanın insanlar, gruplar ve tanımlayıcılar hakkında güvenli olmayan varsayımlar yapmasından kaynaklanır.

Yaygın bir hata rol eşleştirmeyi takım eşleştirmeyle karıştırmaktır. Roller "ne yapabilirsin?" Takımlar ise "nerede yer alıyorsun?" Eğer bir takım grubunu direkt güçlü bir role (Admin gibi) eşlerseniz, o takımda olan herkese geniş yetki vermiş olursunuz.

Bir diğer tuzak ise hesap bağlantısı için yalnızca e-postaya güvenmektir. E-postalar değişir ve alias'lar çoğaltmalara yol açabilir. Birincil anahtar olarak kalıcı IdP kullanıcı ID'sini (subject/NameID gibi) tercih edin ve e-postayı gösterim/iletişim alanı olarak kullanın.

Diğer sık problemler:

• Gruplar eksikken sistemin açık bırakılması (grup yoksa erişimi tam veya yüksek seviyede vermeyin)
• Belirsiz grup adlarının dev, staging ve prod arasında tekrar kullanılması
• Grup üyeliğini izin listesi gibi ele alıp her bir grubun ne anlama geldiğini incelememek
• Birden çok takıma ihtiyaç duyan kullanıcıları admin olmaya zorlayacak sınırlı takım mantığı
• Partnerler ve yüklenicileri çalışan-only takımlardan izole etmeyi unutmak

Canlıya almadan önce uç durumları test edin. Örneğin bir finans analisti olay müdahalesinde iki takıma ve bir yükseltilmiş role ihtiyaç duyabilir. Eğer kurallarınız sadece tek takım izin veriyorsa, ya erişimi kaybeder ya da aşırı yetkilendirilir.

Canlıya almadan önce hızlı kontrol listesi

Herkes için SSO'yu etkinleştirmeden önce her takımdan birkaç test hesabıyla kuru çalıştırma yapın. Çoğu erişim sorunu yeni bir çalışan, rol değişikliği ve offboarding durumu test edildiğinde hemen ortaya çıkar.

Hesap bağlantısıyla başlayın. Zaman içinde değişmeyecek tek bir eşleyici seçin. OIDC'de bu genelde sub, SAML'de genelde NameID veya belirli bir değişmez özniteliktir.

Sonra claim'lerin eksik olduğu durumda ne olacağını kararlaştırın. En güvenli varsayılan, grup veya rol claim'leri yoksa yükseltilmiş erişim vermemektir (çoğu uygulamada erişim vermemek). İş akışınıza uyuyorsa insanları şifrelenmiş, düşük ayrıcalıklı bir role alabilecek en az bir rol bulundurun.

Basit bir ön-canlı kontrol listesi:

• Bağlama tanımlayıcınızın kararlı ve benzersiz olduğunu doğrulayın (ve loglarda görebilin)
• Eksik grup claim'lerinin düşük ayrıcalıklı rolden öte erişim vermediğini doğrulayın
• Admin erişimi için açık bir admin grubunu ve ek bir onay adımını zorunlu kılın
• Bir kullanıcı bir gruptan çıkarıldığında erişimin bir sonraki oturumda (veya senkron) düştüğünü test edin
• Eşleme kurallarını bir sayfada özetleyin ki bir ekip arkadaşı anlayabilsin

Örnek: destek ve finans iç aracı için SSO grupları

Destek, Finans ve birkaç yönetici tarafından günlük kullanılan bir operasyon aracını hayal edin. İnsanların oturum açıp doğru ekranları ve işlemleri hemen görmesini istiyorsunuz, admin'in hesapları elle düzeltmesine gerek kalmadan.

Birkaç IdP grubu oluşturun ve bunları uygulama içi rollere ve takımlara eşleyin:

• ops-support -> Rol: Support Agent, Takım: Support
• ops-finance -> Rol: Finance Analyst, Takım: Finance
• ops-managers -> Rol: Manager, Takım: Management

Bunun nasıl işlediğine bakalım.

Şimdi bir e-posta değişikliği örneği: Omar [email protected] adresinden [email protected] adresine geçti. Uygulama hesapları e-posta yerine kalıcı IdP kullanıcı kimliğiyle (OIDC için sub, SAML için kalıcı NameID) ilişkilendirdiği için, tekrar eden hesap oluşmaz. Aynı geçmişe ve denetim izine sahip olur.

Erişimi tahmin etmeden doğrulamak için bir "effective access" görüntüsü tutun: kullanıcının bağlı IdP kimliği, alınan gruplar, sonuçta atanan rol ve takım gösterilsin. Bir şey yanlış görünürse, bunun IdP kaynaklı mı, eşleme kuralı mı yoksa eksik claim mi olduğunu hızlıca söyleyebilirsiniz.

Sonraki adımlar: organizasyon değiştikçe erişimi öngörülebilir tutun

Zor olan ilk dağıtımdan sonra değil. Zor olan reorganizasyonlar, yeni takımlar ve "geçici" istisnalarla erişimi makul tutmaktır.

Bir sayfalık eşleme dokümanı tutun, bu doküman şunları cevaplamalıdır:

• Hangi IdP grupları hangi uygulama rolleri ve takımlarıyla eşlenir
• Bir claim eksik olduğunda varsayılan davranış nedir (ve değişiklikleri kim onaylar)
• Her yüksek riskli rolün sahibi kimdir (finance admin, user admin, data export)
• Sözleşmeliler ve hizmet hesapları nasıl ele alınır
• Doğruluk kaynağı nerede saklanır (IdP mi yoksa uygulama mı)

Sınırları net olan bir departmanla küçük bir pilot çalışması yapın, uç durumları düzeltin, sonra yeni kurallar icat etmeden genişleyin. Gerçek zarar verebilecek erişimler için periyodik incelemeler yapın: admin ve yüksek riskli roller için aylık, normal roller için çeyreklik gibi.

Kendiniz iç uygulamayı geliştiriyorsanız, roller, takımlar ve iş mantığının yakın olması işleri kolaylaştırır; değişiklikleri test etmek daha basit olur. AppMaster (appmaster.io) gibi araçlar, rolleri ve iş akışlarını görsel olarak modelleyip gerektikçe gerçek backend, web ve mobil kodu yeniden üretmeyi sağlayarak tek seferlik izin düzeltmelerinin birikmesini önleyebilir.