Bir üniversitede tek bir kişi; ana web sitesine, bir fakülte portalına, kütüphane sistemine, bir öğrenme platformuna ve daha onlarca uygulamaya erişmek zorunda kalabilir. Hiç kimse de bunların her birine ayrı ayrı giriş yapmak istemez. Tek oturum açma (SSO), bu sorunu kullanıcının bir kez, tek bir kurumsal kimlik bilgisiyle kimlik doğrulaması yaparak bağlı tüm sistemlere erişmesini sağlayarak çözer. Bir üniversitenin dijital varlığının merkezinde duran bir Drupal sitesi için, kurumun SSO altyapısıyla entegrasyon, projenin en önemli parçalarından biridir.
Bu rehber, Drupal SSO entegrasyonunun nasıl çalıştığını ve daha da önemlisi, doğru yaklaşımın nasıl seçileceğini açıklıyor. Üniversitelerin dayandığı dört teknolojiyi (SAML, Shibboleth, LDAP ve CAS), her birinin ne zaman uygun olduğunu, entegrasyonun Drupal tarafında nasıl işlediğini ve çoğu adım-adım rehberin atladığı kimlik yönetişimi ile güvenlik kararlarını ele alıyoruz.
Tek Oturum Açma Gerçekte Ne Anlama Gelir?
Tek oturum açma, bir kullanıcının güvenilir merkezi bir otoriteye bir kez giriş yapıp ardından ona bağlı her uygulama tarafından otomatik olarak tanınmasına dayanan bir kimlik doğrulama modelidir. Temel ilke ve güvenlik avantajı şudur: Tek tek uygulamalar kullanıcının şifresini hiçbir zaman işlemez. SSO devredeyken kimlik bilgileri, her sistem tarafından ayrı ayrı saklanıp kontrol edilmek yerine tek bir yerde ve tek bir politika seti altında doğrulanır.
Bir üniversite için bu, aynı anda birkaç düzeyde önem taşır. Öğrenciler ve personel onlarca hizmet boyunca tek bir kimliğe sahip olur. BT ekibi kimlik doğrulamayı merkezî olarak yönetir; tutarlı şifre kurallarını ve çok faktörlü kimlik doğrulamayı her yerde uygular. Ve biri kurumdan ayrıldığında, tek bir merkezî hesabı devre dışı bırakmak her şeye erişimi keser; sistemlere dağılmış sahipsiz girişler bırakmaz. Kolaylık ile denetimin bu birleşimi, SSO'yu ciddi her kurumsal web platformu için fiilen bir zorunluluk hâline getirir.
Temel Yapı: Kimlik Sağlayıcı ve Hizmet Sağlayıcı
Her SSO kurulumu iki rol içerir ve bunları anlamak diğer her şeyi netleştirir.
Kimlik Sağlayıcı (IdP), kullanıcı kimliklerini tutan ve kimlik bilgilerini doğrulayan güvenilir merkezî otoritedir; kurumun Shibboleth servisi, Active Directory'si ya da CAS sunucusu gibi. Hizmet Sağlayıcı (SP) ise kullanıcının erişmek istediği uygulamadır; bu durumda Drupal sitesi. Bir kullanıcı Drupal SP'ye erişmeye çalıştığında, Drupal kimlik doğrulamayı IdP'ye devreder; IdP kullanıcıyı doğrular ve ad, e-posta ve rol gibi özniteliklerle birlikte onay gönderir; Drupal da bu güvenilir yanıta dayanarak erişim verir. Standart üniversite kurulumunda Drupal Hizmet Sağlayıcı olarak çalışır, kurumun mevcut sistemi ise Kimlik Sağlayıcıdır. Bu ilişkiyi doğru kurmak, her SSO entegrasyonunun temelidir.
Dört Yaklaşım: SAML, Shibboleth, LDAP ve CAS
Üniversiteler SSO için tipik olarak dört teknolojiden birine dayanır. Bunlar amaç bakımından örtüşür, ancak köken, mekanizma ve en uygun oldukları yer bakımından farklılaşır.
SAML
SAML (Security Assertion Markup Language), modern kurumsal SSO'nun çoğunun temelini oluşturan açık standarttır. Bir IdP ile bir SP arasında kimlik doğrulama ve yetkilendirme verisi alışverişi için kullanılan XML tabanlı bir protokoldür ve hemen hemen her büyük kimlik platformuyla entegre olur: Microsoft Entra ID, Okta, ADFS, Google Workspace ve daha fazlası. Drupal'da SAML, sitenin Hizmet Sağlayıcı olarak çalışmasını ve kimlik doğrulamayı SAML uyumlu herhangi bir IdP'ye devretmesini sağlayan contrib modüllerle ele alınır. En geniş uyumluluğa sahip seçenektir ve diğer sistemlerin çoğunun konuşabildiği ortak dildir.
Shibboleth
Shibboleth, akademik dünyaya derinlemesine kök salmış, yaygın kullanılan belirli bir SAML uygulamasıdır. Yükseköğretim ve araştırmada federatif erişimin bel kemiğidir; bir öğrencinin kendi kurumunda giriş yapıp başka bir kurumdaki kaynaklara erişmesini sağlayan ulusal ve uluslararası akademik federasyonların ardındaki teknolojidir. Teknik olarak Drupal'ı Shibboleth ile entegre etmek bir SAML entegrasyonudur: Drupal bir SAML Hizmet Sağlayıcı olarak çalışır, Shibboleth ise Kimlik Sağlayıcı görevini görür. Kurumunuz bir akademik kimlik federasyonunun parçasıysa, büyük olasılıkla bağlanacağınız sistem Shibboleth'tir.
LDAP
LDAP (Lightweight Directory Access Protocol), SAML ile aynı anlamda bir SSO protokolü değildir; kullanıcı dizinini sorgulamak için kullanılan bir protokoldür ve en yaygın olarak Microsoft Active Directory ile birlikte anılır. Bir üniversitedeki rolü, kimliğin altta yatan kaynağı olmaktır: Kimin var olduğunu, grup üyeliklerini ve özniteliklerini saklar. Drupal'ın LDAP entegrasyonu, kullanıcıların dizin kimlik bilgileriyle giriş yapmasını sağlar; Drupal hesaplarını dizin gruplarına göre otomatik oluşturabilir ve rol atayabilir. LDAP çoğu zaman bir SSO protokolünün yerine geçmek yerine onun arkasında duran katmandır ve özellikle kurumun Microsoft altyapısı üzerinde çalıştığı yerlerde yaygındır.
CAS
CAS (Central Authentication Service), kökleri Yale Üniversitesi'ne uzanan açık kaynaklı bir SSO protokolüdür ve yükseköğretimde hâlâ yaygın kullanılır. Özellikle web uygulaması SSO problemi için tasarlanmıştır ve LDAP gibi yetkilendirme depolarıyla rahatça birlikte çalışır. Drupal'da CAS entegrasyonu, kullanıcıları kimlik doğrulaması için kurumun merkezî CAS sunucusuna yönlendirir, ardından onları giriş yapmış kullanıcı olarak siteye geri getirir; roller CAS yanıtına göre atanabilir. Kampüs çapında bir CAS kurulumunu zaten işleten üniversiteler için Drupal'ı ona bağlamak doğal bir tercihtir.
Bir Üniversite Hangi Protokolü Seçmeli?
Pratikte tercih, genellikle kurumun zaten kullandığı sistem tarafından belirlenir; Drupal mevcut IdP'ye bağlanır, tersi değil. Aşağıdaki tablo her yaklaşımın ne zaman uygun olduğunu özetler.
| Yaklaşım | Nedir | Kime uygun |
|---|---|---|
| SAML | Federatif kimlik doğrulama için açık standart; en geniş uyumluluk. | Entra ID, Okta, ADFS ya da herhangi bir SAML IdP'ye bağlanmak. |
| Shibboleth | Akademik SAML uygulaması; araştırma federasyonlarının standardı. | Ulusal ya da uluslararası akademik federasyondaki kurumlar. |
| LDAP | Dizin protokolü; kullanıcı kimliğinin altta yatan kaynağı. | Microsoft Active Directory ortamları; rol atama. |
| CAS | Web odaklı açık kaynaklı SSO protokolü, kampüslerde yaygın. | Kampüs çapında CAS sunucusu olan kurumlar. |
Pratik kural basittir: Kurumunuzun zaten işlettiği kimlik sağlayıcıyı belirleyin, ardından ona konuşan Drupal entegrasyonunu seçin. Akademik federasyondaki bir üniversite Drupal'ı Shibboleth'e bağlar; Microsoft üzerine standartlaşmış bir kurum SAML ile Entra ID'ye ya da LDAP ile Active Directory'ye bağlanır; kampüs CAS sunucusu işleten bir kurum CAS'e bağlanır. Bu nadiren sıfırdan bir tercihtir; doğru cevap genellikle zaten var olan kimlik altyapısı tarafından belirlenir.
SSO Drupal Tarafında Nasıl Çalışır?
Drupal tarafında SSO, çekirdek yerine contrib modüllerle ele alınır ve her protokol için olgun bir ekosistem vardır. Hangi modül kullanılırsa kullanılsın, entegrasyon birkaç temel işi yürütür: Kimliği doğrulanmamış kullanıcıları IdP'ye yönlendirir, kimlik doğrulama yanıtını alıp doğrular ve IdP'nin döndürdüğü öznitelikleri bir Drupal hesabına eşler.
Burada anlaşılmaya değer bir kavram, tam zamanında (JIT) hesap oluşturmadır. Olası her kullanıcı için önceden bir Drupal hesabı oluşturmak yerine, JIT hesap oluşturma, bir kişi IdP üzerinden ilk kez başarıyla kimlik doğruladığında hesabı otomatik olarak oluşturur ve IdP'nin sağladığı özniteliklerle (ad, e-posta, rol) doldurur. SSO'yu bütün bir üniversiteye ölçeklendiren şey budur: Hiçbir yönetici binlerce hesabı elle oluşturmaz ve rol atama, IdP'nin bildirdiği grup üyeliklerine göre otomatik yürütülebilir. Belirli modülleri değerlendiren kurumlar için, resmî Drupal.org proje sayfaları SimpleSAMLphp Authentication, LDAP ve CAS için güncel ve desteklenen seçenekleri belgeler.
Kimlik Yönetişimi: Çoğu Rehberin Atladığı Kısım
Çoğu SSO eğitimi, giriş çalışır çalışmaz durur. Ancak hassas öğrenci ve personel verisiyle çalışan bir üniversite için daha zor ve daha önemli sorular yönetişimle ilgilidir: Kimin erişimi var, erişim nasıl kaldırılıyor ve kimlik gerçekte nerede yaşıyor. İyi tasarlanmış bir entegrasyonu yalnızca işlevsel olandan ayıran şey burasıdır.
Temel ilke şudur: Drupal, kurumsal kimlik sağlayıcının yanında kendi ayrı kullanıcı hesabı havuzunu tutmamalıdır. Yerel Drupal hesapları bağımsız olarak var olduğunda senkronizasyonu bozulur: Biri ayrıldığında devre dışı bırakılmazlar ve zamanla zayıf şifreler biriktirirler. Önerilen uygulama, acil durumlar için tutulan tek bir "break-glass" (cam kırma) yönetici hesabı dışında herkes için yerel şifre doğrulamasını kapatmak, tüm kimlik doğrulamayı IdP üzerinden yönlendirmek ve kurumun çok faktörlü kimlik doğrulamasını, şifre politikasını ve hesap yaşam döngüsünü o üst kaynaktan devralmaktır. Başka bir deyişle, kimin giriş yapabileceğine dair tek doğruluk kaynağı Drupal değil, kurumun kimlik sistemi olur.
Bu yaklaşım somut bir güvenlik avantajı sağlar: Erişim iptali (deprovisioning). Bir öğrenci mezun olduğunda ya da bir personel ayrıldığında, onların merkezî kimlik hesabını devre dışı bırakmak, geride hiçbir sahipsiz yerel giriş bırakmadan Drupal erişimini de her şeyle birlikte anında keser. Veri korumasından sorumlu bir kurum için, bu tek ve merkezî kapatma düğmesi, her sistemde ayrı hesapların izini sürmeye çalışmaktan çok daha güvenlidir.
Üniversite Senaryoları: Multisite, Yaşam Döngüsü ve Mezunlar
Üniversite bağlamında SSO, tek bir kurumsal sitenin hiç karşılaşmadığı birkaç senaryo getirir:
- Çoklu site tek oturum açma: Büyük üniversiteler çok sayıda site işletir; ana sitenin yanında fakülteler, bölümler ve araştırma merkezleri için ayrı siteler. SSO, bir kullanıcının bir kez giriş yapıp hepsinde sorunsuzca dolaşmasını sağlarken kimlik doğrulama merkezî kalır. Bu, çok sayıda sitenin tek yerden yönetildiği Drupal'ın multisite mimarisiyle doğal biçimde eşleşir.
- Kimlik yaşam döngüsü: Bir kişinin üniversiteyle ilişkisi zamanla değişir; aday, öğrenci, mezun ve bazen personel olur. Erişim ihtiyaçları da bununla değişir. Drupal rollerini IdP'nin özniteliklerinden yürütmek, erişimin her geçişte elle ayarlanmak yerine bu yaşam döngüsünü otomatik olarak izlemesi anlamına gelir.
- Farklı topluluklar: Öğrenciler, akademisyenler, personel ve mezunlar çoğu zaman farklı sistemlere farklı düzeylerde erişime ihtiyaç duyar. IdP grup üyeliğini bildirdiği için Drupal, her topluluğu uygun role otomatik olarak eşleyebilir ve izinleri kullanıcının gerçek durumuyla uyumlu tutabilir.
Bu senaryolar, kimlik entegrasyonunun neden sonradan akla gelen bir şey değil, bir üniversite platformu kurmanın çekirdek parçası olduğunu tam olarak açıklar. Ayrıca bir Drupal sitesinin tipik olarak ihtiyaç duyduğu daha geniş akademik entegrasyonlara da bağlanırlar; bunların arasında bir öğrenme platformu da vardır ki bunu Moodle ve Drupal entegrasyonu rehberimizde ele alıyoruz.
Sık Yapılan SSO Hataları ve Bunlardan Kaçınma Yolları
- IdP'nin yanında yerel hesap işletmek: En sık yapılan yönetişim hatasıdır. Bağımsız Drupal hesaplarının senkronizasyonu bozulur, erişimleri iptal edilmez ve zayıf şifreler biriktirirler. Kimlik doğrulamayı IdP üzerinden yönlendirin ve yalnızca bir break-glass yönetici hesabını yerel tutun.
- Break-glass hesabını unutmak: Her giriş IdP'ye bağlıysa ve IdP erişilemez hâle gelirse, yöneticiler dahil kimse giremez. İyi korunan tek bir yerel acil durum hesabı, tam bir kilitlenmeyi önler.
- Rolleri dikkatsizce eşlemek: IdP özniteliklerinden otomatik olarak yükseltilmiş Drupal rolleri vermek, istemeden yönetici erişimi dağıtabilir. Her özniteliği ihtiyaç duyduğu en düşük yetkiye eşleyin ve yönetici rollerini ekstra titizlikle ele alın.
- Erişim iptalini göz ardı etmek: Yalnızca girişin çalışmasına odaklanmak, daha önemli soruyu (erişimin nasıl kaldırıldığını) yanıtsız bırakır. Yalnızca birinin katıldığı anı değil, ayrıldığı anı da tasarlayın.
- Protokolü yalıtılmış biçimde seçmek: Kurumun zaten ne kullandığını kontrol etmeden bir SSO teknolojisi seçmek gereksiz karmaşıklığa yol açar. Mevcut kimlik sağlayıcıdan başlayın ve ona bağlanın.
- Öznitelik eşlemesini ihmal etmek: IdP'nin öznitelikleri Drupal alanlarına ve rollerine doğru eşlenmezse, kullanıcılar giriş yapabilir ama yanlış izinlerle karşılaşır. Öznitelik eşlemesini en az giriş akışı kadar dikkatle doğrulayın.
Doğru yapıldığında SSO entegrasyonu, bir Drupal sitesini bir üniversitenin dijital ekosisteminin sorunsuz ve güvenli bir parçası hâline getirir; tek kimlik, merkezî olarak yönetilen ve bağlı her sistemi kapsayan. Bu, Drupal'ı ölçekte işleten her kurum için temel bir yetenektir ve eğitimde Drupal genel bakışımızda incelenen daha geniş akademik entegrasyonlar bütününün bir parçasıdır. Nitekim Drupart bünyesinde Drupal4edu ekibinin Sabancı Üniversitesi, ODTÜ ve Yıldız Teknik Üniversitesi gibi kurumlar için geliştirdiği Drupal platformlarında, kurumsal kimlik sistemleriyle entegrasyon bu bütünün doğal bir parçasıdır.
Drupal SSO Hakkında Sıkça Sorulan Sorular
SSO etkinken Drupal şifreleri saklar mı?
Hayır; SSO'nun temel güvenlik avantajı budur. Kimlik doğrulama bir kimlik sağlayıcıya devredildiğinde, kullanıcı kimlik bilgileri IdP tarafından doğrulanır ve Drupal'da hiçbir zaman saklanmaz. Önerilen yapılandırma, acil durumlar için tutulan tek bir break-glass yönetici hesabı dışında yerel şifre doğrulamasını tamamen kapatır. Bu, şifrelerin, şifre politikasının ve çok faktörlü kimlik doğrulamanın tümünün kurumun merkezî kimlik sisteminde yaşaması ve Drupal'ın yalnızca onun doğrulanmış yanıtına güvenmesi anlamına gelir.
Drupal aynı anda birden fazla kimlik sağlayıcı kullanabilir mi?
Evet; kullanılan modüllere bağlı olarak Drupal, birden fazla kimlik doğrulama kaynağıyla çalışacak şekilde yapılandırılabilir. Yaygın bir örnek, öğrencileri bir sistem, personeli başka bir sistem üzerinden doğrulayan ya da çoğu kullanıcı için SAML'i korurken belirli bir grup için sınırlı bir yerel seçenek tutan bir kurumdur. Yapılandırma her kaynakla birlikte karmaşıklaşır; bu nedenle pratik öneri, yalnızca gerçek bir ihtiyaç olan kimlik sağlayıcıları desteklemek ve kurulumu kurumun gerçek gereksinimlerinin izin verdiği kadar basit tutmaktır.
Kimlik doğrulama ile hesap oluşturma (provisioning) arasındaki fark nedir?
Kimlik doğrulama, bir kullanıcının kim olduğunu doğrulamaktır; kimlik bilgilerini kimlik sağlayıcıya karşı teyit etmek. Hesap oluşturma (provisioning) ise kullanıcının hesabını ve özniteliklerini Drupal'da oluşturmak ve sürdürmektir. SSO kimlik doğrulamayı üstlenir; tam zamanında (JIT) hesap oluşturma ise onu izleyen hesap oluşturmayı üstlenir, ilk girişte otomatik olarak bir Drupal hesabı üretir ve IdP'nin özniteliklerinden doldurur. Birlikte çalışırlar: Kimlik doğrulama kimliği kanıtlar, hesap oluşturma ise o kimliğe Drupal içinde bir yer ve bir rol verir.
Bir üniversite için SAML mi CAS mi daha iyi?
Hiçbiri evrensel olarak daha iyi değildir; kurumunuzun zaten ne kullandığına bağlıdır. SAML, akademik uygulaması Shibboleth de dahil, araştırma federasyonlarındaki ya da Entra ID veya Okta gibi kimlik platformları üzerine standartlaşmış kurumlar için doğru tercihtir. CAS, kampüs çapında bir CAS sunucusunu zaten işleten üniversiteler için güçlü bir uyum sağlar. Karar, soyut bir sıralamayı değil mevcut kimlik altyapısını izlemelidir: Drupal'ı kurumunuzun zaten güvendiği sisteme bağlayın ve protokolü bunun belirlemesine izin verin.