Tüketiciler

bilgi

Apinizer'da Kimlik Yönetimi ile yapılan erişim denetimi ayarı 2 farklı şekilde yapılandırılabilir:

1. Tüketiciler üzerinden: Tüketicinin detayına gidilir. Tüketicinin detayında erişim izni verilmiş API Proxy'ler ve ayarları görüntülenerek işlem yapılır.
2. API Proxy'ler üzerinden: API Proxy'nin detayına gidilir. API Proxy'e erişim izni verilmiş tüketiciler görüntülenerek işlem yapılır.

Bu sayfa, birinci seçenekteki koşulu gerçekleştirir.

not

Bu ekran, önceki Apinizer sürümlerinde Kimlik Bilgisi (Credential) adıyla yer alıyordu; bu sürümde yalnızca ekrandaki isim Tüketici olarak değişti — API'ler ve URL'ler aynı kalmaya devam ediyor.

uyarı

Tüketici erişim izni, API proxy'e erişim için tek başına yeterli değildir. Tüketicideki ve erişim iznindeki ayarların geçerli olması için API Proxy üzerinde kimlik doğrulama politikalarından birisi eklenmiş olmalı ve bu politikada kimlik doğrulama şekli olarak Security Manager seçeneği seçili olmalıdır.

Tüketici Listesi

Tüketiciler sayfası ilk açıldığında mevcut tüketicilerin listelendiği görsele aşağıda yer verilmiştir:

Tüketici listesi

Ekran bileşenleri için kullanılan alanlar aşağıdaki tabloda görülmektedir.

Alan	Açıklama
Arama Alanı (Advanced Search)	Tüketiciler üzerinde detaylı arama yapmak için kullanılır.
Tüketici Listesi (Access Control List)	Tüketicilerin listelendiği ve sıralandığı tablodur.
Oluştur (Create)	Yeni "Tüketici" oluşturmak için kullanılır.
CSV'den İçe Aktar (Import From CSV)	Topluca tüketici kaydedilmesi için kullanılır.
Veriyi Aktar (Import)	Tüketiciyi .json veya .zip uzantılı olarak içe aktarmak için kullanılır.
Tüketiciler Listesini Excel Dosyası Olarak Dışa Aktar (Export Consumer List as an Excel File)	Tüketiciler listesini excel dosyası olarak indirmek için kullanılır.
Dışa Aktar (Export)	Tüketiciye ait tüm veriler, başka bir proje de tekrar kullanmak için dışa aktarılabilir. Bu süreçte, sadece genel bilgiler dışa aktarılır. Gelişmiş ayarlar, API Proxy EKL, API Proxy Grup EKL, JWK ayarları ve mTLS ayarları, proje bazında bilgiler oldukları için dışa aktarılmaz.

Listedeki her tüketicinin yanında bir Kaynak etiketi görüntülenir: kayıt Apinizer'da elle oluşturulmuşsa Apinizer, bir kimlik sağlayıcısından senkronize edilmişse LDAP, Veritabanı, API veya OIDC görünür; senkron kaynaklı kayıtlarda etiketin yanında kaydı senkronize eden sağlayıcının adı da yer alır.

CSV ile Toplu Tüketici Aktarımı

Hali hazırda mevcut olan tüketicilerin Apinizer'a aktarımı için CSV'den aktar özelliği kullanılabilir.

Bu özellik kullanılmak istenirse;

Veri Formatı

Mevcut kullanıcı bilgileri her bir kayıt bir satıra gelecek şekilde yazılmalıdır.

Bilgi İçeriği

Kayıt içerisinde kullanıcı adı ve parola bilgisi beraber ve parola bilgisi açık olarak yer almak zorundadır.

Ayıraç Kullanımı

kullanıcı adı ve parola bilgisi arasına ayıraç olarak # işareti koyulmalıdır.

Satır Ayrımı

Her bir satır Enter tuşu ile ayrılmalıdır.

Bu şekilde hazırlanan veriler açılan ekrana girilerek içe aktar tuşuna basılır.

Tüketiciyi Dışa Aktarma

Tüketiciyi dışa aktarmak için satır sonundaki menüden Dışa Aktar (Export) seçilir.

Tüketiciyi Globalleştirme

Tüketiciler "Globalleştir" seçeneği ile Admin sayfasına taşınarak görünümü bu listeden kalkar, tüm projelerde kullanılabilir hale gelir ve yönetimi Admin kullanıcısına bırakılır.

Tüketiciyi globalleştirmek için satır sonundaki menüden Globalleştir (Move to Global) seçilir.

Tüketici Oluşturma

Tüketiciler eklemek için Oluştur (Create) tuşuna basıldığında aşağıda görseli paylaşılan ekran gelir:

Tüketici oluşturma formu

Oluşturma formunda Information / Metadata / Token Settings / Secrets sekmeleri yoktur. Kullanıcı adı ve parola bu adımda girilmez ve otomatik üretilmez; kayıt oluştuktan sonra API İstemcileri sekmesinden eklenir. Erişim denetimi, limit, token ve metadata da sağ panelde belirtildiği gibi tüketici detayında yönetilir.

Bu görselde de görüldüğü üzere tüketicilerin üzerinde iki tür işlem yapabiliriz:

1. Tüketicinin detaylarının girilmesi, oluşturulması veya güncellenmesi
2. Tüketicinin erişim denetimi listesinin oluşturulması veya güncellenmesi

Tüketici alanlarının açıklamaları şu şekildedir:

Alan	Açıklama
Ad (Name)	Oluşturma formundaki zorunlu görünen addır.
Kullanıcı Adı (Client Id/Username)	Kimliği ifade edecek "kullanıcı adı" bilgisidir, yetkilendirme için kullanıcı kimliğine erişmek için bu değer kullanılır. Tüm sistemde tekil ve biricik olmak zorundadır. Oluşturma formunda yer almaz; API İstemcileri üzerinden eklenir.
Parola (Client Secret/Password)	Kimliğin parola bilgisidir. İstenirse yanındaki tuş ile otomatik oluşturulabilir. Oluşturma formunda yer almaz; API İstemcileri üzerinden eklenir.
E-Posta (E-mail)	Kimliğin sahibi istemciye erişmek için kullanılan ve istemciye ait mail bilgisidir.
Tam Adı (Full Name)	Kimliğin sahibi istemcinin tam adıdır.
Aktif (Enabled)	Tüketicinin aktif (kullanılabilir) olup olmadığını belirtir. Seçilmiş ise aktiftir.
Trafiği loglama (Do not log traffic)	Bu tüketicinin API trafiğinin trafik log konnektörlerine yazılmasını durdurur. Varsayılanı kapalıdır. Bkz. Bir Tüketicinin Trafik Logunu Kapatma.
Harici (External)	Tüketicinin dış kimlik olarak işaretlenip işaretlenmediğini belirtir.
Geçerliliğini Yitirme Zamanı (Expires On)	Bu tarih değerinin girilmesi durumunda Tüketici bu tarihten itibaren erişemez hale gelir.
Kurum (Organization)	Tüketicinin bağlı olduğu kurum/organizasyon bilgisi isteğe bağlı olarak seçilebilir. Raporlamanın ötesinde, bu bağlantı bu tüketici için üretilen token'lara kurum seviyesi metadata olarak miras kalır — bkz. Kurum Seviyesi Metadata. Seçim listesi yalnızca çağıran projenin kapsamındaki kurumları (kendi projesinin kurumları ve kurulum-geneli/admin kapsamlı kurumlar) sunar; başka bir projeye ait bir kurum seçilemez — bu kural sunucu tarafında da uygulanır. Tüketici zaten mevcutsa bu alan salt okunurdur: bir tüketiciyi başka bir kuruma taşımak için aşağıdaki Tüketiciyi Başka Bir Kuruma Taşıma bölümündeki eylem kullanılır, bu alan düzenlenerek yapılmaz.
Roller (Roles)	Tüketicinin sahip olduğu rollerdir. Bu rollere göre yetkilendirme yapılır.
IP Listesi (IP List)	Tüketicinin sadece belli IP adreslerden gelmesi gerekiyorsa, bu tüketicinin hangi IP adreslerinden erişebileceği bilgisi buraya girilir. Boş bırakılması tüm IP'lerden isteğin kabul edileceği anlamına gelir.
IP Coğrafi Konum (IP Geolocation)	Tüketicinin sadece belirli ülkelerden erişim yapmasına izin vermek için kullanılır. Ülke seçimi yapılabilir. Varsayılan olarak "Countries: All" seçilidir ve tüm ülkelerden erişime izin verir.
Açıklama (Description)	Tüketici hakkında açıklama girilmek istenirse bu alan doldurulabilir.
Gelişmiş Ayarları Aktifleştir (Enable Advanced Settings)	Tüketicinin parola ve IP listesinin ortam bazlı özelleştirilme ihtiyacı varsa, bu seçenek ile özelleştirme ayarları aktif hale gelir. Seçildiğinde her bir ortam için parola ve IP listesi girilebilir hale gelir.
Ortam Parolası (Environment Password)	İlgili satırdaki ortama özel olarak kullanılmak üzere parola girilebilir.
Ortam IP Listesi (Environment IP List)	İlgili satırdaki ortama özel olarak kullanılmak üzere IP listesi girilebilir.
Silinmiş ortam	Bu projenin artık göremediği bir ortama işaret eden satır — ortam silinmiş, yayından kaldırılmış ya da başka bir projeye taşınmış olabilir — adı boş görünmek yerine Silinmiş ortam rozetiyle işaretlenir. Satırın parolası ve IP listesi olduğu gibi korunur: yalnızca yayından kaldırılmış ya da yeniden atanmış bir ortam geri gelebileceği için sizin adınıza hiçbir şey silinmez. Satır artık gerekmiyorsa kendiniz kaldırabilirsiniz.

Düzenleme ekranındaki Parola alanının göz simgesiyle açılması ya da kopyalanması da denetim kaydına yazılır; bkz. Hassas Erişim Olayları.

not

Düzenlemekte olduğunuz tüketici bu sırada başka biri tarafından silinmişse kaydetme işlemi reddedilir; formun elindeki eski id ile sessizce yeni ve bağlantısız bir kayıt oluşturulmaz.

Tüketici Anahtarı (Consumer Key)

Tüketiciler, kullanıcı adının yanı sıra bir tüketici anahtarı taşır: kayıt oluşturulurken sunucu tarafından atanan kalıcı ve okunabilir kimliktir. Bu anahtar Tüketiciler ekranının hiçbir yerinde — ne listede, ne görüntülemede, ne de düzenlemede — gösterilmez ve elle değiştirilemez; yalnızca Management API (APIops) yanıtlarında görünür. Dışa aktarma/içe aktarma paketleriyle de taşınmaz — bir tüketici dışa aktarıldığında anahtar pakete dahil edilmez.

Bir tüketicinin değişmeyen yanı tüketici anahtarıdır. Kullanıcı adı değiştirilebilir — o, giriş ve görüntüleme kimliğidir — ve tüketici anahtarı bununla birlikte değişmez; kayda yapılan bir referansın yeniden adlandırmadan sağ çıkmasını sağlayan da budur.

Anahtar tek bir tüketiciyi tanımladığı için ikinci bir kayda taşınmaz: Kopyala (Duplicate) ile üretilen tüketici oluşturulduğu anda kendine ait yeni bir anahtar alır. Yeni Olarak İçe Aktar (Import as New) ile getirilen bir tüketici ise anahtarsız gelir; bu kayıtlara ve bu sürümden önce var olan anahtarsız kayıtlara anahtar, düzenli aralıklarla çalışan bir arka plan bakım göreviyle sonradan atanır.

not

Tüketici anahtarı bir sır ya da parola değildir — kullanıcı adı gibi herkese açık bir tanımlayıcıdır ve tek başına hiçbir erişim yetkisi vermez.

bilgi

Bu sürümden itibaren bir kimlik sağlayıcıdan senkronizasyon ile gelen kayıtlar ve CSV dosyasından toplu olarak içe aktarılan kayıtlar da oluşturuldukları anda tüketici anahtarı alır — ekrandan ve Management API üzerinden oluşturulanlarla aynı kural geçerlidir. Senkron kaynaklı kayıtlar ayrıca ilk senkronize edildikleri zamanı da taşır.

Bir Tüketicinin Trafik Logunu Kapatma

Bazı müşteriler, gizlilik veya kişisel verilerin korunması gerekçesiyle API trafiklerinin saklanmamasını ister. Trafiği loglama seçeneği bu talebi tek bir tüketici için karşılar: açıkken, bu tüketicinin trafiği hiçbir trafik log konnektörüne gönderilmez — Elasticsearch, Kafka, Syslog, Veritabanı, Webhook ve diğerleri.

Seçeneği açık olan tüketiciler, tüketici listesinde ve kurum genel bakış ekranında Trafik logu kapalı rozetiyle görünür; böylece susturulmuş bir müşteri her kaydı tek tek açmadan fark edilir.

Kapsam bilinçli olarak dardır. Bu seçeneği açmak şunları durdurmaz:

• İz kayıtları ve OpenTelemetry span'ları — bir olayı teşhis etmek için kullanılan operasyonel iz
• Prometheus metrikleri — mesaj içeriği taşımayan istek sayıları ve süreler
• Güvenlik ve erişim olayları — kota, anomali ve güvenlik incelemelerinin dayandığı denetim izi
• Kimlik doğrulaması başarısız olan istekler — bir istek, ancak gateway sunulan kimliği gerçekten doğruladıktan sonra susturulur. Susturulmuş bir tüketicinin kullanıcı adını yanlış parolayla, geçersiz bir API anahtarıyla ya da reddedilen bir token'la gönderen çağrıcı, bu anahtar açısından o tüketici değildir; engellenen istek trafik log konnektörlerine her zamanki gibi yazılır. Başarısız kimlik doğrulama trafiği, sonraki bir incelemenin tam olarak ihtiyaç duyduğu şeydir; bu yüzden doğrulanmamış bir çağrıcının onu bastırabilmesi mümkün değildir.

Bir gizlilik tercihinin güvenlik veya denetim izini silebiliyor olması doğru değildir; bu yüzden o hatlar açık kalır. Kurulum gerçekten sıfır saklama istiyorsa doğru araç bu anahtar değil, No Persist veri saklama profilidir.

Operatör kararıdır, müşterinin self-servis tercihi değil

Bu anahtar, yönetici yetkisi olan biri tarafından Manager ekranlarından (ya da APIops üzerinden) ayarlanır. API Portal'da bilinçli olarak sunulmaz: kendi kaydını ya da kendi uygulamasını düzenleyen bir portal müşterisi bunu açıp kapatamaz; portalden gelen bir istek gövdesinde bu alan gönderilse bile uygulanmaz, yok sayılır. Gerekçesi şudur: anahtarın açılması, bir müşterinin trafiğini güvenlik ve dolandırıcılık izlemesinin dayandığı SIEM/Elasticsearch/Kafka beslemelerinden çıkarır — bunun bir operatör kararı olarak kalması gerekir.

Aynı anahtar uygulamalarda da bulunur; orada uygulamaya bağlı tüm tüketicileri birden kapsar. İkisi birbirinden bağımsızdır ve herhangi biri yeterlidir şeklinde birleşir: bir tüketici, ya kendisi kapatılmışsa ya da uygulaması kapatılmışsa susturulmuş olur. Kaydetmek yeterlidir — tüketici otomatik olarak yeniden dağıtılır, elle yeniden dağıtım (redeploy) GEREKMEZ.

İçe aktarma bu ayarı geri açmaz

Bir paket mevcut bir tüketicinin üzerine yazdığında, burada susturulmuş olan bir tüketici paket aksini söylese bile susturulmuş kalır. Ters yön serbesttir: bir paket loglamayı kapatabilir. Bu asimetri bilinçlidir — bu, hedef kurulumun kendisi hakkında verdiği bir karardır ve içe aktarmanın onu sessizce geri alması doğru değildir.

Tüketici Silme

Bir tüketici, listedeki işlem menüsünden Sil ile kaldırılır; silme öncesinde onay istenir. Tüketiciye tanımlı erişim yetkileri (ACL) silmeyi engellemez — kayıtla birlikte kaldırılır.

Bir tüketici yalnızca aşağıdaki üç durumda silinemez:

• İptal edilmemiş bir API istemcisi taşıyorsa — taslak, aktif ya da askıda en az bir API istemcisi olan tüketici silinemez; istek, bağlı istemcileri Silme Engelleri olarak bildirerek 409 ile reddedilir ve kayda dokunulmaz. Ekrandaki ret mesajı tüketiciyi adıyla anar ve gerçek engeli sayısıyla birlikte yazar (örn. "Bu kayda bağlı, iptal edilmemiş 1 API istemcisi bulunuyor."). Önce istemcileri iptal edin (hiç etkinleştirilmemiş taslakları atın), sonra silin; iptal edilmiş istemciler silmeyi engellemez.

• Bir kimlik sağlayıcısından senkronize edilmişse — Kaynak etiketi Apinizer dışında bir değer taşıyorsa, kayıt hâlâ o kaynağa bağlıyken hiçbir yüzeyden (ekran, Management API veya APIops dahil) elle silinemez; kaldırma kimlik bilgisi senkronizasyonu üzerinden yapılır.

• Aynı kayıt için hâlihazırda başka bir silme işlemi sürüyorsa — istek, kayda dokunmadan 409 ile reddedilir; bkz. Eş Zamanlı Silme.

Bir tüketicinin silinmesi limit atamalarını da sonlandırır. Bu tüketiciyi adlandıran her İstek Hızı ya da AI Token Bütçesi ataması — aktif olanlar da hiç etkinleştirilmemiş taslaklar da — aynı adımda kapatılır, nedeni Öznesi silindi olarak kaydedilir ve tavan dağıtıldığı gateway'lerden çekilir. Atamalar, elle sonlandırdığınız bir atama gibi geçmiş kaydı olarak korunur. Silme yukarıdaki nedenlerden biriyle reddedilirse atamalara dokunulmaz ve uygulanmaya devam eder. Aynısı bir kurum ya da portal uygulaması silindiğinde de geçerlidir. Bkz. Limit Planları ve Atamalar.

bilgi

Kural yalnızca ekranda değil sunucu tarafında da uygulanır: senkron kaynaklı bir tüketici için Management API veya APIops üzerinden gönderilen silme isteği de aynı şekilde reddedilir.

Tüketiciyi Başka Bir Kuruma Taşıma

Bir tüketici, bu ekranda Kurum alanının yanındaki Taşı düğmesiyle aynı projedeki başka bir kuruma taşınabilir; düğme hedef kurumun seçildiği bir pencere açar. Taşınan tüketicinin çalışmaya devam etmesi için gereken her şey otomatik olarak birlikte gider: tüketicinin kendi API istemcileri, ayrılınan kurumu hâlâ taşıyan erişim yetkileri ve tüketiciye üretilmiş token'lar aynı işlemde yeni kuruma bağlanır, tüketici de değişikliğin hemen etkili olması için yeniden dağıtılır. Kota kullanım rakamları taşıma sırasında yeniden yazılmaz — bir sonraki düzenli senkronizasyonda kendiliğinden düzelir.

uyarı

Hedef kurum askıya alınmışsa, taşımadan hemen sonra tüketicinin trafiği durur. Trafiğin yeniden akması için hedef kurumu devam ettirin.

Aşağıdaki durumlarda taşıma reddedilir ve hiçbir şey değişmez:

• tüketici bir dizin senkronizasyonu tarafından yönetiliyorsa — kurumu kaynak sağlayıcıya aittir;
• tüketici için, ya da ayrılınan veya katılınan kurum için hâlihazırda bir silme işlemi sürüyorsa;
• hedef kurum çözümlenemiyorsa, çağıran projenin kapsamında değilse (kabul edilenler: tüketiciyle aynı projenin kurumu ya da kurulum-geneli/admin kapsamlı bir kurum) ya da başka bir kurumla birleştirilmişse;
• hedef kurum, tüketicinin zaten bağlı olduğu kurumsa.

bilgi

Kural yalnızca ekranda değil sunucu tarafında da uygulanır. Management API'ye doğrudan gönderilen bir taşıma isteği; senkron kaynaklı bir tüketici için, çözümlenemeyen ya da başka bir projeye ait bir hedef için, ya da tüketici veya kurumlardan biri için bir silme işlemi sürerken aynı şekilde reddedilir.

API İstemcileri

Bir tüketicinin kullanıcı adı ve parolası, oturum açan bir kişiyi ya da sistemi tanımlar. API istemcisi ise ayrı bir şeydir: o tüketici adına token alan, kendi client kimliğini ve kendi sürümlü client secret'larını taşıyan bir makine kimliğidir. Bir tüketici birden çok API istemcisi taşıyabilir — entegrasyon başına, ortam başına ya da ekip başına — ve her biri, tüketiciye ve diğer istemcilere dokunulmadan tek başına kullanımdan kaldırılabilir.

API istemcileri, tüketicinin hem görüntüleme hem düzenleme ekranındaki API İstemcileri sekmesinden yönetilir. Bir API istemcisi kendine ait bir sayfada düzenlenmez: listedeki satır bir özettir, açılan satır ise Genel Bakış, Client Secrets, Yetkilendirme, Kimlik ya da AI bütçelerini görme yetkisi olan kullanıcılar için ayrıca Limitler ve Aktivite alt sekmelerini taşıyan editörün kendisidir.

API İstemcileri sekmesi

Tüketicinin kendi düzenleme ekranındaki Limitler sekmesi ise buradan ayrıdır: burada tanımlanan atama yalnızca o tüketiciye ve ona bağlı istemcilerin ortak tüketimine bir tavan atar, başka hiçbir tüketiciyi etkilemez — bkz. Limit Planları → Kapsam.

Canlı trafik

Bir API istemcisi token alabilir ve bunu kullanarak doğrudan bir API Proxy'yi çağırabilir — gateway artık bunu kapıda durdurmaz. İstemcinin fiilen neye erişebileceğine yetkilendirme karar verir: sahibinin kendi erişimi, istemcinin kendi kısıtıyla daraltılmış hâli — ve bu ilişkinin iki tarafının da o an canlı olması gerekir, bkz. Sahip ve İstemci Yaşam Döngüsü.

API İstemcisi Oluşturma: Önce Taslak, Sonra Etkinleştirme

Oluşturma bilinçli olarak iki adımdır.

1. İstemci taslak olarak oluşturulur. Bu anda hiçbir secret taşımaz — bu, kapatılabilecek bir varsayılan değil, yapısal bir yokluktur. Client kimliği ya Apinizer tarafından üretilir ya da elle girilir (4-128 karakter; harf, rakam ve . _ : @ ~ -). Oluşturma anında sabitlenir: ne client kimliği ne de yönetim anahtarı (istemci detayında Yönetim Anahtarı olarak görüntülenir — bkz. Yönetim Anahtarı, Hiyerarşi ve Üst Kayıt Durumu) sonradan değiştirilebilir, çünkü üretilmiş token'lar ve kurulum genelindeki client kimliği kayıt defteri bunlara bağlıdır.
2. İstemci etkinleştirilir. İstemci kullanılabilir bir kimlik doğrulama materyali taşımıyorken etkinleştirme reddedilir — client secret'ı olmayan bir taslak etkin duruma geçemez. İlk secret'ı Client Secrets alt sekmesinden üretin, sonra etkinleştirin.

Hiç etkinleştirilmemiş bir taslak atılabilir. Bu, client kimliğini serbest bırakmaz: kimlik, kurulum genelindeki kayıt defterinde emekliye ayrılır ve bir daha atanamaz — bir client kimliğini kalıcı bir ad yapan şey, yeniden kullanılmamasıdır. Burada sunulan tek silme işlemi budur; kullanıma girmiş bir istemci silinmez — askıya alınır ya da iptal edilir.

Kimlik çakışması

Bir tüketicinin kullanıcı adı ile bir API istemcisinin client kimliği aynı değerde olamaz. Bu, iki farklı ekranda ayrı ayrı oluşturulduğu için oluşturma anında uyarılmaz; çakışma ortama yüklenirken (deploy) fark edilir ve çakışan taraflardan ortama daha sonra ulaşan yüklenmez — hangi kaydın önce oluşturulduğu değil, hangisinin deploy sırasını kaybettiği belirleyicidir (bir worker yeniden başladığında tüketiciler API istemcilerinden önce yüklenir, bu nedenle bu senaryoda kaybeden taraf her zaman API istemcisidir). Kaybeden kayıt üzerinden token isteği karşılanamaz hale gelir. Ret, POLICY_AUTH_IDENTITY_AMBIGUOUS koduyla (bkz. Hata Mesajları) günlüğe düşer; çakışmayan taraf etkilenmez. Bir client kimliği seçerken kurulumdaki mevcut tüketici kullanıcı adlarıyla çakışmadığından emin olun.

Yönetim Anahtarı, Hiyerarşi ve Üst Kayıt Durumu

İstemci detayının kimlik başlığında, client kimliğinin yanında bir Yönetim Anahtarı satırı bulunur. Üzerine gelindiğinde, bu değerin yalnızca yönetim API'sini ve bu ekranı adreslediğini, gateway kimlik doğrulamasında hiçbir zaman kullanılmadığını hatırlatan bir açıklama görüntülenir — gateway her zaman client kimliği ve client secret ile kimlik doğrular. Client kimliği satırındaki gibi, yönetim anahtarının yanında da tek tıkla kopyalama simgesi bulunur.

Başlığın hemen altındaki bilgi kutusu bu ayrımı üç satırda özetler:

• Gateway çağrıları client kimliği ve client secret ile kimlik doğrular.
• Yönetim Anahtarı yalnızca yönetim API'sini ve bu ekranı adresler; kimlik doğrulamada rol oynamaz.
• Client secret yalnızca üretildiği anda görünür; sonrasında ancak denetim kaydına yazılan bir gösterimle erişilebilir.

Sahiplik Zinciri paneli — varsayılan olarak kapalı, tıklanarak açılır — istemcinin bağlı olduğu Organizasyon → Sahip → Bu API İstemcisi hiyerarşisini adım adım gösterir; sahip bir tüketiciyse Tüketici, bir portal uygulamasıysa Uygulama olarak etiketlenir. Panel yalnızca ekranda zaten yüklü olan bilgileri gösterir, ek bir sorgu tetiklemez; organizasyon ya da sahip seviyesinde bir ad bulunmuyorsa o seviye kimlik değeriyle gösterilir.

İstemcinin kendi durumu (Etkin/Hazır) uygun olsa bile, bağlı olduğu bir üst kayıt (örneğin askıya alınmış bir sahip ya da çözülmemiş bir bağımlılık) yüzünden fiilen etkisiz kalabilir — bkz. Sahip ve İstemci Yaşam Döngüsü. Bu durum, istemcinin hazırlık rozetinin yanında "Üst kayıt nedeniyle etkisiz" uyarı rozetiyle ayrıca işaretlenir; rozetin üzerine gelindiğinde zincirdeki hangi kaydın çözülemediği açıklanır.

Client Secret Yalnızca Bir Kez Gösterilir

Client secret, onu üreten ya da döndüren yanıtta bir kez gösterilir. Değeri o anda kopyalayın. Sonrasında değer ne listeden, ne istemci detayından, ne de Management API'den okunabilir — bunların hiçbiri secret materyali döndürmez.

Client Secrets alt sekmesi

Değere yeniden ihtiyaç duyulduğunda tek yol Göster (Reveal)'dir: yönetme yetkisi ister, yazılı bir gerekçe ister ve istemciyi, secret sürümünü ve gerekçeyi taşıyan bir denetim kaydı yazar — değeri asla.

Döndürme (rotate) yeni bir secret üretir ve öncekini bir geçiş süresi boyunca çalışır bırakır; böylece entegrasyonlar kesintisiz geçiş yapabilir. Geçiş süresinin nasıl kapandığı ve ileri tarihe planlanmış bir döndürmenin nasıl devreye girdiği için bkz. Bakım Görevi. Elle girilen bir secret için en az 32 karakter önerilir; daha kısa bir değer yine de kabul edilir ve ekranda bir uyarı gösterilir — yalnızca boş bir değer reddedilir.

Bir istemci en fazla 5 secret sürümü taşır. Sınıra ulaşıldığında yol, artık gerekmeyen bir sürümü iptal etmektir — bkz. Tek Bir Secret Sürümünü İptal Etme.

Secret Saklama Modu

Bir secret kuşağı, üretildiği ya da döndürüldüğü anda sabitlenen iki moddan birinde saklanır:

Mod	Davranış
Encrypted (Varsayılan)	Yeniden gösterilebilecek bir biçimde saklanır: platform tarafından şifrelenmiş bir kopya her zaman tutulur, kurulumda bir kurtarma anahtarı yapılandırılmışsa buna ek olarak KEK ile mühürlenmiş bir kurtarma zarfı da tutulur. Kurtarma anahtarı olsun ya da olmasın gösterilebilir.
Hashed	Yalnızca tek yönlü bir doğrulayıcı saklanır — kurtarma anahtarı var olsa bile geri döndürülebilir hiçbir kopya hiçbir yerde tutulmaz. Bu biçimde saklanan bir kuşak için Göster kalıcı olarak kullanılamaz hale gelir; secret'ın tek görünme anı üretildiği ya da döndürüldüğü andır.

Doğrulama her iki modda da aynı şekilde çalışır ve moddan bağımsızdır: sunulan bir secret, iki modda da kendi doğrulayıcısına karşı kontrol edilir. Mod yalnızca yanında geri döndürülebilir bir kopyanın tutulup tutulmayacağına karar verir.

Client Secrets alt sekmesindeki üretme/döndürme diyaloğu bu seçimi doğrudan sunar: bir Saklama Modu kontrolü, üretilecek kuşak için Encrypted veya Hashed seçilmesini sağlar. Bu kontrol kurulumun varsayılanıyla önceden seçili gelir — bu varsayılan ve nasıl değiştirileceği için bkz. API İstemcisi Secret Saklama Ayarları — diyalogda değiştirmek yalnızca üretilmekte olan o kuşağı etkiler. Var olan her kuşağın modu, secret kuşakları tablosundaki Saklama sütununda gösterilir.

not

Bir kuşağın gösterilebilir olup olmadığını, kurulumda kurtarma anahtarı bulunup bulunmaması değil, kuşağın saklama modu belirler: Encrypted bir kuşak, kurtarma anahtarı olsun ya da olmasın gösterilebilir; Hashed bir kuşak ise hiçbir kurulumda hiçbir zaman gösterilemez — bu bir arıza değil, Hashed seçiminin üretim/döndürme anında yaptığı bilinçli tasarımdır. Yeni bir değer için secret'ı döndürün. Aynı durum, iptal edilirken değeri imha edilmiş bir secret için de geçerlidir.

uyarı

Göster işleminin hız sınırı best-effort'tur: aynı anda gelen iki gösterim isteği ikisi birden geçebilir. Asıl sınır sayaç değil; yönetme yetkisi, zorunlu gerekçe ve denetim kaydıdır.

Askıya Alma, Devam Ettirme ve İptal Etme

Kullanıma girmiş bir istemcinin yaşam döngüsü üç işlemle yönetilir; üçü de istemcinin işlem menüsünden yapılır ve bir onay penceresiyle teyit edilir:

• Askıya Al (Suspend) istemciyi duraklatır: istemci token alamaz ve canlı istekleri reddedilir. Hiçbir şey yok edilmez — secret sürümlerine ve daha önce verilmiş token'lara dokunulmaz; aşağıdaki iptal kesim noktası da ileri alınmaz, çünkü kesim noktası bir andır ve bir devam ettirme onu geri saramaz.
• Devam Ettir (Resume) duraklatılanı aynen geri verir: istemci, askıya alınmadan önce hangi secret'ları ve token'ları taşıyorsa onlarla döner. Süresi henüz dolmamış bir token, askı boyunca kapıda reddedilirken devam ettirme sonrasında yeniden çalışır — yeni token almak ya da secret üretmek gerekmez.
• İptal Et (Revoke) kalıcıdır ve geri alınamaz: istemcinin tüm secret sürümlerinin materyali kalıcı olarak imha edilir — değerler yalnızca devre dışı kalmaz, geri getirilemez biçimde yok edilir. Verilmiş token'lar da tipine göre iki bağımsız katmanla öldürülür: açık (opaque) token'lar depodan doğrudan silinir; JWT'ler durumsuz (stateless) olduğu için silinemez, bunun yerine iptal anı istemciye bir kesim noktası (cutoff) olarak damgalanır ve bu andan önce üretilmiş her JWT — süresi henüz dolmamış olsa bile — sonraki her doğrulamada reddedilir. Client kimliği kurulum genelindeki kayıt defterinde emekli kalır: bir daha hiçbir istemciye verilmez. İptal edilmiş bir istemci devam ettirilemez ve yeniden etkinleştirilemez; aynı entegrasyonun sürmesi gerekiyorsa yeni bir client kimliğiyle yeni bir istemci oluşturulur. İptal edilmiş bir istemciye yeni bir secret da verilemez — deneme 400 ile reddedilir. Bu kesim noktası yalnızca bir API istemcisi kaydı taşıyan token'larda çalışır; bunun kapsamadığı eski akışlar ve onlar için isteğe bağlı ek koruma için bkz. Token İptali Katılık Ayarı.

Askıya alırken ve iptal ederken yazdığınız gerekçe, denetim amacıyla istemcinin yaşam döngüsü geçmişine kaydedilir; devam ettirme gerekçe istemez.

Geçişler katıdır ve sunucu tarafından doğrulanır:

• Bir taslak askıya alınamaz ve iptal edilemez — hiç etkinleştirilmemiş bir taslak yalnızca atılır.
• Zaten askıda olan bir istemciyi tekrar askıya almak (ya da zaten aktif bir istemciyi devam ettirmek) sessizce kabul edilmez; istek geçersiz bir durum geçişi olarak reddedilir.
• Her işlem, istemcinin sizin ekranınızda gördüğünüz haline karşı gönderilir: bu sırada istemci başka biri tarafından değiştirilmişse istek bir çakışma hatasıyla reddedilir — listeyi yenileyip işlemi güncel durum üzerinde tekrarlayın.

Tek Bir Secret Sürümünü İptal Etme

Bir secret değerinin sızdığından şüpheleniyorsanız istemcinin tamamını iptal etmeniz gerekmez: Client Secrets alt sekmesinden yalnızca şüpheli sürümü iptal edebilirsiniz. Sürüm iptali anında ve kalıcıdır — sürümün materyali imha edilir ve bir daha doğrulamada kabul edilmez.

Bu işlem bir sızıntı senaryosu için tasarlandığından, istemcinin o ana kadar almış olduğu tüm açık (opaque) token'lar da güvenlik gereği birlikte silinir — yalnızca iptal edilen sürümle alınanlar değil, istemcinin diğer geçerli secret'larıyla alınmış olanlar da. Token'ını kaybeden bir makine istemcisi bir sonraki isteğinde geçerli bir secret'la yeniden token alır; buradaki kısa kesinti, sızıntı senaryosunda istenen etkidir.

Bu, halihazırda üretilmiş bir JWT'ye ulaşmaz

Tek bir secret sürümünü iptal etmek istemcinin iptal kesim noktasını damgalamaz. JWT hiçbir zaman depoda saklanmaz; bu yüzden bu işlemin silecek bir satırı da yoktur — artık ölü sayılan secret ile önceden alınmış bir JWT, kendi süresi dolana kadar doğrulanmaya devam eder. Halihazırda üretilmiş bir JWT'yi kesin olarak öldürmek, kesim noktasını damgalayan tam bir istemci İptal Et (Revoke) işlemini gerektirir.

Aktif sürümü iptal etmek kesinti yaratır

Aktif secret sürümünü iptal etmek istemciyi kullanılabilir secret'sız bırakır: yeni bir secret üretilene kadar istemcinin kimlik doğrulaması durur ve onay penceresi bu kesintiyi açıkça belirtir. Sızmış bir secret'ı hemen öldürebilmek için bu bilinçli bir bedeldir; kesintisiz geçiş gereken olağan yenilemede bunun yerine döndürmeyi (rotate) kullanın.

Bakım Görevi: Geçiş Süresi ve Planlı Döndürme

Saatlik çalışan bir bakım görevi iki işi kendiliğinden yürütür:

• Geçiş süresi gerçekten kapanır. Döndürme sonrasında eski sürüme tanınan geçiş süresi dolduğunda, o sürümün materyali görev tarafından kalıcı olarak imha edilir: süresi dolmuş sürüm yalnızca doğrulamada reddedilmekle kalmaz, değeri de geri getirilemez biçimde yok edilir. Bu temizlik bir hijyen işlemidir ve istemcinin token'larına dokunmaz — token silme yalnızca yukarıdaki elle iptal yollarında uygulanır.
• İleri tarihli döndürme kendiliğinden devreye girer. Planlanan an geldiğinde bekleyen sürüm görev tarafından aktifleştirilir ve o ana kadarki aktif sürüm geçiş süresine alınır. Görev saatlik çalıştığı için devreye girme, planlanan anın en fazla bir saat kadar sonrasına sarkabilir.

API İstemcisinin Yetkilendirilmesi

Bir API istemcisi sahibinden fazlasına asla erişemez. Gelen her canlı istekte gateway bir kesişim hesaplar: sahibin — tüketicinin ya da uygulamanın — sahip olduğu yetki, bu tek istemci için Yetkilendirme alt sekmesinin izin verdiğiyle daraltılır. Önce sahip tarafı kontrol edilir: sahibin kendisine bir hedef hiç verilmemişse istemcinin kendi modu hiç değerlendirilmez ve hiçbir istemci-taraflı ayar, sahibinin sahip olmadığı bir hedefe ulaşamaz.

Yetkilendirme alt sekmesi

Mod	Anlamı
Sahibini izle	İstemci, sahibinin eriştiği her şeye erişir. Bir tüketiciye ait istemcinin varsayılanıdır; böylece davranış, düz bir tüketicinin zaten sahip olduğu davranışla eşleşir.
Tümünü reddet	Sahibi ne taşırsa taşısın, istemci hiçbir şeye erişemez. Bir uygulamaya ait istemcinin varsayılanıdır.
Alt kümeye izin ver	İstemci yalnızca bu sekmede adı geçen hedeflere erişir — ve yalnızca sahibinin zaten sahip olduklarına.

Burada satır olmaması "kısıt yok" demek değildir

İstemcinin bu sekmede etkin bir satırı yokken yukarıdaki geçerli mod sahibinin türüne göre belirlenir — hiçbir zaman kısıtsız olarak okunmaz:

• Bir tüketiciye ait istemci varsayılan olarak Sahibini izle moduna düşer; bu, o tüketicinin kendi erişiminin zaten davrandığı biçimle aynıdır.
• Bir uygulamaya ait istemci varsayılan olarak Tümünü reddet moduna düşer. Bu kolayca gözden kaçar: yeni oluşturulmuş, uygulamaya ait bir istemci, burada bir hedef adlandırılana kadar her canlı isteği reddeder — uygulamanın kendisi Erişim sekmesinde zaten geniş bir erişime sahip olsa bile.

Sahibine verilmemiş bir hedefe burada izin verilemez; sunucu bunu reddeder. Bir hedefi tek ortama daraltmak bir daraltmadır ve kabul edilir; tersi — sahibi tek ortama daraltılmışken istemcinin tüm API Proxy'yi istemesi — bir genişletmedir ve reddedilir.

Modun değiştirilmesi mevcut satırı düzenlemez: o satır sonlandırılır ve yerine yenisi yazılır; böylece istemcinin nelere erişebildiğinin kaydı korunur.

Bu karar, bütün bir API Proxy ya da API Proxy grubu seviyesinde verilir; bir tüketicinin metod bazlı İzin Verilmeyen Metodlar ayarının bu sürümde bir API istemcisi için karşılığı yoktur.

Sahip ve İstemci Yaşam Döngüsü

Bir hedef için yetkili olmak tek başına yeterli değildir. Bu kesişim daha değerlendirilmeden önce, bir API Proxy'ye yapılan istek ilişkinin her iki tarafının da o an canlı olduğunu denetler; bu iki denetim ayrı nedenlerle ve ayrı hata kodlarıyla reddedilir:

• İstemcinin kendisi Aktif ve Hazır olmalıdır — bir Taslak, Askıya Alınmış ya da İptal Edilmiş istemci reddedilir; hâlâ Secret Bekliyor durumunda olan ya da Çözülmemiş Bağımlılık taşıyan bir istemci de aynı şekilde reddedilir. Bu durumdaki ret, devre dışı bırakılmış bir tüketicide de kullanılan aynı genel kodla, POLICY_AUTH_USERNOTEXISTS ile düşer. Genel Bakış sekmesinde ayarlanan Valid From / Expires At penceresinin de o an geçerli olması gerekir; pencere dışına çıkılmışsa ret bunun yerine POLICY_AUTH_CREDENTIAL_EXPIRED ile düşer.
• Sahip zinciri o an canlı olmalıdır — ve zincir, sahibin kurumuna kadar uzanır. Bir tüketiciye ait istemci, o tüketici devre dışıyken reddedilir; bir uygulamaya ait istemci, uygulama askıya alınmışken reddedilir; sahibin bağlı olduğu kurum askıya alınmışsa, kurumun uygulamalarına ait istemciler de — uygulamanın ve istemcinin kendi durumu ne olursa olsun — reddedilir. Bu durumların hepsinde ret POLICY_AUTH_CREDENTIAL_PROXYNOTALLOWED ile düşer — sahip zinciri canlı değilken istemcinin kendi yetkilendirme modu hiç değerlendirilmez.

Sahip zinciri denetimi yalnızca canlı API Proxy çağrısında değil, token uç noktasında da uygulanır: sahibi ya da kurumu canlı olmayan bir istemcinin token isteği de reddedilir. Aynı kapı, çağıran istemciyi aynı şekilde doğrulayan token introspection ve iptal (RFC 7009 revocation) uç noktalarının da önündedir: sahip zinciri canlı değilken bir istemci kendi token'ını sorgulayamaz ve iptal edemez. Sahibi devre dışı bırakmak ya da askıya almak, bu yüzden altındaki tüm istemcileri — token almaları da dahil — tek tek dokunmadan aynı anda kesmenin en hızlı yoludur.

Kurum tüketici iptali askıyı ne kaldırır ne koyar

Bir kurumun tüketicilerini iptal etmek (revoke), kurum üzerindeki bir askıdan bağımsız, tüketicilere dönük bir işlemdir. Askıya alınmış bir kurumun tüketicileri iptal edildiğinde kurum askıda kalır ve uygulamalarına ait istemciler reddedilmeye devam eder; askıyı kaldırmanın tek kapısı kurumu açıkça devam ettirmektir (Resume) — devam ettirme de iptal edilmiş hiçbir tüketiciyi geri getirmez, iptal tüketiciler için kalıcıdır. Aynı şekilde iptal, askı da koymaz: askıda olmayan bir kurumun tüketicileri iptal edildiğinde kurumun uygulamalarına ait istemciler duraklatılmaz — onlar uygulamanın kendi durumuna tabi kalır; ölen yalnızca kurumun tüketicileri ve onlara bağlı istemcilerdir. "Ölen" burada somut bir kapsam taşır: kurumun kendi tüketicilerine bağlı API istemcilerinin açık (opaque) token'ları depodan hemen silinir. Buna ek olarak kurumun alt ağacındaki tüm API istemcilerine — kendi tüketicileri bu işlemle iptal edilmemiş olsa bile — yukarıdaki iptal kesim noktası damgalanır; bu andan önce üretilmiş bir JWT de sonraki doğrulamada reddedilir, ve alt ağaçtaki bu istemcilerin depoda kalan eski (kesim noktası öncesi) token satırları da arka planda temizlenir. Bkz. Portal Organizasyonları.

API İstemcisi ile Token Alma (Client Credentials)

Bir API istemcisinin client kimliği ve client secret'ı, bir JWT ya da OAuth2 Authentication politikası "ACL'den Yönet (Manage From ACL)" olarak ayarlandığında açılan jenerik token uç noktasından (/credential/token ya da /credential/jwt) token almak için kullanılabilir — tıpkı bir tüketicinin client kimliği/secret'ı gibi. Uç nokta seçimi ve istek biçimi Token Alma Yöntemleri — "ACL'den Yönet" bölümü ile birebirdir; oradaki tablolarda client_id ve client_secret olarak geçen değerler, API istemcisi için sırasıyla client kimliği ve Client Secrets alt sekmesinden üretilmiş secret'tır.

Bir API istemcisiyle token almanın tüketiciden ayrıldığı noktalar şunlardır:

• Yalnızca iki grant type: bir API istemcisi bu sürümde yalnızca client_credentials ve refresh_token ile token alabilir. password grant type desteklenmez — bir API istemcisinin client kimliği bir PASSWORD isteğinde username olarak gönderilirse token reddedilir; bir API istemcisi hiçbir zaman bir PASSWORD grant'inin sahibi (resource owner) olamaz. Bu kalıcı bir kısıttır, kapatılabilecek bir seçenek değildir; Management API üzerinden bir API istemcisine password grant'i tanımlamaya çalışan bir yapılandırma isteği de aynı nedenle reddedilir.
• Token yenileme varsayılan olarak kapalıdır: yeni oluşturulan bir API istemcisinde token yenileme (refresh_token) özelliği varsayılan olarak kapalı gelir. Bu, yalnızca API istemcilerini etkiler; mevcut tüketicilerin Token Ayarları'ndaki mevcut varsayılanı değişmez.
• Tüketicinin kendi API istemcisi tüketicinin Token Ayarları'na uyar: bir tüketici için otomatik oluşturulan API istemcisinin kendine ait token ayarı yoktur; tüketicinin Token Ayarları sekmesinde kaydedilen token süresi, ölümsüz token ve yenileme ayarları, bu istemcinin /credential/token ve /credential/jwt üzerinden aldığı token'lara — istemci var olmadan önce olduğu gibi — aynen uygulanır. Yalnızca Management API üzerinden kendine token ayarı verilmiş bir API istemcisi onları kullanır ve bunu bir bütün olarak yapar: tüketicinin değerleri bunlara hiçbir zaman karıştırılmaz. Token istemci üzerinden alındığı için tüketicinin Token Yenileme İzni (Refresh Token Allowed) ayarı da canlı okunur: kapatılması, o tüketicinin bir sonraki yenileme isteğinde hemen etkili olur.
• Bir uygulamaya ait API istemcisine süre vermediğiniz sürece token'ı ölümsüzdür: sahibi bir tüketici değil bir uygulama olan istemcinin — yaygın örneği API Portal üzerinden verilenlerdir — arkasında tüketiciye ait bir Token Ayarları sekmesi yoktur ve portal istemciyi verirken token ayarı sormaz. Böyle bir istemci, token ayarları hiç doldurulmamış bir tüketiciyle aynı şekilde değerlendirilir: token'ı süresiz olur ve yenileme token'ı üretilmez. Yanıtta bu, expires_in: 0 ile birlikte X-IssuedAt ve X-ExpiresAt alanlarının hiç bulunmaması şeklinde görünür — bu birleşim "süre yok" anlamına gelir ve token geçerli kalır. Gerçek bir süre ya da yenileme yeteneği vermek için o API istemcisinin token ayarlarını Management API üzerinden tanımlayın; kendine ait ayarı olan istemci bu ayarları bir bütün olarak kullanır.
• Token yenileme ayarı canlı okunur: bir API istemcisinin yenileme iznini sonradan açıp kapatmanız, o istemcinin token'ı üzerinden yapılacak bir sonraki yenileme isteğinde hemen etkili olur — token, ilk verildiği andaki değere kilitlenmez. Bu canlı okuma yalnızca bir API istemcisi üzerinden alınmış token'lar içindir; klasik tüketici (consumer) yoluyla alınmış token'larda ayar, token'ın verildiği andaki değere donmuş kalmaya devam eder (davranış değişmedi).
• expires_in her zaman saniyedir: bir API istemcisine verilen token'ın yanıtındaki expires_in alanı, kurulumun Token Yönetim Ayarları sayfasındaki "expires_in Değerini Saniye Olarak Dön" ayarından bağımsız olarak her zaman saniye cinsindendir. Mevcut tüketicilerle alınan token'lar bu ayarın kurulumdaki mevcut haline (varsayılan: milisaniye) tabi olmaya devam eder — o ayarın varsayılanı bu davranış için değiştirilmemiştir.
• Scope her zaman boş döner: bir API istemcisinin henüz kendine ait bir rol/scope kaynağı yoktur; bu nedenle bir API istemcisiyle alınan token'da scope alanı istek scope talep etse bile boş döner. Token Yönetim Ayarları sayfasındaki Principal'ın Rolü Yoksa Reddet ayarı açıksa, scope talep eden bir API istemcisi isteği HTTP 400 invalid_scope ile reddedilir; kapalıysa (varsayılan) scope'suz token verilir.
• Basic / Base64 / Digest ile kullanılamaz: bu politikalar bir parola karşılaştırması bekler; bir API istemcisinin parolası bu politikalar için her zaman boş kabul edilir ve istek bu sürümde reddedilir. Basic ve Base64 desteği ileri bir sürüme bırakılmıştır. Digest tarafındaki kısıt saklama moduna göre değişir: Hashed bir kuşakta Digest'in beklediği parolayı yeniden hesaplayacak hiçbir malzeme yoktur ve bu kalıcıdır; Encrypted bir kuşak (bkz. Secret Saklama Modu) Digest'in ihtiyaç duyacağı geri döndürülebilir kopyayı taşır — yine de bu sürümde API istemcileri için Digest desteği saklama modundan bağımsız olarak devreye alınmamıştır.
• Sözleşme (Contract) süresine tabi değildir: bir tüketicinin sözleşme süresi dolduğunda o tüketici token alamaz hale gelir; bir API istemcisi için böyle bir bağ yoktur — geçerlilik yalnızca istemcinin kendi validFrom/expiresAt penceresiyle yönetilir.

API Proxy'ye Erişim

Bir token verildikten sonra bunun bir API Proxy'ye karşı fiilen kullanılıp kullanılamayacağına tamamen yukarıdaki API İstemcisinin Yetkilendirilmesi ve Sahip ve İstemci Yaşam Döngüsü bölümleri karar verir — token uç noktası hedef bazlı yetkilendirmeyi hiç değerlendirmez; değerlendirdiği tek yaşam döngüsü denetimi sahip zinciridir (sahibi ya da kurumu canlı olmayan bir istemci token da alamaz). Reddedilen bir canlı istek, nedenine göre farklı bir kodla düşer (bkz. Hata Mesajları): istemcinin kendisi Aktif+Hazır değilse ya da kendi geçerlilik penceresi dışındaysa sırasıyla POLICY_AUTH_USERNOTEXISTS ya da POLICY_AUTH_CREDENTIAL_EXPIRED ile; sahip devre dışı/askıdaysa ya da tipli yetkilendirme (eksik yetki, varsayılan Tümünü reddet ya da alt küme eşleşmemesi) isteği reddederse POLICY_AUTH_CREDENTIAL_PROXYNOTALLOWED ile.

Eski Kayıtlar: Otomatik Taşıma

Bugün makine istemcisi olarak kullanılan tüketiciler artık otomatik olarak typed API istemcilerine dönüştürülür — bunun için bir ekran, düğme ya da elle çalıştırılan bir adım yoktur. Dönüşüm, Manager bu sürümle ilk açıldığında kurulum genelinde çalışır (aşağıda Yükseltmede Otomatik Taşıma), yakınsamayan her şeyi günlük bir görev yeniden dener ve bundan sonra oluşturulan ya da düzenlenen bir tüketici aynı adımlardan kaydedilirken geçer (Oluşturulduğunda ve Kaydedildiğinde Taşınır). Aşağıda taşımanın neye karar verdiği, neyi taşıdığı ve neye dokunmadığı anlatılır.

Karar Değerleri

Her eski kayıt üç karardan birini alır. Karar ayrıca taşımanın kayıt defterine de yazılır; böylece bir operatör belirli bir kaydın neden dönüştürüldüğünü ya da dönüştürülmediğini okuyabilir.

Karar	Anlamı
Geçir	Kayıt bir API istemcisine dönüştürülür. Çözülemeyen bir erişim kuralı (örn. artık var olmayan bir API Proxy) bunu durdurmaz: o kural atlanır ve raporlanır, kaydın geri kalanı yine de taşınır. Kaydın sahibi olan uygulama da çözülemiyorsa istemci bunun yerine tüketici-sahipli olarak türetilir (Belirsiz sahip). HTTP Digest ya da mTLS politikasıyla erişilen bir kayıt da aynı şekilde taşınır ve bilgi amaçlı bir not taşır (HTTP Digest ile erişiliyor, mTLS ile erişiliyor); Digest ile erişilen bir kayıt, taşınan kuşağın şifreli platform kopyasından servis edilir.
Yalnız Consumer	Kayıt bir tüketici olarak kalır; kendi başına doğrulayacak hiçbir şeyi olmayacağı için bu kayıt için API istemcisi türetilmez. Bu; dış bir kimlik kaynağıyla (LDAP, veritabanı, bir API) doğrulanan bir kaydı, bir kimlik sağlayıcı claim'iyle eşleşen bir kaydı (IdP eşleşmeli kimlik), kullanılabilir saklı parolası olmayan bir kaydı ve aynı kullanıcı adını taşıyan kayıtlardan en eskisi dışındaki her birini (Client id çakışması) kapsar. Bu bir uyarı değildir — kayıt eskisi gibi çalışmaya devam eder.
Engelli	Kaydın kullanıcı adı yok, dolayısıyla taşınacak bir kimlik yok. Bir kaydın taşınmasını bütünüyle durduran tek durum budur — kayda bir kullanıcı adı verilene kadar; verildiği anda kayıt, kaydedilirken taşınır.

Taşıma, bir kaydın yalnızca erişim eksenini taşır, başka hiçbir şeyi değil. Eski erişim listelerine dokunulmaz ve kaydın diğer limitleri olduğu yerde kalır — AI token bütçesi hariç: o, yükseltmede ayrı olarak typed bir atamaya taşınır, bkz. AI Bütçeleri. Portal abonelikleri tarafından üretilen erişim satırları hariç tutulur ve bu şekilde raporlanır: onları abonelik yaşam döngüsü üretir ve kaldırır; materyalize edilmeleri aynı erişim için ikinci bir otorite yaratırdı.

Eski kimlik bilgisinin parolası bir kez okunur ve türetilen istemcinin ilk secret'ı olarak saklanır, istemci de aktifleştirilir: müşterinin bugün zaten kullandığı aynı client id ve aynı parola, artık yeni istemci üzerinden, zorla bir sıfırlama olmadan ve müşteri hiçbir şey fark etmeden kimlik doğrulamaya devam eder. Eski kimlik bilgisi kaydının kendisi bu işlemle hiç değiştirilmez ve bundan önce ya da sonra verilmiş her token kendi süresi dolana kadar çalışmaya devam eder — taşıma hiçbir şeyi iptal (revoke) etmez. Bir değişken ya da ifade referansı olarak saklanan bir parola (${ ya da #{ ile başlayan bir değer) bir secret reference kuşağı olarak taşınır ve ağ geçidi bunu, eski alanı çözdüğü gibi, her istekte yeniden çözer. Taşınan bir secret her zaman Encrypted modda saklanır; bu yüzden kurulumda kurtarma anahtarı yapılandırılmamış olsa bile gösterilebilir kalır. Bu andan itibaren eski kaydın düzenleme ekranında kullanıcı adı ve parola alanları artık gösterilmez; yerine client id görüntülenir ve secret, API Clients sekmesinden döndürülür — bkz. Göç Etmiş Kayıtlarda Client ID ve Client Secret Tüketici Ekranından Kalkar. Taşımanın kayıt bazındaki sonuçları (Carried, Carried as-is, Carried as variable reference, Skipped — blank secret, …) bu adımın script'lenebilir hâliyle birlikte API İstemcisi Secret Taşıma sayfasında listelenir.

Taşınmış bir istemcinin AI Model Erişimi kısıtı değişmeden çalışmaya devam eder: bu kısıt istemciye kopyalanmaz, taşımanın koruduğu bağ üzerinden eski tüketici kaydına bağlı kalmaya devam eder. AI token bütçesi ise artık typed bir atamadır: taşınmış istemci, eski kimlik bilgisinin kullandığı aynı sayaç havuzunda kalmaya devam eder — sayaç sıfırlanmaz. Hiç taşınmamış (native) bir API istemcisinin de kendi typed AI Token Bütçesi ataması olabilir; bu, AI Gateway'in kendi kiracı ve kurulum geneli bütçeleriyle aynı sayaç ve pencerede birleştirilir — ikisinin daha sıkı olanı uygulanır.

bilgi

Yerel bir parolayla doğrulanan her kayıt taşınır. Dış bir kimlik kaynağı üzerinden doğrulanan, dış bir kimlik sağlayıcının claim'iyle eşleşen ya da saklı bir parolası olmayan bir kayıt ise tüketici olarak kalır — bunun için bir API istemcisi türetilmez — ve değişmeden çalışmaya devam eder.

Oluşturulduğunda ve Kaydedildiğinde Taşınır

Bu sürümden sonra oluşturulan bir tüketici — bu ekrandan, portaldan, APIops üzerinden ya da CSV içe aktarma ile — dış bir kimlik kaynağı yerine yerel bir parolayla doğrulanıyorsa, oluşturulduğu anda aynı üç adımdan otomatik olarak geçer: sınıflandırılır, API istemcisi türetilir, eski parola istemciye taşınır ve istemci aktifleştirilir. Operatörün bir şey yapması gerekmez; türetilen istemci tüketicinin kendi API Clients sekmesinde hemen görünür.

Aynısı, henüz taşınmamış var olan bir tüketicinin her kaydedilişinde de olur. Yükseltmenin o an taşınabilir olmadığı için dokunmadan bıraktığı bir eski kayıt — kullanıcı adı olmadığı için Engelli, ya da saklı bir parolası olmadığı için Yalnız Consumer — eksik alan doldurulup kaydedildiği anda dönüştürülür. Zaten taşınmış bir tüketici, ya da Yalnız Consumer olarak kalan bir tüketici, bu kontrolden hiç etkilenmez; sıradan bir düzenlemede bir maliyeti yoktur.

Taşınması gereken bir tüketici için bu üç adımdan biri başarısız olursa, tüketici bu özellik hiç var olmamış gibi çalışmaya devam eder ve aşağıda anlatılan günlük reconcile görevi bunu tamamlar. Dizin ya da veritabanı senkronizasyonuyla yazılan kayıtlar bu adıma hiç girmez — bunlar yapıları gereği dış bir kimlik kaynağı taşır, dolayısıyla onlar için de zaten hiçbir şey türetilmez.

Yükseltmede Otomatik Taşıma

Operatör müdahalesi gerekmez

Aşağıdaki adımlar, Manager bu sürümle ilk açıldığında — istek kabul etmeye başlamadan önce — otomatik olarak, sırayla ve bir kez çalışır. Bunu tetikleyen bir ekran, düğme ya da elle çalıştırılan bir adım yoktur.

Her adım kayıt başına hata-toleranslıdır (bozuk tek bir kayıt adımı durdurmaz), idempotenttir (ikinci bir koşu sıfır yeni satır ekler) ve gateway'e hiçbir zaman senkron bir push yapmaz: her worker'a tek tek anlık push yapmak yerine worker'ların bir sonraki soğuk açılışlarında ya da dakikalık tarayıcı üzerinden aldığı dağıtım satırları yazar. Her adım — etiket, durum (RUNNING/COMPLETED/FAILED), sayaçlar, bir residual sayısı ve notlar içeren — tek bir koşu satırını api_client_migration_run koleksiyonuna, ve yakınsamayan her kayıt için de api_client_migration_row koleksiyonuna (özne tipi, özne kimliği, sonuç, neden) bir satır yazar. Bu iki koleksiyon birlikte taşımanın kayıt defteridir.

Adım	Ne yapar
Kimlik	Kurulumdaki her eski tüketici için yukarıdaki Karar Değerleri'nde anlatılan envanter kararını verir, API istemcisi ikizini türetir, secret'ını taşır ve aktifleştirir. Residual (yeniden denenebilir): FAILED, FAILED_ISSUE. Kayıt defterine yazılır ama residual sayılmaz: SKIPPED_BLOCKED (boş kullanıcı adı), FAILED_DECRYPT, SOURCE_MISSING.
Erişim işareti	Yalnızca denetim amaçlı olarak, erişim ekseninin (typed grant/kısıt/registry) zaten yukarıdaki Kimlik adımıyla yazıldığını ve tüketici-sahipli ya da Yalnız Consumer bir kaydın erişim otoritesinin her zaman olduğu yerde — eski API Proxy ACL/API Proxy Grup ACL satırlarında — kaldığını kayda geçirir. Bu adım başka hiçbir şey yazmaz.
Limitler	Legacy İstek Hızı limitlerini typed Limit Planlarına ve atamalarına dönüştürür — tam dönüşüm için bkz. Yükseltmede Taşınan Legacy Limitler. Bir tüketicinin etkin AI token bütçesi de aynı şekilde kendi typed AI Token Bütçesi atamasına dönüştürülür ve varsa taşınmış API istemcisine taşınır; bkz. AI Bütçeleri.
Portal	Her portal uygulamasının erişim izinlerini onaylı aboneliklerinden yeniden türetir ve eşleşen abonelik planı atamalarını geriye dönük doldurur.
Consumer key damgası	consumerKey alanı henüz olmayan her tüketici için benzersiz bir anahtar üretir — daha önceki senkronizasyon yazıcıları bunu hiç damgalamamıştı.
Doğrulama ve günlük reconcile	Yukarıdaki her adımın residual'ını tek bir koşu kaydında toplar, ardından günlük bir görevin (03:45), LimitMigrationReconcileJob, admin job kataloğunda var olduğundan emin olur — görev eksikse her açılışta otomatik olarak yeniden kurulur, bu changeset tarafından yalnızca bir kez kurulmaz. Kayıt defterinde residual ya da başarısız bir adım kaldığı sürece aynı idempotent adımları yeniden çalıştırır; tamamen yakınsadığında bu günde tek bir indeksli okumadan ibarettir. Bu adımın kendisi açılışta zamanlayıcıya erişemezse, görevi doğrudan kurmak yerine bir FAILED koşu kaydı yazar — job kataloğunun kendi açılış-anı yeniden kurulumu görevi yine de ayağa kaldırır ve bir sonraki gecelik koşusu kalan adımları yeniden dener.
Legacy parola temizliği	Anında değil, ertelenmiş: Kimlik adımı yakınsadıktan 7 gün sonra (-Dapinizer.migration.legacyPasswordUnsetGraceDays=N ile yapılandırılabilir), yukarıdaki günlük reconcile görevi, ikizi Aktif olan ve kendi secret materyalini (Yerel Secret ya da Secret Reference) taşıyan her eski tüketicinin password alanını siler; böylece secret'ın ikinci bir kopyası geride kalmaz. Ortam detayı parolaları ve username olduğu gibi bırakılır. Secret taşıması başarısız olmuş ya da ikizi hâlâ Taslak'ta olan bir tüketici parolasını korur — eski yol onun için yanıt vermeye devam eder. Bekleme süresi, o pencere içinde yeniden başlayan daha eski sürümlü bir gateway pod'unun taşınmış bir tüketiciyi doğrulamak için ihtiyaç duyduğu parolayı hâlâ bulabilmesi içindir — her gateway bu pencere içinde bu sürüme yükseltilmelidir; bkz. Apinizer Sürüm Yükseltme. Pencere dolana kadar kayıt defteri bu adımı 1 residual ve bir deferred notuyla gösterir — bu beklenen bir durumdur, hata değildir.

Sayaçlar sıfırdan başlar, geri dönüş yok

Legacy kota/daraltma sayaçları taşınmaz — her typed İstek Hızı sayacı sıfırdan başlar. Taşınmış bir AI Token Bütçesi ataması bunun tek istisnasıdır: eski bütçenin zaten kullandığı aynı sayaç altında sayılmaya devam eder, böylece pencere içindeki AI tüketimi sıfırlanmak yerine taşınır. Bu taşıma için bir geri alma (rollback) mekanizması yoktur; yükseltmeden önce alınmış bir MongoDB yedeği (bkz. Apinizer Sürüm Yükseltme) tek geri dönüş yoludur.

Script yazmak için — her eski kaydın neye dönüşeceğini yeniden okumak ya da türetmeyi ya da secret taşımasını bir proje için sonradan yeniden çalıştırmak amacıyla — aynı adımlar Manager REST API'sinde de sunulur; bkz. API İstemcisi Secret Taşıma.

Göç Etmiş Kayıtlarda Client ID ve Client Secret Tüketici Ekranından Kalkar

Bir tüketicinin istemci kimliği otomatik taşıma ile bir API istemcisine — secret materyali dahil olacak şekilde — taşındıktan sonra, o tüketicinin düzenleme ekranında Kullanıcı Adı ve Parola alanları artık gösterilmez. Kimlik bölümünde bunların yerine taşınmış istemcinin client id'si ve alanların nereye taşındığını söyleyen bir not görünür: kullanıcı adı, her çağıranın zaten elinde tuttuğu client id'nin kendisidir; secret ise API Clients sekmesi altındaki Client Secrets alt sekmesinden, her zamanki grace süresi mekanizmasıyla rotate edilir — önceki secret grace süresi boyunca doğrulamaya devam ederken yeni secret devreye girer. Ekranın üstündeki bilgi banner'ı da taşınmış istemciyi adıyla belirtir.

Tüketicinin diğer tüm alanları düzenlenebilir kalır ve kayıt normal şekilde kaydedilir; formu kaydetmek kullanıcı adını da parolayı da değiştirmez. Kullanıcı adı kilidi sunucu tarafında da uygulanır: göç etmiş bir kayıtta kullanıcı adını fiilen değiştiren bir kaydetme isteği, ekran ne gösterirse göstersin credential.legacyIdentityMigrated hata anahtarıyla 400 ile reddedilir. API üzerinden yeni bir parolayla gelen bir kaydetme isteği ise taşınmış istemcinin secret'ını yine o değere rotate eder; eski davranışa göre yazılmış entegrasyonlar çalışmaya devam eder. Henüz taşınmamış kayıtlarda kullanıcı adı ve parola eskisi gibi düzenlenebilir.

not

Ne kullanıcı adı kilidi ne de bir parola rotasyonu, halihazırda verilmiş hiçbir şeyi askıya almaz: rotasyondan önce alınmış bir token, önceki secret'ın grace süresi bitene kadar geçerliliğini korumaya devam eder.

Durum Yayılımı: Eşzamanlı İtme ve Kendiliğinden Onarım

Askıya alma, devam ettirme ve iptal önce yönetim kayıtlarına işlenir; ardından yeni durum, gateway ortamlarına eşzamanlı olarak itilir. Bu itme — örneğin bir ortam o an erişilemezse — tüm ortamlardan aynı anda onay alamayabilir. Böyle bir durumda:

• Yanıt her zaman gerçek durumu bildirir. Management API yanıtındaki dağıtım durumu bilgisi bir durum ve etkilenen ortamların listesini taşır: Senkron her ortam onayladı, Gecikmiş en az bir ortam henüz onaylamadı, Beklemede yalnızca aşağıdaki kalıcı iptal senaryosunda görülür. Hiçbir yüzey Gecikmiş ya da Beklemede durumundaki bir işlemi "ortamlara tamamen ulaştı" olarak göstermez.
• Kalıcı bir iptal asla sessizce yarım kalmaz. Bir API istemcisi iptali tüm ortamlardan eşzamanlı onay alamazsa istek 202 Accepted ile sonuçlanır ve yanıt, durumun ayrıca sorgulanabileceği adresi bildirir; o anki durum Beklemede'dir. İşlemin kendisi geri alınmaz: iptal kalıcı olarak kaydedilmiştir, yalnızca tüm ortamlara ulaşması zaman alacaktır.
• Ulaşamayan bir değişiklik kendiliğinden tamamlanır. Beklemede ya da Gecikmiş kalan her değişiklik, dakikada bir çalışan bir arka plan süreci tarafından henüz onaylamamış ortamlara otomatik olarak yeniden iletilir; ardışık denemeler arasındaki bekleme süresi 1, 2, 5, 15 ve en sonunda 60 dakikaya kadar artar. Tüm ortamlar onayladığında durum kendiliğinden Senkron'a döner — bunun için elle bir işlem yapmanız ya da bir ortamı yeniden başlatmanız gerekmez. Bir kayıt hiç oluşturulamamış ya da bir kesinti sırasında kaybolmuşsa bu da gecelik çalışan ayrı bir tarama ile tespit edilip yeniden oluşturulur ve aynı otomatik iletime dahil edilir.
• Bir istemcinin dağıtım durumu her zaman ayrıca sorgulanabilir, ortam bazında kırılımıyla birlikte. Ekranda bu, istemci detayındaki Runtime rozetiyle gösterilir — Senkron, onaylanan/hedef biçiminde bir sayaçla Gecikmiş (örneğin "2/3") ya da Beklemede — ve rozete tıklandığında hangi ortamın onayladığını, hangisinin geride kaldığını ve varsa nedenini listeleyen bir panel açılır. Bu sorgu, henüz hiç dağıtılmamış ya da bu sürümden önce oluşturulmuş bir istemci için boş sonuç döner.
• İptalin en kritik ayağı bu gecikmeden hiç etkilenmez: açık (opaque) token'lar doğrudan yönetim veritabanından silinir ve yayılımı geciken bir ortamda bile silinmiş bir token'la yapılan doğrulama başarılı olmaz.
• Bir ortama, elindekinden daha eski bir yapılandırma asla geri yazılmaz. Her gateway ortamı üzerindeki yapılandırmanın sürümünü izler ve bundan daha eski bir itmeyi reddeder; bu, örneğin gecikmiş bir yeniden denemenin daha yeni bir işlemle çakışması durumunda güncel durumun eski bir kopyayla ezilmesini engeller.
• Sahip/kurum zinciri bilgisi bir ortama hiç ulaşmamışsa istemci o ortamda güvenli tarafta kalınarak reddedilir (fail-closed) — belirsizlik hiçbir zaman erişime açılmaz.

Sürüm geçişi: Manager ve Worker'lar birlikte güncellenmelidir

Bu sürüm hattında Manager ve Worker'lar birlikte güncellenmelidir. Eski bir Manager'dan itme (push) alan bu sürümdeki bir Worker, sahip zinciri alanını hiç almadığı için güvenli tarafta kalır (fail-closed): ilgili API istemcileri, o worker yeniden başlatılana kadar o worker'da reddedilir — yeniden başlatma sahip zincirini yerel olarak yeniden türetir ve durumu düzeltir. Ters kombinasyonda — yeni Manager, eski Worker — kurum-askısı ekseni, o worker güncellenene kadar o worker'da hiç uygulanmaz.

Bilinen Sınır: İptal Kaskadı Dışında Kalan Eski JWT Yolları

Bazı JWT'lere hiçbir iptal ulaşamaz

Yukarıda anlatılan kesim noktası (cutoff), yalnızca damgalanacak bir kaydı olan kimlikler için vardır — yani bir API istemcisi için. İki JWT şeklinin böyle bir kaydı yoktur ve ne iptal edilirse edilsin kesim noktasının dışında kalır:

• Depolanmış bir tüketici (consumer) ya da API istemcisi kaydı dışında bir kimlik kaynağıyla üretilmiş bir JWT — örneğin harici bir LDAP, Veritabanı, API veya OIDC kimlik servisine karşı password-grant doğrulaması;
• Hiçbir tüketici kaydı olmayan bir client_credentials çağıranına verilmiş bir JWT — tüketicisiz eski tip M2M entegrasyonu.

Bir tüketiciyi, bir API istemcisini ya da bir kurumun tüketicilerini iptal etmek, bu iki şekilden birindeki halihazırda üretilmiş bir token'ı kendi süresi dolmadan asla geçersiz kılamaz — kesim noktasının damgalanacağı bir kayıt yoktur. Token İptali Katılık Ayarı da bu boşluğu o tür bir iptal için kapatmaz: ayarı açmak yalnızca token'ın kendi açık iptalinin — çağıranın RFC 7009 iptal uç noktasına kendi çağrısının — bu şekildeki bir token için gerçekten etkili olmasını sağlar; bugün bu çağrı kabul edilir ama sessizce hiçbir şey yapmaz. Ayar, yöneticinin tetiklediği bir tüketici, API istemcisi ya da kurum iptalinin daha önce ulaşamadığı bir token'a ulaşmasını sağlamaz.

Performans

Token kayıtları üzerinde arama performansını iyileştiren yeni indeksler eklenmiştir; bu, sunucu tarafında bir performans iyileştirmesidir ve yukarıda anlatılan davranışların hiçbirini değiştirmez.

Tüketici Erişim Denetimi Ayarları

Tüketicinin erişim izinlerini ayarlamak için Erişim Denetimi (Access Control List) paneline geçilerek işlem yapılır.

Bu panelde erişim izni verilmek istenen API Proxy, + Add API Proxy tuşuna basılarak karşımıza çıkan ekrandan seçilir.

Erişim Denetimi — Access Control sekmesi

Açılan ekrandan ayarlamak istenilen API Proxy(ler) seçilir ve Ekle (Add) tuşuna basılır.

Add API Proxy — Proxies diyaloğu

Bu işlem ile tüketiciye seçilen API Proxy'ler için erişim izni verilmiş olur. Bu işlemin canlı çalışan kurallar üzerinde aktif hale gelebilmesi için ortamlara yüklenmesi gereklidir.

Bunun için işlemler tamamlandığında sağ üst köşedeki Kaydet ve Yükle (Save and Deploy) tuşuna basılarak ayarların aktifleşmesi sağlanır.

Kaydet ve Yükle — Save and Deploy

API Proxy Bazlı Özelleştirme

API Proxy bazında tüketicinin özelleştirilmesi için Access Control listesinden ilgili API Proxy seçilir; sağdaki yapılandırma panelinde kota, daraltma ve geçerlilik ayarları yapılır.

API Proxy bazlı özelleştirme paneli

API Proxy bazlı erişimi özelleştirme konfigürasyonu için kullanılan alanlar aşağıdaki tabloda görülmektedir.

Alan	Açıklama
Geçerliliğini Yitirme Zamanı (Expires On)	Bu tarih değerinin girilmesi durumunda Tüketici bu tarih geldiği zamandan itibaren API Proxy'e erişemez hale gelir.
Ortam Listesi (Environment List)	API Proxy'nin yüklendiği ortama özel olarak Kota ve Daraltma değerlerinin girilebilmesini sağlar.
Ortam Kotası (Quota)	API Proxy'nin belirtilen ortama özel Kota değeridir.
Ortam Daraltması (Throttling)	API Proxy'nin belirtilen ortama özel Daraltma değeridir.
Mesaj Sayısı (Message Count)	Daraltma Aralığı ile verilen süre içinde Backend API'ye gönderilebilecek olan maksimum mesaj sayısıdır.
Daraltma Zaman Miktarı (Interval Time Amount)	Seçilen zaman birimi cinsinden, sınırlama penceresinin süresini belirten sayısal değer.
Daraltma Zaman Birimi (Interval Time Unit)	API istek sınırlaması için kullanılan zaman aralığı birimi (örneğin, saniye, dakika).
Periyot Tipi (Interval Window Type)	API istek sınırlaması için kullanılan zaman aralığı yöntemi (sabit veya kayan).
Cache Bağlantısı Zaman Aşım Süresi (Cache Connection Timeout (Second))	Cache bağlantısı için zaman aşımı süresi belirtilir.
Cache Bağlantı Hatası Eylemi (Action for Cache Connection Error)	Eğer politika cache sunucusuna bağlantı sorunu yaşarsa uygulanacak eylem belirtilir.
İzin Verilmeyen Metodlar (Disallowed Methods)	Tüketicinin sahip olduğu rollerinden bağımsız olarak API Proxy'nin herhangi bir metoduna erişmemesi isteniyorsa, burada API Proxy'nin erişime kapatılmak istenen metodları seçilir.
AI Model Erişimi (AI Model Access)	Yalnızca AI proxy'lerinde anlamlıdır. Bu tüketicinin bu proxy ve ortamda çağırabileceği modelleri sınırlar — bkz. aşağıdaki bölüm.
Kaydet ve Yükle Tuşu (Save and Deploy)	Ayarların/değişikliklerin tamamlanması sonrasında Kaydet ve Yükle tuşuna basılarak ayarların aktifleşmesi sağlanır.

AI Model Erişimi

Bir AI proxy'sinde her tüketicinin aynı modellere erişmesi istenmeyebilir: örneğin bir ekibe yalnızca ucuz bir modeli açıp pahalı olanı kapatmak isteyebilirsiniz. AI Model Erişimi, ortam kartındaki anahtar açıldığında bu tüketicinin bu proxy ve ortamda çağırabileceği model kimliklerini sınırlar.

Kısıt iki yolda birden uygulanır ve ikisi de zorunludur:

• Çağrı yolu — liste dışındaki bir model istenirse istek reddedilir; tüketici failover ya da koşullu yönlendirme üzerinden de o modele ulaşamaz.
• Keşif yolu — GET /v1/models çıktısı çağırana göre süzülür; izin verilmeyen model listede hiç görünmez.

Boş liste kısıt DEĞİLDİR

Anahtar açık olsa bile liste boşsa hiçbir kısıt uygulanmaz ve tüketici proxy'nin sunduğu her modeli çağırabilir. Bu, sağlayıcı tarafındaki İzin Verilen Modeller alanıyla aynı davranıştır (boş = kısıtsız) ve mevcut kayıtların davranışının değişmemesini sağlar. Kısıtlamak için en az bir model ekleyin.

not

Kota ve model erişimi ayrı kavramlardır. Kota "ne kadar tüketebilir", model erişimi "hangi modeli çağırabilir" sorusunu yanıtlar. Bir modele bütçe tanımlamak ona erişim vermez; erişim vermek de bütçe tanımlamaz.

Kota aşımında otomatik model düşürme (cheaper model) kullanıyorsanız, hedef model bu listede yoksa istek düşürülmez, engellenir — aksi halde kısıt kota aşımı üzerinden delinirdi.

Tüketici olmayan (anonim) isteklerde bu kısıt uygulanmaz; proxy ve sağlayıcı seviyesindeki kısıtlar aynen çalışmaya devam eder.

Senkronizasyon Sekmesi

Bir kimlik sağlayıcısından senkronize edilmiş tüketicilerin detayında ayrı bir Senkronizasyon sekmesi görüntülenir; elle oluşturulmuş kayıtlarda bu sekme görünmez. Sekmedeki alanlar aşağıdaki gibidir.

Alan	Açıklama
Kaynak Tipi (Source Type)	Kaydın senkronize edildiği kaynak türüdür: LDAP, Veritabanı, API veya OIDC.
Kaynak Adı (Source Name)	Kaydı senkronize eden kimlik sağlayıcının adıdır.
LDAP DN	Yalnızca LDAP kaynaklı kayıtlarda görüntülenir; kaydın dizindeki tam DN değeridir.
Son Senkronizasyon	Kaydın en son senkronize edildiği zamandır.

Kimlik yönetme yetkisi olan kullanıcılar için sekmede bir Senkronize Et düğmesi de bulunur. Bu düğme yalnızca ilgili tek kaydı değil, kaydın bağlı olduğu kaynak sağlayıcının tamamını senkronize eder; zamanlama, geçmiş ve toplu izleme için Kimlik Bilgisi Senkronizasyonu sayfasına bakabilirsiniz.

Metadata

Metadata sekmesi — Consumer Metadata

Her tüketici üzerinde serbest tanımlı anahtar/değer metadata girişleri oluşturabilirsiniz. Bu girişler tüketici ile birlikte saklanır, isteğe bağlı olarak şifrelenir ve şu kanallara aktarılabilir:

• JWT token payload — JWT'ye Ekle seçeneği aktifse, giriş token oluşturma sırasında JWT body'sine custom claim olarak eklenir. Hassas işaretli girişler bu kuralın dışındadır (aşağıdaki uyarıya bakın).
• OAuth token endpoint response body — Token Yanıtına Ekle seçeneği aktifse, giriş /oauth/token JSON response'una ek bir alan olarak eklenir.
• Script politikaları (Groovy / JavaScript) — script içinden credentialMap ile erişilir (bkz. aşağıdaki Script Erişimi). Script bağlamı, include seçeneklerinden bağımsız olarak tüm metadata'yı (hassas değerler dahil) görür.
• APIops GET /apiops/projects/{projectName}/credentials/{username} response'unda görünür. Hassas (secret) değerler *** ile maskelenir.

Alanlar

Alan	Açıklama
Anahtar (Key)	Metadata girişinin benzersiz tanımlayıcısı. Boş olamaz; aynı credential üzerinde tekrarlanan anahtarlar save sırasında reddedilir.
Değer (Value)	Serbest formda değer. Hassas aktif olduğunda şifrelenmiş olarak saklanır. ${env.X} / #{ctx.Y} placeholder'ları runtime'da çözümlenir.
Hassas (Secret)	Aktif olduğunda değer at-rest şifrelenir ve yönetim/APIops credential listelemelerinde *** ile maskelenir. Token endpoint response'unda ise TLS üzerinden açık (çözülmüş) olarak teslim edilir; imzalı JWT herkesçe okunabilir olduğundan JWT claim'i olarak hiçbir zaman eklenmez. Her giriş için bağımsız ayar.
JWT'ye Ekle (Include in JWT)	Aktif olduğunda giriş JWT claim'i olarak token'a eklenir. Hassas işaretli girişler bu seçenek açık olsa dahi JWT'ye dahil edilmez. OAuth-opaque grant tiplerinde devre dışıdır.
Token Yanıtına Ekle (Include in Token Response)	Aktif olduğunda giriş OAuth token endpoint response body'sine eklenir. Token Yönetim Ayarları'ndaki alan isimlendirmelerine uyar.
JWT Claim Adı	Opsiyonel: claim/alan adı override'ı. Boş bırakılırsa girişin Anahtar değeri kullanılır.

uyarı

Hassas işaretli alanlar, herkesçe okunabilen imzalı JWT'ye hiçbir zaman claim olarak yazılmaz — JWT'ye Ekle açık olsa bile. Hassas değerler yalnızca token endpoint response gövdesiyle (TLS üzerinden, kimliği doğrulanmış istemciye) teslim edilir. JWT içine gömülmesi gereken hassas olmayan değerler için Hassas seçeneğini kapalı tutun.

Rezerve İsimler

Aşağıdaki isimler, JWT'ye Ekle veya Token Yanıtına Ekle aktif girişlerde kullanılamaz. UI ve backend'de save reddedilir.

• JWT (RFC 7519): iss, sub, aud, exp, nbf, iat, jti
• JWT (Apinizer dahili): X-ApplicationName, X-IssuedAt, X-ExpiresAt, X-ExpiresInMillis, scope, X-RefreshTokenExpiresAt, X-RefreshTokenExpiresInMillis, X-RefreshTokenIssuedAt, X-RefreshCount, X-MaxRefreshCount, X-ApiResponse, X-RefreshToken
• OAuth response (RFC 6749): access_token, refresh_token, token_type, expires_in, scope, state, error, error_description, error_uri
• OAuth response (Apinizer dahili): X-ApplicationName, X-IssuedAt, X-ExpiresAt, X-RefreshTokenIssuedAt, X-RefreshTokenExpiresAt, X-RefreshCount, X-ApiResponse
• OAuth response (dinamik): Token Yönetim Ayarları altında OAuth yanıt alanları için tanımladığınız özel adlar (örn. access token veya scope alanı için verdiğiniz isimler) da rezerve sayılır.

Kurum Seviyesi Metadata

Kurumlar (Organization) da aynı metadata yapısını destekler. Kurum metadata'sı, o kuruma bağlı (Kurum alanı bu kurumu gösteren) tüm tüketiciler için varsayılan olarak uygulanır. Token üretiminde önce kurum metadata'sı uygulanır; aynı anahtar tüketici üzerinde de tanımlıysa tüketicinin değeri öncelik kazanır (tüketici seviyesi, kurum seviyesini geçersiz kılar). Kurum tek başına token üretmez; kurum yalnızca bağlı tüketiciler için metadata miras sağlar.

Script Erişimi

Script politikalarından (Groovy / JavaScript) metadata'ya credentialMap bağlama değişkeniyle erişilir; kullanıcı adı veya istemci kimliği ile sorgulanır:

• credentialMap["kullanıcıAdı"].metadata — birleştirilmiş (kurum + tüketici) metadata
• credentialMap["kullanıcıAdı"].credentialMetadata — yalnızca tüketici metadata'sı
• credentialMap["kullanıcıAdı"].organizationMetadata — yalnızca kurum metadata'sı

credentialMap yalnızca sorgulama içindir; tüm kullanıcıların listelenmesi veya değiştirilmesi desteklenmez. Script bağlamı hassas değerleri de okuyabilir.

İstisna: API istemcileri

Bir API istemcisinin client kimliğiyle sorgulandığında credentialMap her zaman bulunamadı döner (hem varlık kontrolü hem değer okuma tutarlı biçimde boş sonuç verir) — API istemcileri bu sürümde script bağlamında görünmez. Bu bilinçli bir tasarımdır: API istemcisinin parolası script'e null olarak sızdırılmaz.

Token Ayarları

Token ayarları için Token Ayarları (Token Settings) paneline geçilerek işlem yapılır.

Token ayarlarını içeren görsele aşağıda yer verilmiştir:

Token Settings sekmesi

Token ayarları konfigürasyonu için kullanılan alanlar aşağıdaki tabloda görülmektedir.

Alan	Açıklama
Onay Türü (Grant Type)	Buna göre token üretimi istenecek olan bilgiler değişmektedir. Client Credentials veya Password.
Kimlik/Yetki Doğrulama Servisi (Identity/Role/Group Service)	Grant Type password ise; gönderilecek olan username, password bilgisinin nereden doğrulanacağını belirten kimlik sağlayıcı servisidir.
JWT Rejeneratör API Servisi (Select to JWT Regenerator Service API)	Bu özellik yalnızca JWT token kullanımında geçerlidir. JWT token değerinin seçilen API üzerinden kimlik doğrulama olmaksızın tekrar oluşturulmasını sağlar.
Önceki Token'ı Sil (Delete Previous Token)	Bu özellik yalnızca OAuth2 token kullanımında geçerlidir. Yeni token alımlarında ya da yapılan yenilemelerde, önceki token'ı geçersiz hale getirir.
Token Ölümsüz Olsun (Token Never Expires)	Bu seçenek işaretlenirse token zamana bağlı olarak geçersiz hale gelmez, istenildiği kadar kullanılabilir.
Token Geçerlilik Süresi (Token Expires In)	Token'ın kullanılabilir olacağı yaşam süresini belirtir.
Token Yenileme Olsun (Refresh Token Allowed)	Token'ın yenilenme özelliğini etkinleştirir.
Token Yenileme Sayısı (Refresh Token Count)	Token'ın kaç kez yenilenebilir olacağını belirtir.
Yenilenmiş Token Geçerlilik Süresi (Refresh Token Expires In)	Her bir yenilemede, token'ın ne kadarlık yaşam süresine sahip olacağını belirtir.
JWT İmzalama Algoritması (JWT Signature Algorithm)	Bu özellik yalnızca JWT token kullanımında geçerlidir. Token üretilirken kullanılacak olan imza algoritmasını seçmek için kullanılır.
URL Parametrelerine İzin Ver (Allow URL Parameters)	Token Servisine token üretimi için istek gönderilirken bilgilerin URL parametresi halinde de gönderilmesine izin verir. Güvenlik açısından risk oluşturacağından kullanılmaması tavsiye edilir.

Client Authentication — Authorization Basic Header Desteği (RFC 6749 §2.3.1)

Örnek:

Basic Authorization Header (Yeni — 2026.04.4)

curl -u "my-client-id:my-secret" \
  -d "grant_type=client_credentials" \
  https://gateway.example.com/credential/token

Body Parametreleri (Geriye Dönük Uyumlu)

curl -d "grant_type=client_credentials&client_id=my-client-id&client_secret=my-secret" \
  https://gateway.example.com/credential/token

Önemli Kurallar:

• Çift gönderim yasağı: Aynı istekte hem Authorization Basic header'ı hem body'de client_id/client_secret parametreleri gönderirseniz, sunucu HTTP 400 (invalid_request) ile reddeder (RFC 6749 §2.3.1 "MUST NOT" kuralı).
• Bozuk header işlemesi: Base64-decode edilemeyen veya eksik Basic header'lar HTTP 401 (invalid_client) ile reddedilir.
• Diğer Authorization scheme'leri: Basic dışındaki yetkilendirme türleri (örn. Bearer, Digest) görmezden gelinir; bu durumda body parametreleri kullanılır.
• Şifre ve kullanıcı adı: PASSWORD grant akışında username ve password her zaman request body'de gönderilir; Authorization header sadece client_id/client_secret için kullanılır.

JWK Ayarları

Secrets sekmesinden, tüketicinin JWK anahtarları ile ilgili verisinin decrypt edilmesi ve/veya imzasının doğrulanabilmesi için gerekli olan JWK anahtarları seçimleri yapılır.

JWK ayarlarını içeren görsele aşağıda yer verilmiştir:

Secrets sekmesi — JOSE JWK

JWK ayarları konfigürasyonu için kullanılan alanlar aşağıdaki tabloda görülmektedir.

Alan	Açıklama
JOSE İmza & Doğrulama için JWK (JWK for JOSE Sign & Validation)	Tüketicinin sahip olduğu imzalama/imza doğrulama JWK anahtarıdır. JOSE Validation/Implementation politikalarında kullanıcının anahtarı kullanılsın denildiğinde imzalama/imza doğrulama için bu JWK kullanılır.
JOSE Encryption & Descryption için JWK (JWK for JOSE Encryption & Descryption)	Tüketicinin sahip olduğu şifreleme/şifre doğrulama JWK anahtarıdır. JOSE Validation/Implementation politikalarında kullanıcının anahtarı kullanılsın denildiğinde şifreleme/şifre doğrulama için bu JWK kullanılır.

mTLS Ayarları

Secrets sekmesinden, tüketicinin mTLS Authentication Poliçesi ile sertifikasının doğrulanabilmesi için gerekli olan Truststore seçimi yapılır.

mTLS ayarlarını içeren görsele aşağıda yer verilmiştir:

Secrets sekmesi — Truststore (mTLS)

mTLS ayarları konfigürasyonu için kullanılan alanlar aşağıdaki tabloda görülmektedir.

Alan	Açıklama
Truststore (Truststore)	Truststore seçilir. Eğer daha önce tanımlı değil ise yandaki + butonuna basarak yeni bir tane oluşturulabilir.