Kurumsal SSO Entegrasyonu: OIDC ile Giriş ve Yetki Sınırları

Kimlik doğrulama ile yetkilendirmeyi ayırın

OIDC, OAuth 2.0 üzerinde kimlik katmanı sağlar ve kullanıcıya ilişkin bilgilerin doğrulanmış biçimde alınmasını tanımlar. [1] Bu, kullanıcının hangi müşteri hesabına bağlı olduğunu veya hangi raporu açabileceğini uygulamanızın ayrıca değerlendirmesi gerekmediği anlamına gelmez.

SSO teklifinde “giriş ekranı bağlanacak” yerine kimlik sağlayıcı, uygulama hesabı, şirket üyeliği ve rol eşleştirmesi ayrı teslimatlar olsun. Kullanıcı ilk kez geldiğinde hesap otomatik mi açılacak, davet mi gerekecek? Kurumsal alan adına sahip olmak tek başına her şirkete üyelik kanıtı sayılmamalıdır.

Kararlı kimlik eşleştirmesi kurun

E-posta adresi değişebilir. Kimlik sağlayıcının kullanıcı tanımlayıcısı ve sağlayıcı kimliği birlikte değerlendirilmelidir. Aynı e-posta görüldü diye iki hesabı kontrolsüz birleştirmeyin. OIDC standardında issuer ve subject gibi alanların rolü ve token doğrulama gereksinimleri tanımlanır. [1]

Kendi kullanıcı kaydınızla dış kimlik arasındaki bağlantıyı açık tutun. Bir müşterinin birden fazla kimlik sağlayıcısı kullanması veya birleşme sonrası sağlayıcı değiştirmesi mümkündür. Geçişte hesap geçmişinin korunması ve yanlış kişiye bağlanmaması için onaylı eşleştirme planı hazırlayın.

Örnek: aynı danışman iki şirkette çalışıyor

Varsayımsal danışman iki farklı şirketin sistemine erişiyor. Birinde rapor okuyucu, diğerinde proje yöneticisidir. Kullanıcının giriş yapması tek ve genel bir rol ataması üretmemelidir. Aktif şirket bağlamı ve o şirkete ait üyelik, her kritik işlemde dikkate alınmalıdır.

Bu model, kullanıcı arayüzünde şirket seçme alanı göstermekten daha fazlasıdır. İstek başka bir şirket kimliğiyle değiştirildiğinde sunucu erişimi reddedebilmelidir.

Token doğrulamayı hazır kütüphaneyle ama bilinçli yapın

Standartlara uygun, güncel kütüphaneler kullanmak tercih edilebilir; fakat yapılandırmanın doğruluğu test edilmelidir. İmza, issuer, audience ve süre gibi kontrollerin atlanmadığını doğrulayın. Akışa göre gerekli ek güvenlik kontrolleri OIDC dokümantasyonuyla birlikte ele alınmalıdır. [1]

Geliştirme kolaylığı için kapatılan doğrulamalar üretime taşınmamalıdır. Token veya gizli bilgileri günlük sistemine yazmayın. Başarısız girişin kullanıcıya açıklanması ile güvenlik ayrıntılarının dışarı sızdırılması arasında denge kurun.

Rol değişikliği ve ayrılışı prova edin

Kurumsal kullanıcı pasif hale geldiğinde mevcut uygulama oturumları nasıl etkileniyor? Grup üyeliği kaldırıldığında uygulama rolü hemen mi, sonraki girişte mi değişiyor? Bu davranış kimlik ve oturum mimarisine bağlıdır; sadece SSO çalışıyor diye otomatik varsayılmamalıdır.

Yetki kararlarının her istekte uygun biçimde doğrulanması temel bir ilkedir. [2] Uzun süre açık sekme, arka plan işi ve cihaz oturumu gibi yolları da test edin. Kullanıcı ayrıldığında sahip olduğu görev ve kayıtların devri ayrı bir operasyon adımı olabilir.

Kabul kapsamını hata yollarıyla tamamlayın

Yanlış sağlayıcı, süresi bitmiş token, başka uygulamaya ait token, üyeliği kaldırılan kullanıcı ve farklı şirket bağlamı senaryolarını test edin. Kimlik sağlayıcı geçici erişilemezken uygulamanın ne yaptığı açık olsun. Yönetici için acil erişim gerekiyorsa bu yol da ayrı güvenlik politikasıyla değerlendirilmelidir.

Teslim paketinde entegrasyon şeması, claim eşleştirmesi, kullanıcı açma-kapama davranışı ve destek yönergesi bulunsun. Kurumsal müşteriye yalnızca bir giriş düğmesi değil, yönetilebilir bir erişim yaşam döngüsü sunulmalıdır.

Sık sorulan sorular

### SSO kurunca uygulamadaki rol sistemi kaldırılabilir mi? Genellikle farklı sorumlulukları vardır. Dış gruplar uygulama rollerine eşlenebilir, ancak veri ve işlem yetkileri yine uygulamanın iş kurallarıyla yönetilmelidir.

E-posta alan adı şirket üyeliği için yeterli mi?

Tek başına güvenilir bir genel kural değildir. Davet, doğrulanmış sağlayıcı ve açık üyelik ilişkisi gibi koşullar iş modeline göre birlikte değerlendirilmelidir.