Windows Server

Deep Dive: Active Directory Federation Services (ADFS) Bölüm 1

Kimlik yönetimi ve erişim denetimi, modern bilgi teknolojilerinin temel taşlarından biridir. Birden fazla uygulamanın, hizmetin ya da organizasyonun bulunduğu yapılarda, kullanıcıların güvenli ve merkezi şekilde doğrulanması kritik öneme sahiptir. İşte tam bu noktada Active Directory Federation Services (ADFS) devreye girer.

ADFS, Microsoft’un geliştirdiği, claims (iddia) tabanlı bir kimlik federasyon çözümüdür. Kurum içi veya dışı uygulamalara kullanıcıların tek bir kimlik ile güvenli biçimde erişmesini sağlar. Hem şirket içi uygulamalarla hem de bulut tabanlı hizmetlerle entegre çalışabilen bu sistem, özellikle Single Sign-On (SSO) ve federasyon güveni senaryolarında etkin bir rol oynar.

ADFS Ne Yapar?

ADFS’in temel işlevi, bir kullanıcıyı yalnızca bir kez doğrulayıp, bu kullanıcının kimliğini başka sistemlerde de kabul ettirmektir. Böylece:

  • Aynı oturumla birden çok uygulamaya erişim sağlanır.
  • Uygulama başına farklı kullanıcı adı-parola girmek gerekmez.
  • Kimlik bilgilerinin güvenli bir şekilde iletimi sağlanır.
  • Uygulamalar, kullanıcının sadece ihtiyaç duyduğu özellikleri (örn. e-posta, departman bilgisi) alır.

Temel Bileşenler

ADFS mimarisi aşağıdaki ana bileşenlerden oluşur:

BileşenAçıklama
Federation ServerKimlik doğrulama isteğini alır, kullanıcıyı doğrular ve token üretir.
Claims Provider TrustKimlik doğrulamanın geldiği kaynak (örn. Active Directory).
Relying Party TrustToken’ı kabul eden uygulama ya da servis.
Web Application Proxy (WAP)Kurum dışından gelen istekleri ADFS sunucusuna yönlendirir.
ADFS Configuration DatabaseTüm konfigürasyon ve ilişki verileri burada tutulur.

ADFS Örnek 1 : Active Directory Federation Services’ın ne olduğunu anlamak için birkaç örneği ele alalım, o zaman konu daha net anlaşılacaktır.

Varsayalım ki 2 tane organizasyonumuz var, organization1 ve organization2. Organization1, organization2’de barındırılan bir uygulamaya erişmek istiyor. Her iki kuruluşun da kaynaklarını birbirleriyle paylaşabilmeleri için bir güven oluşturmaları gerekir. Ancak bu bir güvenlik riskine yol açabilir. Çünkü her iki kuruluş da tüm kaynaklarına erişebilecektir. Dahası, bir güven oluşturmak için her iki kuruluşun da belirli port numaralarını açması gerekir. Örneğin, 389, 443, 89 ve 636.

İşte ADFS tam bu noktada devreye giriyor. ADFS’de belirli bir uygulama ile bir federasyon güveni oluştururuz. Ve bu şekilde bir organizasyondaki kullanıcılar yalnızca yetkilendirildikleri uygulamaya erişebilecektir.

ADFS Örneği 2 : ADFS’ye neden ihtiyaç duyduğumuzu anlamak için bir örnek daha ele alalım.

Bir Active Directory hesabı belirli uygulamalara erişmek istediğinde, kullanıcı kimliği doğrulandıktan sonra Active Directory bir Kerberos bileti oluşturur.

Bu kullanıcının erişmeye çalıştığı uygulamalara gönderilecektir. Burada dikkat edilmesi gereken bir şey, Kerberos biletinin her zaman aynı öznitelik kümesini içereceğidir. Bir Kerberos bileti Kullanıcı Hesabı SID’si , Grup SID’si ve Kimlik Doğrulama Zaman Damgası içerir .

Yukarıdaki örnekte, bir kullanıcı 2 farklı uygulamaya erişmeye çalışıyor. Bu kullanıcı doğrulandığında, Active Directory 2 Kerberos bileti oluşturacak ve bu biletleri her iki uygulamaya gönderecek. Ve her iki Kerberos biletinin de aynı attribut kümesi olacak. Yani, kullanıcının hangi tür uygulamalara erişmeye çalıştığı önemli değil, aynı Kerberos token uygulamalara gönderilecek. Ancak uygulamalar kimlik doğrulama amacıyla farklı bir attribut kümesine ihtiyaç duyduğunda işler değişecektir. Diyelim ki application1’in kimlik doğrulama için Department niteliğine ve application2’nin EmailAddress niteliğine ihtiyacı var. Kimlik doğrulama için Group SID veya Account SID niteliklerine ihtiyaçları yok. Bu yüzden ADFS devreye giriyor.

ADFS Nasıl Çalışır?

Active Directory’deki her kullanıcının E-posta Adresi, Departman, UserprincipalName veya ContactNumber gibi belirli attribut vardır. Tüm bu attribut ADFS’de Claims olarak adlandırılır . ADFS’de, bir kullanıcı belirli uygulamalara erişmeye çalıştığında, bu uygulamalar ADFS sunucusuyla iletişim kuracaktır.

Daha sonra ADFS sunucusu kullanıcının kimliğini doğrulamak için Active Directory ile iletişime geçecektir.

Kullanıcı doğrulandıktan sonra ADFS uygulamalara bir token gönderecektir ve ADFS token i uygulama gereksinimlerine göre özelleştirme yeteneğine sahiptir. Eğer Uyuglama-1 kullanıcının Departman attribut göre bir token e ihtiyaç duyarsa, ADFS sunucusu Departman attribut göre bir token oluşturacak ve bunu uygulamaya gönderecektir. Aynı şekilde, başka bir uygulamanın gereksinimi kullanıcının EmailAddress attribut göre kimlik doğrulaması ise ADFS kullanıcının e-posta adresini içeren başka bir token oluşturacak ve bunu uygulamaya gönderecektir.

Claims Nedir?

ADFS’in temelini claims-based authentication oluşturur. Claims, kullanıcıya ait tanımlayıcı bilgileri temsil eder. Örnek claims’ler:

  • E-posta adresi
  • Departman
  • Kullanıcı adı (UserPrincipalName)
  • Telefon numarası
  • Rol veya grup bilgisi

Her uygulama, yalnızca ihtiyaç duyduğu claim’leri ister. ADFS, uygulamaya özel token’lar oluşturduğu için minimum veri paylaşımı ve maksimum kontrol elde edilir.

ADFS ile Active Directory Arasındaki Farklar

Karşılaştırma KriteriActive DirectoryADFS
Doğrulama YöntemiKerberos / NTLMClaims tabanlı Token
Uygulama ErişimiYerel ağla sınırlıForest, Domain veya Cloud arası erişim
ÖzelleştirmeSınırlıUygulama bazlı claim özelleştirmesi
Federasyon YeteneğiYokEvet
Doğrudan AD ile BağlantıEvetHayır (ADFS aracılığıyla dolaylı)

SSO (Single Sign-On) ile Entegrasyon

ADFS, kurum içi veya bulut uygulamalarıyla tek oturum açma deneyimi sunar. Kullanıcı, bir kez kimlik doğruladıktan sonra;

  • Microsoft 365 (Office 365),
  • Salesforce,
  • SAP,
  • SharePoint,
  • Kurumsal portal uygulamaları

gibi birçok uygulamaya tekrar parola girmeden erişebilir.

Bu yapı, kullanıcı deneyimini iyileştirirken aynı zamanda parola tabanlı güvenlik açıklarını da azaltır.

Federasyon Senaryoları

ADFS, özellikle aşağıdaki senaryolarda tercih edilir:

  • İki farklı domain arasında kimlik paylaşımı yapılmak isteniyorsa
  • Kurumsal ağ dışındaki uygulamalara güvenli erişim gerekiyorsa
  • Kimlik bilgileri, grup üyeliği yerine başka özniteliklere göre filtrelenmek isteniyorsa (örneğin departmana göre)
  • SAML 2.0, WS-Federation veya OAuth protokolleriyle entegre olunmak isteniyorsa

İlk bölümü burada bitiriyorum bir sonraki makalede görüşmek dileğiyle.

İlgili Makaleler

Bir yanıt yazın

Başa dön tuşu