Basic Kimlik Doğrulama

ipucu

Bu doküman spesifik bir politikanın detaylı kullanımını anlatır. Eğer Apinizer politika yapısını ilk kez kullanıyorsanız veya politikaların genel çalışma prensiplerini öğrenmek istiyorsanız, öncelikle Politika Nedir? sayfasını okumanızı öneririz.

Genel Bakış

HTTP Basic Authentication standardını kullanarak API isteklerini güvenli bir şekilde doğrulamak. İsteklerde gönderilen kullanıcı adı ve şifre bilgilerini base64 ile decode ederek kimlik kontrolü yapmak.

Amacı Nedir?

• HTTP Basic Authentication standardını kullanarak API isteklerini güvenli bir şekilde doğrulamak. İsteklerde gönderilen kullanıcı adı ve şifre bilgilerini base64 ile decode ederek kimlik kontrolü yapmak.
• Secret Manager, LDAP, veritabanı veya harici API entegrasyonları ile merkezi kimlik doğrulama altyapısına bağlanmak. Kullanıcı bilgilerini güvenli şekilde Identity/Role Group servisleri üzerinden doğrulamak.
• Kullanıcının rollerini ve yetkilerini kontrol ederek endpoint bazında veya method bazında erişim kontrolü sağlamak. Authorization yapılandırması ile sadece yetkili kullanıcıların belirli API'lere erişmesini garanti etmek.
• Kimlik doğrulaması yapılan kullanıcı bilgilerini (username, user ID vb.) backend servislerine özel header ile iletmek. Backend'in kullanıcı bağlamında işlem yapmasını sağlamak.
• IP adresi kontrolü, clear auth ve error message özelleştirme gibi gelişmiş güvenlik katmanları ekleyerek çok katmanlı güvenlik sağlamak.

Çalışma Prensibi

1. İstek Gelişi: API Gateway'e gelen her HTTP/HTTPS isteği için, istemin Authorization header'ı kontrol edilir ve Basic prefix ile base64 encoded credentials (kullanıcı adı:şifre) aranır.
2. Politika Kontrolü: Base64 Authentication politikası aktif ise, sistem aşağıdaki sırayla kontrol yapar:
   • Condition (koşul) tanımlı mı? Varsa koşul sağlanıyor mu?
   • Politika aktif mi (active=true)?
   • Variable kullanılıyor mu yoksa Apinizer default mı?
3. Kimlik Doğrulama Kontrolü: Authorization header'ı decode edilir ve username/password çıkarılır. Identity Role Group servisi (Secret Manager, LDAP, Database veya API) ile kimlik bilgileri doğrulanır. Eğer checkClientIpAddress aktifse, istemci IP adresi de kontrol edilir.
4. Karar Verme:
   • Doğrulama Başarılı: Kullanıcı doğrulanırsa, opsiyonel olarak authorization (rol kontrolü) yapılır. addUserToHeader aktifse kullanıcı bilgisi backend'e özel header ile iletilir. clearAuth aktifse, Authorization header backend'e gönderilmez.
   • Doğrulama Başarısız: Kullanıcı kimlik bilgileri geçersizse veya yetkisi yoksa HTTP 401/403 hatası döndürülür.
5. Hata İşleme: Politika kuralına uymayan istekler için özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.

Şifre : karakteri içerebilir

Base64 çözüldükten sonra kullanıcı adını şifreden yalnızca ilk : karakteri ayırır; sonrasındaki tüm karakterler şifrenin parçası sayılır (RFC 7617). Örneğin kullanici:12:34 bilgisi kullanici kullanıcı adı ve 12:34 şifresi olarak çözümlenir.

Şifrede : bulunan kullanıcıların isteği daha önce "kimlik bilgisi eksik" hatasıyla reddediliyordu. Kullanıcı adında : kullanılamaz — standardın gereğidir.

Özellikler ve Yetenekler

Temel Özellikler

• HTTP Basic Authentication Desteği: RFC 7617 standardına uygun base64 encoded username:password formatında kimlik doğrulama. Authorization header'ından otomatik decode ve credential extraction.
• Identity/Role Group Entegrasyonu: Secret Manager, LDAP, Database veya harici API servisleri ile merkezi kimlik yönetimi. Kullanıcı bilgilerini güvenli şekilde doğrulama ve rol bilgilerini alma.
• Username Variable Desteği: Doğrulanan kullanıcı adını Apinizer değişkenlerine yazma. Policy chain boyunca kullanıcı bilgisine erişim ve backend'e aktarım imkanı.
• Aktif/Pasif Durum Kontrolü: Politikanın aktif veya pasif durumunu kolayca değiştirme (active/passive toggle). Pasif durumda politika uygulanmaz ancak yapılandırması saklanır.
• Koşul Bazlı Uygulama: Query Builder ile karmaşık koşullar oluşturarak politikanın ne zaman uygulanacağını belirleme (örn: sadece belirli endpoint'lere veya header değerlerine göre).

İleri Düzey Özellikler

• Authorization (Yetkilendirme) Yapılandırması: Method bazlı erişim kontrolü (GET, POST, PUT, DELETE vb.). Rol bazlı yetkilendirme ve credential role listesi tanımlama. Rolleri backend'e header olarak iletme (addRolesToHeader).
• IP Adresi Kontrolü: Secret Manager modunda kullanıcı kimlik bilgilerine ek olarak istemci IP adresi doğrulaması. Çift faktörlü güvenlik katmanı.
• Clear Auth ve Header Manipülasyonu: Authorization header'ını backend'e göndermeme (clearAuth). Doğrulanmış kullanıcı bilgisini özel header ile backend'e iletme (addUserToHeader). Header adını özelleştirme (userHeaderName).
• Export/Import Özelliği: Politika yapılandırmasını ZIP dosyası olarak export etme. Farklı ortamlara (Development, Test, Production) import etme. Versiyon kontrolü ve yedekleme imkanı.
• Policy Group ve Proxy Group Desteği: Birden fazla politikayı Policy Group içinde yönetme. Proxy Group'lara toplu politika atama. Merkezi güncelleme ve deploy işlemleri.
• Deploy ve Versiyonlama: Politika değişikliklerini canlı ortama deploy etme. Hangi API Proxy'lerde kullanıldığını görme (Policy Usage). Proxy Group ve Policy Group kullanım raporları.

Kullanım Senaryoları

Senaryo	Durum	Çözüm (Politika Uygulaması)	Beklenen Davranış / Sonuç
Kurumsal Kimlik Doğrulama	Şirket içi API'ler için LDAP tabanlı kimlik doğrulama gerekli. Tüm kullanıcılar Active Directory'de tanımlı.	Identity Role Group olarak LDAP servisi seçilir. Username variable tanımlanır. Politika tüm API'lere atanır.	Her istekte Authorization header'ı kontrol edilir. LDAP'tan kullanıcı doğrulanır. Başarılı ise backend'e istek iletilir.
Mikroservis Kimlik Aktarımı	Backend mikroservisler kullanıcı bilgisine ihtiyaç duyuyor ancak şifre bilgisi gönderilmemeli.	addUserToHeader=true ve clearAuth=true ayarlanır. Header adı X-Authenticated-User olarak belirlenir.	Gateway kimlik doğrulaması yapar, Authorization header'ı backend'e göndermez. Sadece kullanıcı adını X-Authenticated-User header'ı ile iletir.
Rol Bazlı Erişim Kontrolü	Admin kullanıcıları tüm method'lara erişebilsin, normal kullanıcılar sadece GET ve POST yapabilsin.	Authorization yapılandırması aktif edilir. Method Access tanımlanır: Admin rolü: ALL, User rolü: GET, POST.	Her istekte kullanıcının rolü kontrol edilir. Admin DELETE yapabilir ancak User rolü 403 hatası alır.
IP Kısıtlamalı Doğrulama	Secret Manager'da tanımlı kullanıcılar sadece belirli IP'lerden erişebilmeli.	Secret Manager Identity seçilir. checkClientIpAddress=true ayarlanır. Secret Manager'da credential tanımlarken IP listesi girilir.	İstek geldiğinde hem kullanıcı adı/şifre hem de IP adresi kontrol edilir. IP uyuşmazsa 401 hatası döner.
Test ve Production Ayrımı	Test ortamında kimlik doğrulama yapılmasın, production'da yapılsın.	Condition tanımlanır: Header = X-Environment, Equals, production. Politika aktif olarak atanır.	Test ortamında X-Environment header'ı olmadığı için politika atlanır. Production'da header varsa kimlik doğrulama yapılır.
External API Kimlik Doğrulama	Kullanıcı bilgileri harici bir REST API'de tutuluyor.	Identity Role Group olarak API servisi seçilir. API endpoint ve parametreleri yapılandırılır.	Her istekte API Gateway harici API'ye kullanıcı bilgilerini gönderir. API'den dönen response'a göre doğrulama yapılır.
Çoklu Kimlik Kaynağı	Bazı kullanıcılar LDAP'ta, bazıları Database'de tanımlı.	İki ayrı Base64 Authentication politikası oluşturulur. Condition ile ayrılır: LDAP kullanıcıları için Header = X-Auth-Source, Equals, LDAP.	İsteğe göre uygun kimlik kaynağı seçilir. LDAP veya Database'den doğrulama yapılır.

Politika Parametrelerini Yapılandırma

Bu adımda, kullanıcı yeni bir politika oluşturabilir ya da mevcut politika parametrelerini yapılandırarak erişim kurallarını belirleyebilir. Tanımlanan parametreler, politikanın çalışma şeklini (örneğin hangi IP'lerin izinli olacağı, coğrafi kısıtlamalar, koşullu aktivasyonlar vb.) doğrudan etkiler. Bu sayede politika hem kuruma özel gereksinimlere göre özelleştirilebilir hem de merkezi olarak yönetilebilir.

Yeni Base64 Authentication Politikası Oluşturma

Yapılandırma Adımları

Adım	Açıklama / İşlem
Adım 1: Oluşturma Sayfasına Gitme	- Sol menüden Development → Global Settings → Global Policies → Base64 Authentication bölümüne gidin. - Sağ üstteki [+ Create] butonuna tıklayın.
Adım 2: Temel Bilgileri Girme	Policy Status (Politika Durumu): Aktif/Pasif durumu gösterir. Yeni politikalar varsayılan olarak aktiftir. Name (İsim) Zorunlu: Örnek: Production_Basic_Auth - Benzersiz isim girin, boşlukla başlamaz. - Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir. Kırmızı çarpı: mevcut isim. Description (Açıklama): Örnek: "Production ortamı için LDAP tabanlı kimlik doğrulama" - Maks. 1000 karakter. - Politikanın amacını açıklayın.
Adım 3: Variable Kullanımı	- Sayfanın üst kısmındaki işlem butonları alanında, [<> Variable] butonunu kullanarak dinamik değer seçebilirsiniz. - Context/global variable ifadeleri sayesinde politika parametrelerini sabit değer yerine değişken tabanlı yönetebilirsiniz. - Bu kullanım, değişen değerlerde manuel güncelleme ihtiyacını azaltır ve operasyonel kolaylık sağlar. - Detaylı bilgi için Dinamik Değişkenler sayfasını inceleyebilirsiniz.
Adım 4: Identity Role Group Seçimi (Zorunlu)	- Identity Role Group alanında [Click to Select] butonuna tıklayın. - Açılan dialogda kimlik kaynağını seçin: Secret Manager: Apinizer'da tanımlı kullanıcı/şifre/IP listeleri LDAP: Active Directory veya OpenLDAP entegrasyonu Database: Kullanıcı bilgilerini veritabanından sorgulama API: Harici REST API ile kimlik doğrulama - Seçim yaptıktan sonra [Select] butonuna tıklayın. - Yanlış seçim yaparsanız [X] butonu ile temizleyebilirsiniz.
Adım 5: Username Variable Tanımlama (Zorunlu)	- Variable for Authorization alanında değişken seçimi yapın. - İki seçenek mevcuttur: 1. Mevcut Variable Seçme: [Select Different] butonuna tıklayın. Variable listesinden username bilgisinin yazılacağı değişkeni seçin. 2. Variable Güncelleme: Seçili variable'ın [Update Variable] butonuna tıklayarak özelliklerini düzenleyebilirsiniz. - Doğrulanan kullanıcı adı bu variable'a yazılır. - Policy chain'de sonraki politikalar veya backend bu değişkeni kullanabilir.
Adım 5b: Gizli Anahtar Doğrulama Modu (İsteğe Bağlı)	Gizli Anahtar/Parola Değerini Kontrol Et: - Varsayılan olarak açıktır. Açıkken, standart Basic Authentication'da olduğu gibi kullanıcı adıyla birlikte bir gizli anahtar/parola değeri de sağlanmalı ve kontrol edilmelidir. - Kapatıldığında kimlik doğrulama yalnızca kullanıcı adı/API anahtarı değerine dayanır (yalnız-anahtar doğrulama) — ayrıca bir gizli değer kontrol edilmez. API Anahtarını Bearer Token Olarak Kullan (yalnızca Gizli Anahtar/Parola Değerini Kontrol Et kapalıyken görünür): - Açıkken, username variable üzerinden okunan değer ham bir Basic Authentication kimlik bilgisi olarak değerlendirilmez. Authorization header'ı Bearer şemasını taşımak zorundadır ve ardından gelen token API anahtarı olarak kullanılır. - Bearer şeması yoksa veya token boşsa, istek API anahtarının kendisi eksik olduğunda dönen aynı "kimlik bilgisi eksik" hatasıyla reddedilir. - Gizli Anahtar/Parola Değerini Kontrol Et tekrar açılırsa bu seçenek otomatik olarak temizlenir. Kullanım örneği için aşağıdaki API Anahtarını Bearer Token Olarak Kullanma bölümüne bakın.
Adım 6: Opsiyonel Güvenlik Ayarları	Check Client IP Address (sadece Secret Manager): - Checkbox aktif edilirse, Secret Manager'da tanımlı IP listesi ile istemci IP'si karşılaştırılır. - IP uyuşmazsa 401 hatası döner. Clear Auth: - Checkbox aktif edilirse, Authorization header backend'e iletilmez. - Mikroservis mimarilerinde backend'in şifre bilgisine erişmesini engellemek için kullanılır. Set Resolved Identity to Context (Çözümlenen Kimliği İstek Bağlamına Yaz): Bu politikanın çözümlediği kimliğin (kullanıcı/anahtar) isteğin kimliği olarak kaydedilip kaydedilmeyeceğini belirler. Açık (varsayılan) iken bu kimlik trafik loglarında ve sonraki politikalar ile scriptlerde görünür. Kapalı iken kimlik yalnızca gerekli iç kimlik doğrulama/yetkilendirme kontrolleri için kullanılır, isteğin kalıcı kimliği olarak tutulmaz. Add User to Header: - Toggle aktif edilirse, doğrulanan kullanıcı bilgisi özel header ile backend'e iletilir. - User Header Name alanı açılır (varsayılan: X-Authenticated-UserId). - Backend bu header'ı okuyarak kullanıcı bağlamında işlem yapabilir.
Adım 7: Koşul Tanımlama (İsteğe Bağlı)	- Condition sekmesine geçin. - Koşullar, politikanın hangi durumda aktif olacağını belirler. Örnekler: - Ortam bazlı: Header = X-Environment, Operator = Equals, Value = production - API Key bazlı: Header = X-API-Key, Starts With = PROD- - Endpoint bazlı: Path = /api/admin/* Koşul tanımlamazsa politika her zaman aktif
Adım 8: Hata Mesajı Özelleştirme (İsteğe Bağlı)	- Error Message Customization sekmesine gidin. - Erişim reddedildiğinde dönecek mesajı özelleştirin. Varsayılan: { "statusCode": 401, "message": "Unauthorized: Invalid credentials" } Özel: { "statusCode": 401, "errorCode": "AUTH_FAILED", "message": "Kimlik doğrulama başarısız. Kullanıcı adı veya şifre hatalı." }
Adım 9: Kaydetme	- Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: - Benzersiz isim - Zorunlu alanlar dolu - En az bir Identity Role Group seçili Sonuç: - Politika listeye eklenir. - API'lere bağlanabilir. - Global politikaysa otomatik uygulanır.

not

Varsayılan kullanıcı adı/parola modunda Identity Role Group seçim listesinde OIDC Kimlik Sağlayıcı yer almaz: Basic Authentication her istekte gönderilen parolayı karşılaştırır, OIDC sağlayıcı ise token doğrular ve hiç parola vermez. API Anahtarını Bearer Token Olarak Kullan açıldığında (Gizli Anahtar/Parola Değerini Kontrol Et kapalıyken) sunulan değer bir bearer token olduğundan OIDC seçilebilir hale gelir: sağlayıcının ürettiği token her istekte sağlayıcının doğrulama moduna göre doğrulanır (çevrimdışı JWKS imzası, çevrimiçi introspection/userinfo), kimlik sağlayıcının Kullanıcı Adı Claim Yolu alanından çözülür ve Eşleşen Consumer Zorunlu açıksa bir Consumer ile eşlenir. API Anahtarını Bearer Token Olarak Kullan tekrar kapatılırsa OIDC kimlik kaynağı Secret Manager'a sıfırlanır (uyarı gösterilir); OIDC kaynağı taşıyan düz Basic politikasını sunucu reddeder. Tarayıcı tabanlı oturum açma akışları için OIDC Kimlik Doğrulama politikasını kullanın.

API Anahtarını Bearer Token Olarak Kullanma

API Anahtarını Bearer Token Olarak Kullan seçeneğini, yalnızca tek bir opak anahtar sunan ve kullanıcı adı/parola doğrulaması uygulamayan istemciler için etkinleştirin — örneğin, kendini tanıtmak için tam bir OIDC/Keycloak token alma akışına ihtiyaç duymaması gereken basit servisler arası veya makine istemcileri.

Gizli Anahtar/Parola Değerini Kontrol Et kapalı ve API Anahtarını Bearer Token Olarak Kullan açıkken, istek anahtarı standart Authorization header'ında Bearer şemasıyla taşımalıdır:

curl https://api.example.com/orders \
  -H "Authorization: Bearer <api-key>"

Bearer sonrasındaki token, API anahtarı olarak aranır — seçilen Identity Role Group'a bağlı olarak Consumer'ın kullanıcı adı veya API Client'ın clientId değeri. Bearer şeması olmayan veya token'ı boş olan bir istek, anahtar aranmadan önce reddedilir.

Koşullar ve Hata Mesajı Özelleştirme panellerinin açıklaması için Politika Nedir? sayfasındaki Koşullar ve Hata Mesajı Özelleştirme (Error Message Customization) bölümlerini inceleyebilirsiniz.

Hata mesajı yapılandırmasının tüm katmanları, öncelik sırası ve senaryo örnekleri için Hata Mesajı Yapılandırma Rehberi sayfasına bakın.

Politikayı Silme

Bu politikanın silme adımları ve kullanımdayken uygulanacak işlemler için Politika Yönetimi sayfasındaki Akıştan Politika Kaldırma bölümüne bakabilirsiniz.

Politikayı Dışa/İçe Aktarma

Bu politikanın dışa aktarma (Export) ve içe aktarma (Import) adımları için Export/Import sayfasına bakabilirsiniz.

Politikayı API'ye Bağlama

Bu politikanın API'lere nasıl bağlanacağına ilişkin süreç için Politika Yönetimi sayfasındaki Politikayı API'ye Bağlama bölümüne bakabilirsiniz.

İleri Düzey Özellikler

Özellik	Açıklama ve Adımlar
Authorization (Yetkilendirme) Yapılandırması	- Politika düzenleme sayfasında Enable Authorization toggle'ını aktif edin. - Authorization Type seçin (API, Database, LDAP veya Secret Manager). - Enable Method Access aktif edilirse, method bazlı yetkilendirme yapılır. Her HTTP method (GET, POST, PUT, DELETE vb.) için izinli roller tanımlanır. - Add Roles to Header aktif edilirse, kullanıcının rolleri backend'e header olarak iletilir.
Çoklu Kimlik Kaynağı Desteği	- Farklı kimlik kaynakları için ayrı politikalar oluşturun (örn: LDAP_Auth, Database_Auth). - Her politikaya Condition tanımlayın: Header = X-Auth-Type, Equals, LDAP veya Header = X-Auth-Type, Equals, DB. - Aynı API'ye her iki politikayı da ekleyin. Gateway isteğe göre uygun politikayı çalıştırır.
Cascading Authentication (Zincirleme Doğrulama)	- İlk politika (Base64 Authentication) ile kimlik doğrulama yapın. - İkinci politika (örn: IP Whitelist) ile ek güvenlik kontrolü ekleyin. - Politika sıralamasını doğru yapın. Kimlik doğrulama önce, diğer kontroller sonra gelmelidir.

İpuçları ve En İyi Uygulamalar

Yapılması Gerekenler ve En İyi Uygulamalar

Kategori	Açıklama / Öneriler
Kimlik Kaynağı Seçimi	Kötü: Her API için ayrı Secret Manager credential tanımlamak. İyi: Secret Manager'da grup credential tanımları kullanmak. En İyi: Merkezi LDAP veya Identity Provider (IdP) entegrasyonu kullanmak. - Tüm kullanıcılar tek noktadan yönetilir, şifre değişiklikleri otomatik yansır.
Variable Kullanımı	Kötü: Username variable tanımlamamak ve backend'in kullanıcı bilgisine erişememesi. İyi: Username variable tanımlayıp addUserToHeader ile backend'e göndermek. En İyi: Username variable + User ID variable + Roles variable tanımlayıp tüm kullanıcı bağlamını backend'e aktarmak. - Policy chain'de sonraki politikalar da bu bilgiyi kullanabilir.
Clear Auth Kullanımı	Kötü: Authorization header'ını backend mikroservislere göndermek. Şifre bilgisi gereksiz yere iletilir. İyi: clearAuth=true ayarlayıp Authorization header'ını temizlemek. En İyi: clearAuth=true + addUserToHeader=true kombinasyonu. - Backend şifre görmez, sadece doğrulanmış kullanıcı bilgisini alır.
Condition Kullanımı	Kötü: Tüm API'lere aynı politikayı condition olmadan atamak. İyi: Production ve test ortamlarını condition ile ayırmak. En İyi: Path, method, header ve query parameter kombinasyonları ile granüler kontrol. - Örn: Admin endpoint'leri için ayrı condition, public endpoint'ler için ayrı condition.
Error Message Customization	Kötü: Varsayılan hata mesajlarını kullanmak. Kullanıcı neyin yanlış gittiğini anlamaz. İyi: Türkçe hata mesajları tanımlamak: "Kimlik doğrulama başarısız". En İyi: Detaylı hata kodları ve yönlendirme bilgileri: { "errorCode": "AUTH_001", "message": "Kullanıcı adı veya şifre hatalı", "supportUrl": "https://support.example.com/auth" }

Güvenlik En İyi Uygulamaları

Güvenlik Alanı	Açıklama / Uyarılar
HTTPS Zorunluluğu	Kritik: Base64 Authentication sadece HTTPS üzerinden kullanılmalıdır. HTTP'de base64 encoding kolayca decode edilebilir ve credentials açığa çıkar. Gateway'de HTTPS enforcement aktif olmalı, HTTP istekleri otomatik olarak HTTPS'e yönlendirilmeli veya reddedilmelidir.
IP Kısıtlaması (Defense in Depth)	Öneri: Secret Manager kullanılıyorsa checkClientIpAddress=true ayarlayın. Hem credential hem de IP kontrolü yapılır. Saldırganlar credentials çalsa bile farklı IP'den erişemez. Çok katmanlı güvenlik (defense in depth) prensibi uygulanmış olur.
Credential Rotation	Uyarı: Secret Manager'da tanımlı kullanıcı şifrelerini düzenli olarak değiştirin (30-90 gün). LDAP/Database kullanılıyorsa şifre expiration policy aktif olmalıdır. Eski şifreler revoke edilmeli, yeni şifreler güçlü olmalıdır (min 12 karakter, karmaşık).
Brute Force Koruması	Öneri: Rate Limiting politikası ile aynı IP'den gelen başarısız authentication denemelerini sınırlayın. Örnek: 5 başarısız denemeden sonra 15 dakika IP block. Log'larda başarısız authentication denemelerini izleyin, anomali tespiti yapın.
Authorization Kontrolü	Kritik: Sadece kimlik doğrulama yeterli değildir, yetkilendirme de yapılmalıdır. enableAuthorization=true ayarlayın ve method bazlı rol kontrolü ekleyin. Aksi halde doğrulanmış her kullanıcı tüm endpoint'lere erişebilir (privilege escalation riski).

Kaçınılması Gerekenler

Kategori	Açıklama / Uyarılar
HTTP Üzerinden Basic Auth	Neden kaçınılmalı: HTTP trafiği şifrelenmez. Base64 encoding sadece encoding'dir, şifreleme değildir. Network sniffing ile credentials kolayca çalınabilir. Alternatif: Sadece HTTPS üzerinden Basic Auth kullanın. Gateway'de HTTP isteklerini reddedin veya HTTPS'e yönlendirin.
Authorization Header'ını Backend'e İletme	Neden kaçınılmalı: Backend mikroservislerin şifre bilgisine ihtiyacı yoktur. Şifre bilgisi backend log'larına yazılabilir veya 3. parti entegrasyonlarda açığa çıkabilir. Alternatif: clearAuth=true + addUserToHeader=true kullanın. Backend sadece doğrulanmış kullanıcı bilgisini alır.
Global Politikada Dikkatli Olmama	Neden kaçınılmalı: Global politika değişiklikleri tüm API'leri etkiler. Yanlış yapılandırma tüm servislerin erişilemez hale gelmesine neden olabilir. Alternatif: Global politika değişikliklerini test ortamında deneyin. Production'a deploy etmeden önce "Used Proxies" kontrolü yapın.
Username Variable Tanımlamamak	Neden kaçınılmalı: Backend kullanıcı bilgisine erişemez. Audit log, user tracking ve personalization özellikleri çalışmaz. Alternatif: Mutlaka username variable tanımlayın ve backend'e header ile iletin. User context tüm mikroservisler arasında tutarlı olmalı.

Performans İpuçları

Kriter	Öneri / Etki
Identity Service Cache	Öneri: LDAP veya Database kimlik doğrulaması kullanılıyorsa, Gateway'de credential caching aktif edilmelidir. Her istekte harici servis çağrısı performans kaybına neden olur. Etki: Cache süresi 5-15 dakika arası olabilir. Cache hit rate %80+ ise response time 50-100ms azalır.
Connection Pooling	Öneri: LDAP veya Database bağlantılarında connection pool kullanın. Her istekte yeni connection açmak overhead yaratır. Etki: Connection pool size 10-50 arası ayarlanabilir. Connection reuse ile 20-30ms kazanç sağlanır.
Condition Değerlendirme Sırası	Öneri: Condition kurallarını basit → karmaşık sırasına göre yazın. Hızlı sonuç veren condition'ları önce değerlendirin (örn: header check → regex check). Etki: Condition evaluation time %30-40 azalır.
Authorization Cache	Öneri: Rol bazlı yetkilendirme kullanılıyorsa, kullanıcı rollerini cache'leyin. Her istekte rol sorgulama yapmak gereksizdir. Etki: Cache TTL 10-30 dakika. Cache kullanımı ile authorization overhead %60-70 azalır.
Lightweight Identity Service	Öneri: Mümkünse Secret Manager kullanın. LDAP veya Database'e göre 3-5x daha hızlıdır çünkü local memory'de çalışır. Etki: Secret Manager response time 5ms'den az. LDAP/Database response time 20-50ms arası. Kritik performans gereksinimleri için Secret Manager tercih edilmelidir.

Sık Sorulan Sorular (SSS)

Kategori	Soru	Cevap
Genel	Base64 Authentication ile JWT Authentication arasındaki fark nedir?	Base64 Authentication her istekte kullanıcı adı ve şifre gönderilir, Gateway Identity Service'i sorgular. JWT Authentication'da ise token tabanlı çalışır, kullanıcı bir kez login olur ve sonraki isteklerde token gönderir. JWT stateless'tır ve daha performanslıdır. Base64 Auth daha basittir ancak her istekte kimlik doğrulama overhead'i vardır.
Genel	Base64 Authentication güvenli midir?	HTTPS üzerinden kullanıldığında güvenlidir. HTTP'de kesinlikle kullanılmamalıdır çünkü base64 sadece encoding'dir, şifreleme değildir. HTTPS trafiği TLS ile şifrelenir, credentials güvende kalır. Ek güvenlik için IP restriction ve rate limiting eklenmelidir.
Teknik	X-Forwarded-For header'ından IP nasıl alınır?	Kurumsal ortamlarda LDAP (Active Directory) tercih edilir çünkü merkezi kullanıcı yönetimi sağlar. Küçük ölçekli projelerde Secret Manager yeterlidir. External kullanıcılar için 3. parti Identity Provider (IdP) API entegrasyonu kullanılabilir. Database option legacy sistemler için uygundur.
Teknik	Identity Role Group olarak hangi servis seçilmeli?	Kurumsal ortamlarda LDAP (Active Directory) tercih edilir çünkü merkezi kullanıcı yönetimi sağlar. Küçük ölçekli projelerde Secret Manager yeterlidir. External kullanıcılar için 3. parti Identity Provider (IdP) API entegrasyonu kullanılabilir. Database option legacy sistemler için uygundur.
Teknik	checkClientIpAddress ne zaman kullanılmalı?	Yüksek güvenlik gerektiren senaryolarda (örn: admin paneli, finansal işlemler) kullanılmalıdır. Kullanıcının IP adresi sabitlenebiliyorsa (örn: ofis IP) etkilidir. Mobil kullanıcılar veya dinamik IP'li senaryolarda kullanışlı değildir çünkü IP sık değişir.
Kullanım	clearAuth ne zaman kullanılmalı?	Mikroservis mimarisinde backend'in şifre bilgisine ihtiyacı yoksa mutlaka kullanılmalıdır. Gateway kimlik doğrulama yapar, backend sadece doğrulanmış kullanıcı bilgisini alır. Security best practice olarak backend'e credentials gönderilmemelidir (least privilege principle).
Kullanım	Global politika mı Local politika mı kullanmalıyım?	Çoğu API aynı kimlik doğrulama kuralını kullanıyorsa Global politika kullanın. Merkezi yönetim ve tutarlılık sağlar. Sadece 1-2 API'de farklı kural gerekiyorsa Local politika oluşturun. Local politika test ve geliştirme aşamasında daha esnektir.