ADFS nedir? Ne işe yarar? Altyapı gereksinimleri nelerdir?
Active Directory Federation Services (ADFS), Windows Server rolleri arasında belki de çoğu kişinin göz atmadığı ve ne işe yaradığını bilmediği rollerden birisidir. 1.0 sürümü harici bir download olarak Windows Server 2003 R2 ile hayatımıza giren ADFS, Windows Server 2012’ye kadar işletim sisteminin dahili bir bileşeni olamadı ve IIS gibi ek rollerin kurulumuna ihtiyaç duydu. İlk olarak Windows Server 2012 ile IIS ihtiyacı ortadan kalktı ve işletim sisteminin dahili bir bileşeni haline gelip kendine ait konfigürasyon bileşenlerine sahip oldu.
ADFS, bir organizasyonda kullanılan web tabanlı uygulamalarda single-sign-on (tek oturumla giriş) yöntemi ile oturum açmayı sağlayan, kimlik doğrulama işlemini merkezi bir otorite üzerinden yapmayı mümkün kılan, claim tabanlı bir oturum açma hizmeti sağlayıcısıdır. Bu tanımı tam olarak anlayabilmek için “claim tabanlı” ifadesini daha da açmamız gerekiyor.
Claim, bir kimliğin belli bir kısmı tanımlayan bir bilgi parçasıdır. Kullanıcı adı, şifre, kullanıcının tam ismi, e-posta adresi gibi bilgiler birer claim örneğidir. Claim’ler, içindeki bilginin özgünlüğünü doğrulayan imzalara sahip authentication token’ları içerisinde tutulur. Daha açıklayıcı bir örnek vermek gerekirse: Ben, Halil İbrahim MOLLAOĞLU isimli kişi olduğumu iddia etmem için kimliğimi size ibraz etmem gerekir ve sizin de kimliğimin sahte bir kimlik olmadığını teyit etmek için kimliğin belli başlı otoriterler tarafından damgalandığını ve özgünlüğü ifade eden seri numarasına sahip olduğunu kontrol etmeniz gerek. İşte claim (iddia) tabanlı kimlik doğrulamanı yaptığı da tam olarak bu: İddianızı doğrulayarak sizi arka tarafta hizmet veren bir uygulamaya aktarmak. Dikkat edersiniz yetkilendirme, ADFS’in kapsamına girmiyor; onun işi sadece sizin iddia ettiğiniz kişi olduğunuzu doğrulamak. ADFS gerekli kimlik doğrulamasını yaptıktan sonra sizi uygulamaya aktarır ve uygulama kendi içerisindeki yetki tablosuna bakarak sizi içeri alır veya reddeder.
“Bunu zaten LDAP veya AD authentication ile uygulama içerisinde yapabiliyorum, neden ADFS kullanmalıyım?” diyebilirsiniz. İşte burada uygulamanıza “kimlik doğrulama” gibi aslında görevi olmayan bir iş yüklüyorsunuz ve en basitinden uygulamanızın oturum açma sayfasını dış dünyaya, yani bir diğer deyişle siber saldırılara açık hale açmış oluyorsunuz. Sonuçta kurum içi uygulamaların hepsi iç network’te çalışmayabilir. İş ihtiyaçları gereği bunları dışarı da açmanız gerebilir ve kimlik doğrulama sayfaları siber saldırganların en sevdiği atak yüzeylerinden biridir. Güvenlik zafiyetleri dışında son kullanıcıların bütün kurum içi uygulamalarda tek tek oturum açması yerine bir tanesinde oturum açtığında diğer bütün uygulamalarda da oturum açmaya ihtiyaç duymadan giriş yapılabilmesi (single-sign-on) ve bunu yaparken kimlik doğrulamanın tek bir otoritede toplanması da aslında bütün kurumlarda standart olması gereken bir durum. Her bir kurumsal uygulamaya ne kadar güvenli olduğu belli olmayan kendi lokal kimlik doğrulama sistemleriyle oturum açtırmak, her bir kullanıcının birden çok kimliği olduğu için kişi kurumdan ayrıldığında kapatılmayan ERP, CRM, EBYS hesapları da ayrı bir güvenlik riski oluşturuyor. Her işte olduğu gibi kimlik doğrulamayı da ehline bırakmak lazım. Bu ADFS olur veya başka bir çözüm olur; fakat uygulamanın kendisi olmamalı.
“Sonuçta ADFS de bir yazılım, buna tamamen nasıl güvenebiliriz?” sorusu aklınıza gelebilir. ADFS kimlik doğrulama konusundaki güvenlik zafiyetlerini büyülü bir asa ile ortadan kaldırmıyor. Active Directory entegrasyonu dışında endüstri standardı haline gelmiş OpenID ve OAuth 2.0 gibi kimlik doğrulama standartlarını kullanarak işi kuralına uygun hale getiriyor. Bu standartların tek amacı kimlik doğrulama sürecini güvenli hale getirecek kuralları belirlemek; dolayısıyla sizi bir yazılım geliştiricinin kimlik doğrulama konusundaki bilgi dağarcığına bağlı olmak zorunda bırakmıyor. Bu standartlar Microsoft gibi ticari amaç güden firmalara da özel değil; topluluklar tarafından destekleniyor ve her geçen gün gelişiyorlar. Dolayısıyla “ADFS gibi kimlik doğrulama sağlayıcıları ne kadar güvenli?” sorusunun cevabı: Global kimlik doğrulama standartları ne kadar güvenliyse o kadar güvenli.
Anlattıklarımdan anlaşılabileceği üzere ADFS gibi kimlik doğrulama sistemleri, söz konusu bir yazılımı geliştirirken dizayna dahil edilmesi gereken bir unsur. Bakımı ve kurulumu sistem altyapı ekibinin sorumluluğunda olsa bile, kullanımı ve konfigürasyonu aslında tam bir yazılım geliştiricisinin işi. Kimlik doğrulama sağlayıcıları, özellikle de bulut teknolojileriyle iç içe olan veya ileride DevOps süreçlerine adapte olmaya çalışacak her yazılım geliştiricinin göz atması gereken konulardan bir tanesidir.
ADFS ve benzeri kimlik doğrulama sağlayıcılarından bu ön bilgileri verdikten sonra kuracağımız ADFS yapısı için gerekli bilgilere geçebiliriz.
Kurulumumuz Windows Server 2019 ile beraber gelen ADFS 4.0 sürümünü baz alacak ve Azure üzerindeki sanal makinelerde konumlandırılacak. ADFS, yüksek erişilebilirlik için en az iki front-end sunucu, iki adet back-end sunucu (veri tabanı) ve güvenliği arttırmak için opsiyonel olarak iki adet reverse proxy sunucusuna ihtiyaç duyuyor. Reverse Proxy olarak yine Windows Server ile beraber gelen Web Application Proxy (WAP) rolünü kullanacağız. ADFS’in Active Directory domain’ine dahil edilmiş sunucular üzerine kurulu olması ve dolayısıyla iç network’te konumlandırılması gerekiyor. Fakat ADFS’i uygulamaları dışarıya açmak için de kullanabileceğimiz için ADFS sunucularını internete açmak yerine bir proxy sunucu arkasında konumlandırmak daha mantıklı ve güvenli bir çözüm. Dolayısıyla WAP’ın işi ADFS sunucularını korumak. WAP sunucuları DMZ segmentinde konumlandırılacak ve AD domainine dahil edilmeyecek. Eğer bir Web Application Firewall’ınız (WAF) varsa WAP sunucusu konumlandırmanıza gerek yok; zira ADFS’i WAF üzerinden dışarıya açabilirsiniz.
ADFS’i harici SQL Server’a ihtiyaç duymadan Windows Internal Database ile de kullanabilirsiniz fakat bu durumda iki sunucu bile kullansanız tam anlamıyla bir yüksek erişilebilirlik sağlamıyor, zira aynı anda sunuculardan sadece bir tanesi primary server olarak hizmet veriyor, diğeri primary sunucu ile belli aralıklarla kendini senkronize ederek stand-by server olarak bekliyor. Olur da primary sunucu hizmet veremez hale gelirse ikinci sunucu otomatik olarak aktif hale gelmiyor, sizin manüel olarak sunucuyu promote etmeniz gerekiyor. Dolayısıyla bu çözümün yüksek erişilebilir olması için veri tabanını dışarıya almamız gerekiyor. Neyse ki veri tabanı ihtiyaçları, sunucunun yapacağı iş gereği yüksek olmadığı için başka veri tabanlarını topladığınız genel amaçlı bir SQL sunucuda konumlandırabilirsiniz. ADFS’i SQL veri tabanıyla kurduğunuz vakit bir diğer avantaj, her iki sunucunun aktif-aktif yapıda çalışıp yük dengeleme de yapması; Windows Internal Database de böyle bir seçenek yok.
Kaynak ihtiyaçları konusunda ADFS ve WAP gayet tutumludur. Veri tabanı hariç, diğer her bir sunucuya 2 sanal çekirdek ve 4 GB RAM vermeniz, başlangıç için fazlasıyla yeterlidir. Veri tabanı sunucuları için 2 sanal çekirdek ve 8 GB RAM’den oluşan ve AlwaysOn Avalability Group ile çalışan 2 adet SQL sunucumuz olacak.
Network tarafında toplam 3 adet Azure Load Balancer’a ihtiyacımız olacak. Bu Load Balancer’ların ikisi internal tipte olup, ADFS ve SQL Server’ların önünde duracak; sonuncusu ise external tipte olup WAP sunucularının önünde duracak. Eğer yapıyı Azure’da değil de lokal olarak kursaydık bu ihtiyaçları yine Load Balancer cihazlarla sağlamamız “best practice” çözüm olacaktır. İşletim sistemi olarak bütün noktalarda Windows Server 2019, veri tabanı motoru olarak ise SQL Server 2017 kullanacağız.
Üç bölümden oluşacak makalemizin ilk kısmı bu şekilde. İkinci bölümde network gereksinimleri ve veri tabanı sunucularının; üçüncü bölümde ise ADFS ve WAP sunucularının kurulumu ve olacak. Bir sonraki bölümde görüşmek üzere.
Kaynaklar:
https://www.techopedia.com/definition/26292/active-directory-federated-services-adfs
https://gunnarpeipman.com/aspnet/what-is-claims-based-authentication/