Keycloak’da Authentication, Identity, Identity Provider İle Birlikte Authentication Flow’ları Teorik Olarak İnceleyelim #5

Merhaba,

Modern kimlik ve erişim yönetimi (IAM) çözümlerinde kullanıcıyı doğrulamak artık tek başına yeterli değildir. Doğrulamanın hangi bağlamda, hangi adımlarla ve hangi koşullara bağlı olarak gerçekleştiği en az sonucun kendisi kadar kritik arz etmektedir. Keycloak’ın en güçlü bileşenlerinden biri olan Authentication Flow yapısı, tam da bu noktada devreye girerek kimlik doğrulama sürecini esnek, koşullu ve genişletilebilir bir mimariye dönüştürmektedir. Bizler bu içeriğimizde; Authentication Flow kavramının neyi ifade ettiğinden başlayarak Browser Flow ile Direct Grant Flow arasındaki temel farklara değinecek, bir flow’un yapı taşlarını oluşturan Execution‘ların nasıl çalıştığını değerlendirecek ve Conditional Flow mantığıyla dinamik doğrulama senaryolarının nasıl kurgulandığını inceleyeceğiz. Böylece nihai olarak Keycloak’ın sunduğu Service Provider Interface (SPI) mekanizması ile tamamen özel authentication flow’ların nasıl geliştirilebileceğini teoride derinlemesine ele almış ve sonraki içeriklerde deneyimleyeceğimiz pratik dokunuşlara bir zemin hazırlamış olacağız. O halde hazırsanız başlayalım…

Authentication Nedir?

Authentication, “bu kullanıcı gerçekten söylediği kişi mi?” sorusuna verilen cevaptır…

Yolda yürüyorsun… Polis durdurdu: Kimliğini ver dedi… Burada kimlik, bir doğrulama aracıyken, polisin yaptığı ise authentication’dır. Benzer mantıkla, bankamatiğe kartı soktun ve şifreyi girdin… Banka diyor ki: Bu kart ve bu şifre… evet bu sensin… Bu da bir authentication durumudur. Yazılım dünyasında da authentication aynı mantıkla seyretmektedir. Bilgisayar; senin yüzünü bilmez, sesini tanımaz. Haliyle bir API’yi kullanabilmen için senden bir doğrulama kanıtı ister. Bu kanıt; kullanıcı adı + şifre olabilir, telefona gelen kod olabilir, Google hesabın olabilir, parmak izi yahut herhangi bir sertifika olabilir… Evet, bunların her biri yazılım açısından birer authentication davranışlarıdır. Sadece hangi yöntemle doğrulamanın yapılacağı Authentication Flow ile belirlenir…

Yani bir yazılım açısından authentication, amaç olarak kullanıcı doğrulamak olsa da, süreç olarak; kullanıcının hangi yöntemle doğrulandığını, bu doğrulama sürecinde hangi adımların (şifre mi, OTP mi, SMS mi, captcha mı vs.) izlendiğini ve bu adımların hangi sırayla ve hangi şartlarla çalıştığını belirleyen bir akışa (flow) ya da bir başka deyişle davranışa sahip olan bir süreçtir.

Identity Nedir?

Identity, “bu herif kim?” sorusunun cevabıdır…

Identity, sistemin tanıdığı bir kullanıcının kim olduğunu ifade eder. Ama dikkat ediniz!!! Henüz doğrulanmış olmayı değil, tanımlı olmayı ifade etmektedir. Bir identity’nin gerçekten o kullanıcı olup olmamasının doğrulanma süreci ise authentication’dır.

Davranışsal olarak authentication, identity’den önce değil mi?
Davranışsal olarak evet, authentication identity’den önce gibi görünür, ancak kavramsal olarak identity daha önceliklidir!

Burada akışa bakmakta fayda vardır… Şöyle ki;

1. Kullanıcı gelir
2. Kullanıcı adı ve şifreyi gönderir
3. Sistem doğrular
4. Sonra ‘bu X kişisiymiş’ der

Bu akış insana önce authentication oldu, sonra identity bulundu hissiyatı verecektir. Ama bu sadece algısaldır. Halbuki identity zaten vardır! Çünkü authentication bir identity oluşturmamakta, icat etmemektedir. Sadece verilen credential bilgileri doğrultusunda mevcut bir identity ile eşleştirme sağlamaktadır.

Yani batıni boyutta gerçek = Credential → Identity lookup → Doğrulama → Kabul mantığında seyretmektedir.

Authentication, identity’nin varlığını varsayarak çalışır.

Bunu daha da netleştirebilmek için şöyle güzel bir örnek verebiliriz :

• Kullanıcı username ve password’ü girer
• Keycloak şunu yapar:
  • “Bu username’e karşılık gelen identity var mı?” diye sorar
  • Varsa şifreyi doğrular

Haliyle esas buyken bizler süreci dışarıdan sanki; kullanıcının kendini kanıtlama çalışması (authentication) neticesinde, sistemin sonucu identity olarak açıklaması olarak algılıyoruz. Yani yanılıyoruz 🙂

Peki Identity Provider (IdP) nedir?

Kullanıcıyı tanıtan yerin ta kendisidir. Yani ilgili kullanıcının kimliğini kim onaylıyorsa o identity provider’dır. Örnek olarak; Google hesabıyla bir sisteme giriyorsanız eğer o noktada Google identity provider’ı kullanıyorsunuz demektir, yok eğer şirket içi Active Directory ile ya da LDAP sayesinde girişte bulunuyorsanız identity provider’ınız bunlardır demektir.

Ee peki başka bir Keycloak sistemi üzerinden doğrulama yapılabilir mi?

Evet, bir sistem Keycloak kullansın ya da kullanmasın başka bir Keycloak kullanan sistem üzerinden girişe izin verebilir. İşte bu taktirde o sistemde de identity provider Keycloak olacaktır.

Yani identity provider;

• Kullanıcı kimliğini doğrular.
• Doğrulama başarılıysa bu kimliği temsil eden bir çıktı üretir. Bu çıktı genelde JWT, SAML Assertion gibi token ya da doğrulanmış identity claim’leri olabilir.
• Bu çıktıyı başka sistemlerin güvenle kullanmasını sağlar.

Identity Provider (IdP), authentication sorumluluğunu üstlenen ve bu işlem neticesinde bir identity üretip bunu başkalarına kanıtlanabilir bir şekilde sunan sistemdir.

Keycloak, Azure Active Directory (Azure AD / Entra ID), Google, Facebook, GitHub vs. yaygın olarak kullanılan identity provider örnekleridir…

Identity’de ‘Federation’ ve ‘Broker’ Ne Demektir?

Identity dünyasında tek bir kimlik kaynağına bağlı kalmamak gibi bir problem vardır. Federation ve Broker, bu problemi iki farklı mimari yaklaşımıyla çözmektedir.

• Federation (Kimlik Federasyonu) Nedir?
  

  Federation, farklı organizasyonlar / domain’ler arasında kimlik paylaşımını mümkün kılmak içindir…

  Keycloak’un kullanıcıyı kendi veritabanında tutmadığı doğrudan harici bir user store üzerinden doğruladığı senaryolarda kullanılır. Bu mimaride Keycloak, kimlik doğrulama sorumluluğunu dış sisteme devreder ve kullanıcı bilgileri harici sistemde authoritative kabul edilir.

  LDAP, Active Directory ve Kerberos tipik federation kaynaklarıdır.

  Akış mantığı

  1. Kullanıcı kullanıcı adı ve şifre gönderir
  2. Keycloak bu bilgileri LDAP veya Active Directory’e iletir
  3. Doğrulama gerçekleştirilir
  4. Keycloak bir token üretir

  Dikkat ederseniz burada, kimlik doğrulama yetkisi Keycloak’ta değil, dış sistemdedir, ancak token yine Keycloak tarafından üretilmektedir.

  Kritik nokta şudur ki; bu senaryoda Keycloak bir identity provider olarak değil de identity gateway / proxy gibi davranış sergilemektedir.

• Broker (Identity Brokering) Nedir?
  Keycloak’un kendi kullanıcı havuzuna sahip olduğu ama kullanıcıyı başka bir IdP’ye yönlendirerek doğrulattığı senaryolar için uygun olan bir mimaridir.

  Google, Azure AD, GitHub ya da başka bir Keycloak vs. bizler için güncel birer broker kaynaklarıdır…

  Akış mantığı

  1. Kullanıcı login ister
  2. Keycloak:
     • “Bu kullanıcıyı ben doğrulamayacağım” der
     • Ve harici IdP’ye yönlendirir
  3. Harici IdP:
     • Kullanıcıyı doğrular
     • Bir assertion / id_token döner
  4. Keycloak:
     • Bu sonucu kabul eder
     • Kendi realm’inde kullanıcıyı oluşturur ve eşler
     • Kendi token’ını üretir

  Evet, bu yaklaşımda da dikkat ederseniz kimlik başka IdP’de doğrulanırken; token oluşturma ise Keycloak tarafından gerçekleştirilmektedir.

Authentication Flow Nedir?

Authentication Flow, sisteme girmek isteyen bir kullanıcının gerçekten kim olduğunu kanıtlaması için izlenen adımlar zinciridir…

Authentication Flow, bir kullanıcı kimliğinin doğrulanması için hangi adımların, hangi sırayla ve hangi koşularda çalışacağını tanımlayan akıştır.

Authentication Flow neyi çözer?
Authentication Flow esasında şu soruların cevabını belirler;

• Kimlik doğrulama nasıl başlayacak?
• Hangi kontroller yapılacak?
• Hangi sırayla yapılacak?
• Bir adım başarısız olursa ne olacak?
• Koşula bağlı (conditional) adımlar olacak mı?

Yani anlayacağınız, kullanıcı authentication olurken sistem tarafından “şifre mi sorayım, OTP mi isteyeyim, cihaz güvenilir mi değil mi ona mı bakayım, captcha mı koyayım, ne halt edeyim?” tarzı durumların hepsi flow’un konusudur.

Teoride olaya baktığımızda authentication flow, bir state machine gibi davranış sergileme durumudur. Çünkü, akış sürecinin her bir adımı bir execution’dır (yani doğrulama kuralıdır) ve her execution; required, alternative, optional ve conditional olabilmektedir. Bunları yazımızın sonraki satırlarında masaya yatıracak olsak da şimdilik buradan anlamamız gereken, her adımın zorunluluğu ve davranışı önceden belirli olmasıdır.

Keycloak’ta Flow Türleri Nelerdir?

Flow Türü	Açıklama	Kullanıldığı Yerler	Günlük Hayattan Örnekler	Keycloak Karşılığı
Browser Flow	Tarayıcı (browser) tabanlı etkileşimli giriş akışları.	▪️Web uygulamaları login ekranları ▪️SSO (Single Sign-On) senaryoları ▪️MFA / OTP / Captcha gibi etkileşimli adımlar ▪️Identity Provider (Google, Azure AD, e-Devlet) ile login durumları	▪️İnteraktif Vergi Dairesi’ne e-Devlet üzerinden login olma. ▪️MHRS’ye e-Devlet üzerinden giriş yapma.	browser
Direct Grant Flow	Kullanıcı adı ve şifre ile doğrudan token alma. Sessiz çalışır. Arka planda token üretir ve tarayıcıya gerek yoktur! ⚠️Güvenlik riski daha yüksektir! Modern OAuth dünyasında pek önerilmemektedir!	▪️Redirect olmadan token alınacağı durumlar ▪️API, backend ve script tabanlı login durumları ▪️Public / Confidential client’ları ▪️MFA ve OTP olmaksızın doğrulama durumları	Mobil uygulamasının kullanıcı adı ve şifreyi doğrudan bankanın sistemine gönderip arka planda doğrulaması ve token alması.	direct grant
Client Auth Flow	Client’ın kendisini doğrulaması. Kullanıcı yoktur. Dolayısıyla doğrulanan kullanıcı değil uygulamanın ta kendisidir.	▪️Client’ın kendini doğrulamak zorunda olduğu durumlar ▪️Machine-to-Machine (M2M) senaryoları ▪️Confidential client’lar ▪️Refresh token	Bir bankanın muhasebe sisteminin, çalışan olmaksızın, kendi kurum kimliğiyle Gelir İdaresi sistemine bağlanıp otomatik bildirim göndermesi.	clients
Registration Flow	Kullanıcı kayıt süreci adımları. Yeni kullanıcı kayıt olurken hangi adımlar izlenecek onu belirler.	▪️Registration endpoint ▪️E-posta doğrulaması gereken kayıt işlemleri ▪️Kayıt sırasında ek kontrol veya kural olduğu durumlar ▪️IdP sonraki ek kayıt gerektiği durumlar	Bir belediyenin e-hizmet portalından ilk kez hesap oluşturup e-posta doğrulaması yaparak sisteme kayıt olunması.	registration
Reset Credentials Flow	Şifre veya kimlik bilgisi sıfırlama.	Yeni şifre belirleme süreçleri	Şifremi unuttum akışı.	reset credentials
First Broker Login Flow	Harici IdP sonrası ilk giriş süreci. Google, Azure AD, e-Devlet vs. gibi harici bir Identity Provider’dan ilk kez gelen kullanıcı için çalışır. 📌Federation / Broker senaryolarının kalbidir.	▪️Harici Identity Provider’dan dönüş yapıldığı durumlar ▪️IdP’den gelen bilgiler yeterli olmadığı durumlar ▪️IdP login sonrası politika uygulanacağı durumlar	▪️Bir vatandaşın bir belediyenin e-hizmet portalına ilk kez e-Devlet ile giriş yapması ve sistemin bu kişiyi o anda kendi kayıtlarına eklemesi. ▪️Bir öğrencinin üniversite sistemine ilk kez e-Devlet/YÖK doğrulamasıyla girip otomatik öğrenci hesabını açması.	first broker login
Conditional Flow’lar	Koşula bağlı authentication akışları. Eğer şu şart sağlanıyorsa, şu adımı çalıştır mantığında akış sağlar.	▪️Authentication Flow içinde koşul değerlendirmesi gereken her yer ▪️Kullanıcıya göre farklı adımlar çalıştırılacağı durumlar ▪️Ortama / bağlama göre karar verilen senaryoları ▪️Risk bazlı doğrulama senaryolarında ▪️Aynı flow içinde farklı login yolları sunulacaksa	Role veya IP’ye göre ek doğrulama.

Execution Nedir?

Authentication Flow, içerisinde adımlardan oluşan bir akıştan ibarettir ve her bir adım önceden; çalışıp çalışmayacağı, başarısız olursa ne olacağı, alternatif olup olmadığı vs. gibi durumlara karşın hali hazırda tanımlanmış davranışa sahiptir. İşte bizler bu doğrulama kurallarının olduğu adımların her birine Execution diyoruz.

Execution, authentication sırasında çalışan tek bir doğrulama kuralıdır. Flow ise execution’ların sıralı çalıştığı bir yapıdır.

Execution Type’lar

Execution’lar sergiledikleri davranışların türüne göre required, alternative, optional ve conditional olmak üzere dörde ayrılmaktadırlar. Şimdi gelin bu execution tiplerini tek tek masaya yatıralım;

• REQUIRED
  Required olarak tanımlanmış olan adım, adı üzerinde, mutlaka çalışmalı ve başarılı olmalı. Genellikle username ve password doğrulama süreçlerinde veyahut zorunlu OTP kullanılan senaryolarda tercih edilir.
• ALTERNATIVE
  Aynı seviyede birden fazla execution’ın olduğu senaryoyu ifade etmektedir. Aralarında ‘veya’ mantığı söz konusudur. Adı üzerinde 🙂 alternatif… Haliyle bir tanesinin başarılı olması flow’un devam etmesi için yeterlidir.
• OPTIONAL
  Bu execution başarılı olsa da olmasa da çalışacak ancak flow’u engellemeyecektir. Yani opsiyoneldir. Buna en güzel örneği ‘Remember-me’yi verebiliriz 😉 Olsa da akış devam edecek, olmasa da…
• CONDITIONAL
  Bu execution ise şarta göre işlevsellik gösterecektir. Yani bir doğrulamadan ziyade, karar mekanizması gibi davranış sergilemektedir. Misal olarak; kullanıcının OTP’si aktif mi?, client public mi? IP trusted mı? vs. gibi şartlar örnek gösterilebilir.

Şimdi bu execution’ları akıllarda daha da netleştirebilmek için Keycloak çerçevesinde Browser Authentication Flow‘u adım adım (execution execution) teoride parçalayalım ve böylece süreçte yapıyı gözlemlemeye çalışalım.

Browser Authentication Flow’u Execution’larına Bölelim

Browser flow, yukarıdaki satırlarda incelediğimiz üzere tarayıcıdan gelen login’ler için çalışan bir akıştır. Şimdi bu flow’un üst seviye şemasını çıkarırsak eğer;

Görüldüğü üzere Browser flow, yukarıdaki execution’lar ile seyretmektedir. Şimdi gelin tek tek, hangi execution ne yapıyor, neden var, başarısız olursa ne olur incelemeye başlayalım…

• 1️⃣Cookie
  Type : ALTERNATIVE

  Ne yapar?

  • Tarayıcıda önceden geçerli bir Keycloak oturumu (SSO cookie) var mı kontrol eder.
  • Varsa hiç kullanıcı şifre sormadan login başarılı sayılır.

  Neden ALTERNATIVE’dir?
  Çünkü cookie varsa eğer iş bitmekte, yoksa diğer alternatiflere geçilmektedir.

  Bu adım başarısız olsa bile login bitmeyecektir!

• 2️⃣ Kerberos (SPNEGO)
  Type : ALTERNATIVE

  Ne yapar?
  Kurumsal ortamda (AD / Kerberos) tarayıcı domain’e login mi diye bakar.

  Çoğu sistemde disable edilmektedir.

• 3️⃣ Username Password Form
  İşin klasik login kısmı burada başlamaktadır! Esasında bu bir execution değildir! SUB-FLOW’dur! Yani altında aşağıdaki execution’lar mevcuttur;
  Username Password Form
  ├─ Username Password
  └─ Conditional OTP
  └─ OTP Form
  • 3️⃣.1️⃣ Username Password
    Type : REQUIRED

    Ne yapar?

    • Kullanıcı var mı?
    • Şifre doğru mu?
    • Hesap kilitli mi?
    • Credential geçerli mi?

    kontrol eder.

  • 3️⃣.2️⃣ Conditional OTP
    Type : CONDITIONAL

    Bu adım doğrudan doğrulama yapmamakta sadece karar vermektedir.

    Şart şudur: Kullanıcının OTP’si aktif mi? Eğer bu şart false ise kullanıcının OTP’si pasif olduğu anlaşılacak ve dolayısıyla herhangi bir alt adım devreye girmeyecektir. Yok eğer şart true ise işte o taktirde OTP Form execution’ı devreye girecektir.

    • 3️⃣.2️⃣.1️⃣ OTP Form
      Type : REQUIRED

      Ne yapar?

      • Kullanıcıdan OTP ister.
      • Yanlışsa login biter!
      • Doğruysa devam eder.

Peki bu flow ne zaman authentication’ı bitirecek?
Aslında aşikar… Akışta; Cookie veya Kerberos veya Username Password (+ gerekirse OTP) başarılı olduğu taktirde authentication başarılı kabul edilecek, token üretilecek ve session oluşturulacaktır.

Tüm akışı tek parça halinde seyredebilmek için buyurun;

Evet… Bu örnek sayesinde execution’ların daha anlaşılır olduğunu düşünüyorum.

Nihai olarak;

Bu içeriğimizde, Keycloak’daki Authentication Flow yapısını teorik olarak tam teferruatlı incelemiş bulunuyoruz. Bundan sonraki içeriklerimizde bu makalede değerlendirdiğimiz her bir akışa ayrı ayrı odaklanacak ve Asp.NET Core üzerinden mümkün mertebe pratiksel olarak örneklendirmeye çalışıyor olacağız. O halde heyecanla sonraki yazılarda görüşmek üzere diyelim ve içeriğimizi burada nihayetlendirelim…

İlgilenenlerin faydalanması dileğiyle…
İyi çalışmalar…