Genel Bakış
Backend API Authentication politikası, API Gateway’in backend servislerine erişim sağlarken kullanacağı kimlik doğrulama bilgilerini tanımlar. Plain-Text, Basic, API Key ve Digest gibi farklı authentication yöntemlerini destekleyerek backend sistemlere güvenli bağlantı kurar. Mikroservis mimarilerinde her servisin farklı authentication gereksinimlerini merkezi olarak yönetmek için idealdir.Amacı Nedir?
- Backend API servislerine yapılan çağrılarda kimlik doğrulama bilgilerinin otomatik olarak eklenmesini sağlar, böylece her istek için manuel credential yönetimi gerekmez.
- Basic, Digest, Base64 ve özel API Authentication olmak üzere dört farklı kimlik doğrulama türünü destekler ve koşullu kullanıcı adı/şifre tanımlarına izin verir.
- Kimlik doğrulama bilgilerinin HTTP Header, URL Parametresi, Body Message veya Body Injection yöntemleriyle backend’e iletilmesini sağlar.
- XML ve JSON formatlarında mesaj içeriği desteği sunarak hem SOAP hem de REST servisleriyle uyumlu çalışır.
- Koşul bazlı credential yönetimi sayesinde farklı senaryolarda (örn: environment, endpoint, header değerine göre) farklı kullanıcı bilgileri kullanılabilir.
Çalışma Prensibi
- İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemin backend servise yönlendirilmeden önce kimlik doğrulama bilgisinin eklenmesi gerekip gerekmediği kontrol edilir.
- Politika Kontrolü: API 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ı?
- Kimlik Doğrulama Türü Seçimi: Tanımlanan Auth Type’a göre (API, BASIC, BASE64, DIGEST) uygun kimlik bilgisi hazırlanır. Eğer Conditional Expression tanımlıysa, koşullara göre doğru username/password seçilir.
- Karar Verme:
- Koşul Sağlanırsa: İlgili credential bilgisi seçilen Send Type metoduyla (Header, Param, Body Message, Body Injection) backend çağrısına eklenir ve istek iletilir.
- Koşul Sağlanmazsa veya Credential Bulunamazsa: İstek reddedilir ve özelleştirilebilir hata mesajı döndürülür.
- Hata İşleme: Politika kuralına uymayan istekler için özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.
Özellikler ve Yetenekler
Temel Özellikler
- Dört Farklı Kimlik Doğrulama Türü: API (hazır auth servisi), Basic Authentication, Base64 encoded Authorization, Digest Authentication desteği.
- Koşullu Credential Yönetimi: Her username/password çifti için ayrı koşullar tanımlayarak ortam, endpoint veya header değerine göre dinamik credential seçimi yapabilme.
- Dört Farklı Gönderim Yöntemi: Kimlik bilgilerini HTTP Header, URL Parametresi, Body Message veya Body Injection yöntemleriyle backend’e gönderebilme.
- XML ve JSON Desteği: Body tabanlı kimlik doğrulamada hem XML (SOAP) hem de JSON (REST) formatlarını destekleme ve XPath/JSONPath injection yapabilme.
- API Authentication Entegrasyonu: Hazır tanımlı Authentication API servislerini kullanarak merkezi credential yönetimi yapabilme.
- 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
- Dinamik Field Name ve Injection Path Tanımlama: Header, parametre veya body injection için field name ve path’leri özelleştirerek esnek kimlik doğrulama yapılandırması oluşturma.
- Digest Authentication Desteği: Nonce, Created timestamp gibi gelişmiş güvenlik parametreleriyle Digest authentication yapabilme (SOAP WS-Security uyumlu).
- Body Message Template Desteği: XML ve JSON için hazır body message template’leri kullanarak hızlı SOAP/REST kimlik doğrulama konfigürasyonu oluşturma.
- XPath ve JSONPath Test Aracı: Body injection ve message path’lerini canlı olarak test edebilme ve doğrulama yapabilme.
- Username Expression Table: Birden fazla username/password çifti tanımlayıp her biri için farklı koşullar belirleyerek çok senaryolu credential yönetimi yapabilme.
- 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ç |
|---|---|---|---|
| Backend SOAP Servisine WS-Security ile Bağlanma | SOAP backend servisi Basic Authentication ile korumalı ve WS-Security header’ı bekliyor | Auth Type: BASIC Send Type: BODY_MESSAGE Message Type: XML Username/Password: Conditional Expression ile tanımlanmış Body Message: WS-Security template kullan | Gateway, tüm SOAP isteklerine otomatik olarak WS-Security header’ı ekler. Backend servis kimlik doğrulamasını geçer ve cevap döner. |
| Ortam Bazlı Farklı Credential Kullanımı | Test ortamında test_user, Production ortamında prod_user kullanılması gerekiyor | Auth Type: BASIC Send Type: HEADER Conditional Expression 1: Header X-Environment = test → username: test_user Conditional Expression 2: Header X-Environment = prod → username: prod_user | Gateway, gelen istekteki X-Environment header’ına göre doğru credential’ı seçer ve backend’e iletir. |
| REST API’ye Base64 Authorization Header Ekleme | REST backend servisi “Authorization: Basic base64string” header’ı bekliyor | Auth Type: BASE64 Send Type: HEADER Password Field Name: Authorization Conditional Expression: İlgili username/password tanımlanmış | Gateway, username ve password’ü otomatik olarak Base64 encode eder ve Authorization header’ına ekleyerek backend’e gönderir. |
| Hazır Authentication API Kullanımı | Merkezi bir OAuth/OIDC servisi üzerinden token alınıp backend’e gönderilmesi gerekiyor | Auth Type: API Auth API ID: Seçilen Authentication API servisi Send Type ve diğer parametreler API konfigürasyonuna göre | Gateway, tanımlı Authentication API’yi çağırır, aldığı token’ı kullanarak backend servisine kimlik doğrulamalı istek gönderir |
| JSON REST API’ye Digest Authentication | JSON backend servisi digest authentication bekliyor ve nonce/created bilgisi istiyor | Auth Type: DIGEST Send Type: BODY_INJECTION Message Type: JSON Field Names: username, password, nonce, created Injection Paths: JSONPath ile belirlenen path’ler | Gateway, digest authentication için gerekli nonce ve created değerlerini oluşturur, JSON body’ye inject eder ve backend’e gönderir. |
| URL Parametresi ile Kimlik Doğrulama | Legacy backend servisi kimlik bilgilerini query string parametresi olarak bekliyor | Auth Type: BASIC Send Type: PARAM Username Param Name: api_user Password Param Name: api_key Conditional Expression: İlgili credential tanımlanmış | Gateway, kimlik bilgilerini URL query string’ine ekler: ?api_user=xxx&api_key=yyy |
| Endpoint Bazlı Farklı Credential | /admin endpoint’i admin credential, /user endpoint’i user credential gerektiriyor | Koşul (Policy Condition): Path starts with /admin → Admin API Authentication Policy Koşul (Policy Condition): Path starts with /user → User API Authentication Policy | Gateway, gelen isteğin path’ine göre doğru politikayı uygular ve ilgili credential’ı kullanır. İki ayrı policy veya tek policy içinde conditional expression kullanılabilir. |
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 API 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 → API 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_Backend_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 backend servislerine kimlik doğrulama bilgisi ekler” - Maks. 1000 karakter. - Politikanın amacını açıklayın. |
| Adım 3: Kimlik Doğrulama Türü Seçimi (Auth Type) | Auth Type Dropdown (Zorunlu): Seçenekler: - API: Önceden tanımlı Authentication API servisi kullanır (OAuth, OIDC vb.) - BASIC: Kullanıcı adı ve şifre ile temel kimlik doğrulama - BASE64: Base64 encoded authorization header - DIGEST: Digest authentication (nonce, created ile güvenli kimlik doğrulama) Not: - API seçilirse: “Select Authentication API” butonu görünür, hazır auth servisi seçilir. - BASIC/BASE64/DIGEST seçilirse: Username/Password Expression Table görünür. |
| Adım 4: Username/Password Expression Tanımlama (Auth Type: BASIC, BASE64 veya DIGEST için) | Bu bölümde, koşullu kullanıcı adı ve şifre tanımları yapılır. Birden fazla credential tanımlanabilir ve her biri için farklı koşullar belirlenebilir. Username/Password Expression Table: - [+ Add] butonuna tıklayın. - Username: İlgili kullanıcı adını girin (örn: backend_user, ${variable.username})- Password: İlgili şifreyi girin (örn: backend_pass123, ${variable.password})- Condition (Koşul): Query Builder ile koşul tanımlayın - Örnek: Header[X-Environment] Equals production- Örnek: Path Starts With /adminNot: - En az bir username/password tanımı zorunludur. - Koşullar sırayla değerlendirilir, ilk eşleşen kullanılır. |
| Adım 5: Gönderim Yöntemi Seçimi (Send Type) (Auth Type: BASIC, BASE64 veya DIGEST için) | Send Type Dropdown (Zorunlu): HEADER: Kimlik bilgileri HTTP header’larında gönderilir - Username Header Name: Kullanıcı adı header adı (örn: X-Username)- Password Header Name: Şifre header adı (örn: X-Password)- Digest için: Created Header Name, Nonce Header Name PARAM: Kimlik bilgileri URL parametresi olarak gönderilir - Username Param Name: Kullanıcı adı parametre adı (örn: user)- Password Param Name: Şifre parametre adı (örn: pass)- Digest için: Created Param Name, Nonce Param Name BODY_MESSAGE: Hazır mesaj template’i body’ye eklenir - Message Content Type: XML veya JSON seçin - Body Message: Otomatik template yüklenir (WS-Security için XML, JSON için username/password object) - Body Message Injection Path: Template’in nereye ekleneceği (XPath veya JSONPath) BODY_INJECTION: Mevcut body’ye field injection yapılır - Message Content Type: XML veya JSON seçin - Username Field Name: Kullanıcı adı field adı (örn: username)- Username Injection Path: XPath veya JSONPath (örn: $.credentials.username)- Password Field Name: Şifre field adı (örn: password)- Password Injection Path: XPath veya JSONPath (örn: $.credentials.password)- Digest için: Created Field Name, Created Injection Path, Nonce Field Name, Nonce Injection Path |
| Adım 6: 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 7: 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: Authentication credentials are missing or invalid" }Özel: { "statusCode": 401, "errorCode": "AUTH_FAILED", "message": "Backend kimlik doğrulama başarısız. Lütfen sistem yöneticisi ile iletişime geçin." } |
| Adım 8: Kaydetme | - Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: - Benzersiz isim - Zorunlu alanlar dolu - En az bir username/password tanımı mevcut Sonuç: - Politika listeye eklenir. - API’lere bağlanabilir. - Global politikaysa otomatik uygulanır. |
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 |
|---|---|
| Variable Expression Kullanımı | - Username ve password alanlarında değişken ifadeleri kullanın (örn: ${env.backend_user}, ${vault.db_password})- API Proxy veya Global Settings → Variables bölümünden ilgili değişkenleri tanımlayın - Değişkenler runtime’da çözümlenir ve güvenli credential yönetimi sağlanır Fayda: Credential’lar kod içinde hardcoded olmaz, merkezi yönetim ve güvenlik artar. |
| XPath ve JSONPath Test Aracı | - Send Type olarak BODY_MESSAGE veya BODY_INJECTION seçin - Field Name ve Injection Path alanlarının yanındaki [Test] butonuna tıklayın - Test penceresinde sample XML/JSON mesajınızı girin - Tanımladığınız XPath/JSONPath ifadesinin doğru çalışıp çalışmadığını görün Fayda: Canlı ortama almadan önce injection path’lerinizi test edebilir, hata riskini azaltırsınız. |
| Authentication API Entegrasyonu | - Global Settings → Authentication API bölümünden OAuth, OIDC veya Custom Auth servisi tanımlayın - API Authentication politikasında Auth Type = API seçin - “Select Authentication API” butonuna tıklayarak tanımlı auth servisini seçin - Backend çağrılarında otomatik olarak token alınıp kullanılır Fayda: OAuth/OIDC gibi karmaşık auth flow’larını merkezi yönetim ve token yenileme otomatik yapılır. |
İpuçları ve En İyi Uygulamalar
Yapılması Gerekenler ve En İyi Uygulamalar
| Kategori | Açıklama / Öneriler |
|---|---|
| Credential Yönetimi | Kötü: Kullanıcı adı ve şifreleri politika içinde hardcode etmek: username: admin, password: 12345İyi: Variable expression kullanmak: username: ${backend.user}, password: ${backend.pass}En İyi: Variable expression + Vault entegrasyonu kullanmak: username: ${vault.backend_user}, password: ${vault.backend_password}- Güvenlik maksimum düzeyde, credential rotation kolay |
| Koşul Tanımlama | Kötü: Tek bir global politikada tüm ortamlar için aynı credential kullanmak İyi: Her ortam için ayrı politika oluşturmak (Dev_Auth, Test_Auth, Prod_Auth) En İyi: Tek politika içinde conditional expression kullanarak ortam bazlı credential yönetimi: Header[X-Environment] = prod → prod_user- Merkezi yönetim, daha az politika, daha kolay bakım |
| Send Type Seçimi | Kötü: Legacy sistemler için BODY_MESSAGE/BODY_INJECTION kullanmak (performans düşer) İyi: Modern REST API’ler için HEADER kullanmak (standart ve hızlı) En İyi: Backend’in beklentisine göre uygun yöntemi seçmek: SOAP WS-Security için BODY_MESSAGE, REST için HEADER, Legacy için PARAM - Uyumluluk ve performans dengesi |
| Test ve Deploy Stratejisi | Kötü: Global politikayı doğrudan production’da oluşturup test etmek İyi: Önce local politika olarak test etmek, sonra global yapmak En İyi: Dev ortamında global politika oluşturup test etmek → Export → Test ortamına import → Test → Prod ortamına import - Risk minimize, kontrollü deploy |
| Authentication API Kullanımı | Kötü: OAuth token’larını manuel olarak yönetmeye çalışmak (token expiration, refresh logic vb.) İyi: Her API için ayrı auth logic yazmak En İyi: Merkezi Authentication API tanımlayıp tüm API’lerde kullanmak - Token yenileme otomatik, merkezi yönetim, kod tekrarı yok |
Güvenlik En İyi Uygulamaları
| Güvenlik Alanı | Açıklama / Uyarılar |
|---|---|
| Credential Güvenliği | Uyarı: Credential’ları asla log’lara yazdırmayın. Politika içinde credential’ları hardcode etmekten kaçının. Şifreleri düz metin olarak saklamayın. Çözüm: Variable expression + Vault entegrasyonu kullanın. Log masking aktif olsun. Credential rotation politikaları uygulayın. |
| HTTPS Kullanımı | Uyarı: Backend kimlik doğrulama bilgileri HTTP üzerinden gönderilirse man-in-the-middle saldırılarına açık hale gelir. Çözüm: Backend servislere mutlaka HTTPS üzerinden bağlanın. TLS 1.2 veya üstü kullanın. Self-signed sertifika kullanmayın (prod için). |
| Least Privilege Prensibi | Uyarı: Tüm backend servisleri için aynı admin credential’ı kullanmak büyük güvenlik riski oluşturur. Çözüm: Her backend servisi için ayrı, sadece gerekli yetkilere sahip credential kullanın. Conditional expression ile servis bazlı credential yönetimi yapın. |
| Audit ve Monitoring | Uyarı: Kimlik doğrulama başarısızlıklarını izlemezseniz saldırı girişimlerini kaçırırsınız. Çözüm: Auth failure log’larını aktif edin. Monitoring ve alerting kurun. Başarısız auth denemelerini limit edin (Rate Limiting ile birlikte kullanın). |
| Policy Update Güvenliği | Uyarı: Global politikayı güncellerken tüm bağlı API’lerde kimlik doğrulama kesintiye uğrayabilir. Çözüm: Önce test ortamında deneyin. Production’da güncelleme yapmadan önce backup alın. Deploy’dan sonra Used Proxies’de test edin. Blue-green deployment stratejisi kullanın. |
Kaçınılması Gerekenler
| Kategori | Açıklama / Uyarılar |
|---|---|
| Hardcoded Credential Kullanımı | Neden kaçınılmalı: Güvenlik riski oluşturur. Credential değiştiğinde tüm politikaları manuel güncellemek gerekir. Kod review’lerde credential’lar görünür. Alternatif: Variable expression ve Vault kullanın: ${vault.backend_credentials.username} |
| Send Type Yanlış Seçimi | Neden kaçınılmalı: Backend’in beklediği format dışında gönderim yapılırsa kimlik doğrulama başarısız olur. BODY_MESSAGE kullanırken mevcut body’yi ezebilir. Alternatif: Backend dokümantasyonunu inceleyin ve uygun Send Type’ı seçin. BODY_INJECTION kullanırken path’lerin doğruluğunu test edin. |
| Conditional Expression Kullanmadan Çok Sayıda Politika Oluşturma | Neden kaçınılmalı: Yönetim zorlaşır. Deploy karmaşık hale gelir. Aynı mantığı farklı politikalarda tekrarlamak hata riskini artırır. Alternatif: Tek politika içinde conditional expression kullanarak farklı senaryoları yönetin. Policy Group kullanın. |
| Test Etmeden Production’a Deploy | Neden kaçınılmalı: Yanlış yapılandırma tüm backend çağrılarını kırar. Credential yanlışsa servisler erişilemez hale gelir. Downtime oluşur. Alternatif: Önce local politika olarak test edin. Dev/Test ortamlarında doğrulayın. Canary deployment kullanın. |
Performans İpuçları
| Kriter | Öneri / Etki |
|---|---|
| Send Type Performansı | Öneri: HEADER veya PARAM kullanın (en hızlı). BODY_MESSAGE ve BODY_INJECTION daha fazla işlem gerektirir. Etki: HEADER: ~1ms ek süre, BODY_MESSAGE: ~5-10ms, BODY_INJECTION: ~10-20ms (message boyutuna bağlı) |
| Conditional Expression Sayısı | Öneri: Conditional expression sayısını makul seviyede tutun (max 5-10). Karmaşık XPath/JSONPath yerine basit koşullar kullanın. Etki: Her expression ~0.5ms ekler. Çok fazla expression runtime overhead oluşturur. |
| Variable Expression Çözümleme | Öneri: Variable expression’ları cache’lenen değişkenlerden çözümleyin. Her istekte external Vault’a gitmekten kaçının (caching kullanın). Etki: Cache hit: ~0.1ms, Cache miss + Vault call: ~50-100ms |
| Message Content Type | Öneri: JSON kullanın (daha hafif ve hızlı parse). XML sadece SOAP servisleri için gerekli. Etki: JSON parsing: ~2-5ms, XML parsing: ~10-20ms (message boyutuna bağlı) |
| Authentication API Cache | Öneri: Authentication API kullanıyorsanız token cache’i aktif edin. Token expiration süresini optimize edin (너무 kısa: çok sık yenileme, çok uzun: güvenlik riski). Etki: Cached token: ~0.5ms, Yeni token almak: ~100-500ms (auth service’e bağlı) |
Sık Sorulan Sorular (SSS)
| Kategori | Soru | Cevap |
|---|---|---|
| Genel | API Authentication politikası ne zaman kullanılmalı? | Backend servisleriniz kimlik doğrulama gerektiriyorsa ve bu bilgileri her istekte manuel eklemek istemiyorsanız bu politikayı kullanmalısınız. Özellikle SOAP WS-Security, Basic Auth, OAuth token yönetimi gibi durumlarda idealdir. |
| Genel | Birden fazla Authentication politikası aynı API’ye atanabilir mi? | Hayır, bir API’ye sadece bir tane API Authentication politikası atanabilir. Ancak conditional expression kullanarak tek politika içinde birden fazla senaryo yönetebilirsiniz. |
| Teknik | BODY_MESSAGE ve BODY_INJECTION arasındaki fark nedir? | BODY_MESSAGE: Hazır bir template’i mesajın belirli bir yerine ekler (örn: SOAP Header). Mevcut body’yi değiştirmez, sadece ekler. BODY_INJECTION: Mevcut body içindeki belirli alanlara credential bilgilerini inject eder. XPath/JSONPath ile hedef field’ları bulup değer atar. |
| Teknik | Authentication API kullanırken token yenileme otomatik mi yapılıyor? | Evet, Authentication API yapılandırmasında token expiration ve refresh logic tanımlıysa Apinizer otomatik olarak token’ı yeniler. Manual müdahale gerekmez. |
| Kullanım | Ortam bazlı farklı credential nasıl yönetilir? | İki yöntem: 1) Conditional Expression kullanarak tek politika içinde Header[X-Environment] = prod → prod_user şeklinde tanım yapın.2) Her ortam için ayrı politika oluşturun ve deployment sırasında doğru politikayı aktif edin. Birinci yöntem önerilir (merkezi yönetim). |
| Kullanım | Variable expression’da hangi değişken kaynaklarını kullanabilirim? | ${env.VAR_NAME}: Environment variables${variable.VAR_NAME}: API Proxy veya Global Variables${vault.PATH}: Vault entegrasyonu (HashiCorp Vault, AWS Secrets Manager vb.)${header.HEADER_NAME}: Request header’larından değer alma |
| Güvenlik | Credential’lar log’larda görünür mü? | Hayır, Apinizer default olarak credential field’larını log’lardan maskeler. Ancak custom log policy kullanıyorsanız masking kurallarını kontrol edin. |
| Güvenlik | Digest authentication’da nonce ve created nasıl oluşturuluyor? | Apinizer otomatik olarak her istek için unique nonce (Base64 encoded random değer) ve created (ISO 8601 timestamp) değerleri oluşturur. Manual müdahale gerekmez. |
| Hata Giderme | ”Authentication credentials are missing or invalid” hatası alıyorum | Şunları kontrol edin: 1) Conditional expression’larınız doğru mu? (hiçbiri match etmiyorsa hata alırsınız) 2) Variable expression’lar çözümlenebiliyor mu? 3) Backend’in beklediği format ile Send Type uyumlu mu? 4) Field name’ler ve injection path’ler doğru mu? Debug için API logs ve policy execution logs’ları inceleyin. |