Kullanıcılar
Apinizer'da API Developer, API Analitik, Proje Sahibi (Project Owner), Sistem Yöneticisi (System Admin) gibi rollerde çalışacak ya da platformu yönetecek kullanıcıların Apinizer'a tanımlanması gerekmektedir.
Kullanıcı Yönetiminin Önemi
Kullanıcı yönetimi, Apinizer platformunun güvenli ve verimli bir şekilde çalışması için kritik bir rol oynar. Doğru kullanıcı tanımlamaları ve rol atamaları sayesinde:
- Güvenlik: Her kullanıcı sadece yetkili olduğu işlemleri gerçekleştirebilir
- Verimlilik: Kullanıcılar kendi sorumluluk alanlarına odaklanabilir
- İzlenebilirlik: Kullanıcı bazlı işlemler takip edilebilir ve raporlanabilir
- Ölçeklenebilirlik: Büyük organizasyonlarda merkezi kullanıcı yönetimi sağlanır
Kullanıcı Tipleri
Sistem genelinde iki tür kullanıcı tipi vardır; Kullanıcı (User) ve Sistem Yöneticisi (Admin).
Kullanıcı Apinizer'da sadece giriş yetkisine sahiptir ve sadece üye olarak eklendiği projedeki rolü/rolleri kapsamında işlemler yapmaya yetkilidir. Bu kullanıcılar, kendilerine atanan projeler ve roller dahilinde platformu kullanabilirler.
Sistem Yöneticisi rolüne sahip kullanıcı Apinizer'da tüm işlemleri yapma yetkisine sahiptir. Administration menüsündeki tüm yönetim işlemlerini gerçekleştirebilir ve platform genelinde tam kontrol yetkisine sahiptir.
Kullanıcı Rolleri ve Proje Üyeliği
Kullanıcı farklı projelerde farklı rollere sahip olabilir. Örneğin, A projesinde API Developer rolüne sahip iken, B projesinde API Analytics, C projesinde API Developer ve API Analytics rollerinde olabilir.
Benzer şekilde bir kullanıcıyı farklı takımlara farklı roller tanımlanabilir.
Esnek Rol Yönetimi
Apinizer'da kullanıcılar için esnek bir rol yönetim sistemi bulunmaktadır:
- Proje Bazlı Roller: Her kullanıcı farklı projelerde farklı rollerle çalışabilir
- Takım Bazlı Roller: Kullanıcılar farklı takımlarda farklı rollerle yer alabilir
- Çoklu Rol Desteği: Bir kullanıcı aynı projede birden fazla role sahip olabilir
- Dinamik Yetkilendirme: Roller proje ve takım bazında dinamik olarak yönetilebilir
Kullanım Senaryoları
Kullanıcılar projelere üye olarak eklenir ve proje bazında roller atanır. Örneğin:
- E-Ticaret projesinde API Developer
- Ödeme projesinde API Analytics
- Raporlama projesinde hem Developer hem Analytics
Kullanıcılar takımlara üye olarak eklenir ve takım bazında roller atanır. Takım projelere eklendiğinde, takım üyeleri otomatik olarak projeye eklenir.
Bir kullanıcıyı herhangi bir projeye üye olarak nasıl ekleyebileceğinizi öğrenmek için tıklayınız .
Kullanıcı Rolleri Detayları
Apinizer'da kullanıcılara atanabilecek roller ve bu rollerin yetkileri aşağıda detaylı olarak açıklanmıştır:
Sistem Yöneticisi
Apinizer Management Console'u üzerinde gerçekleştirilebilecek tüm işlemleri yönetebilir. Özellikle Administration menüsündeki, uygulamanın yönetim bazlı işlemlerini sadece bu yetkiye sahip kullanıcı yapabilir. Bu rol:
- Tüm projelerde tam yetkiye sahiptir
- Sistem ayarlarını yönetebilir
- Kullanıcı ve takım yönetimi yapabilir
- Tüm API Proxy'lere erişebilir
API Portal Yöneticisi
Bu yetkiye sahip kullanıcı, konsol üzerindeki Portal Yönetimi (Portal Management) bazındaki API oluşturma, hesaplar, tüketiciler ve portal ayarlarına ait işlemleri gerçekleştirebilir. Portal yönetimi için gerekli tüm yetkilere sahiptir.
Analyzer
Bu yetkiye sahip kullanıcı, Analitik modülündeki grafikler, kullanım özetleri, sorgular oluşturup raporlar hazırlama işlemleri yönetir. Analitik verileri görüntüleyebilir, özel sorgular oluşturabilir ve raporlar hazırlayabilir.
Proje Yöneticisi
Bu yetkiye sahip kullanıcı, tüm projelerde yetkili olup, tüm işlemleri yönetebilir. Proje bazlı tüm operasyonları gerçekleştirebilir ve proje ayarlarını yönetebilir.
API Portal İş Kullanıcısı
Bu yetkiye sahip kullanıcı, Portal üzerindeki Apileri görüntüleme, kullanıcılar ile ilgili işlemleri yönetme, organizasyon ile ilgili işlemleri yapabilmektedir. Portal kullanıcı yönetimi ve organizasyon yönetimi yetkilerine sahiptir.
API Portal Geliştirici Kullanıcısı
Bu yetkiye sahip kullanıcı, konsol üzerindeki Portal Yönetimi (Portal Management) bazındaki API oluşturma ve portal ayarlarına ait işlemleri gerçekleştirebilir. Portal üzerinde API geliştirme ve yayınlama yetkilerine sahiptir.
Promotion Yöneticisi
Bu yetkiye sahip kullanıcı, Administration menüsündeki Promotion Manager ekranlarına (Instances, Mappings, Executions) ve projelerdeki Promotion ekranına erişip API'lerin ortamlar arası taşıma (promotion) işlemlerini yönetebilir.
Kurulumla birlikte gelen yerleşik admin hesabı Sistem Yöneticisi, Analyzer, API Portal Yöneticisi, Promotion Yöneticisi, API Portal İş Kullanıcısı ve API Portal Geliştirici Kullanıcısı yetkileriyle gelir. Önceki bir sürümden yükseltilen kurulumlarda son üç yetki admin hesabına otomatik olarak eklenir; bir yöneticinin bu hesapta bilinçli olarak kaldırdığı bir yetki yeniden işaretlenmez. Proje Yöneticisi yetkisi bu ekleme kapsamında değildir. Bir yükseltme başka hiçbir kullanıcıyı değiştirmez.
Yeni Bir Kullanıcı Oluşturma
Kullanıcı oluşturma ayarlarını içeren görsele aşağıda yer verilmiştir:
Kullanıcı oluşturma konfigürasyonu için kullanılan alanlar aşağıdaki tabloda görülmektedir.
| Alan | Açıklama |
|---|---|
| Kullanıcı Giriş Tipi (User Login Type) | Kullanıcının giriş yapacağı kaynağın seçimidir. Değeri "Veri tabanı" olması durumunda tüm bilgilerin Apinizer kullanıcı havuzunda tanımlı olacağını ifade eder. Değeri "LDAP" olması durumunda "kullanıcı adı ve parola" bilgisinin, login esnasında seçili LDAP bağlantısı üzerinden doğrulanacağını, diğer bilgilerin veri tabanında tutulacağını ifade eder. LDAP tipindeki kullanıcıların kısmi olarak da olsa Apinizer veri tabanında da tutuluyor olması kullanıcıya rol tanımlama ve projeye erişim yetkisi verilebilmesi için gereklidir. Bu durumda olan kullanıcıların LDAP havuzundaki kullanıcı adıyla bu listeye kayıt edilmesi gereklidir. LDAP ile giriş ayarlarının nasıl aktifleştirildiği hakkında detaylı bilgi için buraya tıklayınız. |
| Kullanıcı Adı (Username) | Giriş yapmak için kullanılan kullanıcı adı bilgisidir. |
| Parola (Password) | Kullanıcı Giriş Tipi'nin veri tabanı olması durumunda bu alan görünür hale gelir. Kullanıcıya tanımlanan paroladır. Karşılaması gereken kurallar (uzunluk, karakter türleri, önceki parolaların yeniden kullanımı) ve girilirken ekranda gösterilen canlı kontrol listesi, Genel Ayarlar'daki Parola Politikası'ndan gelir; bkz. Parola Kuralları ve Zorunlu Değişim. Var olan bir kullanıcıda bu alanın yerinde bir pencere açan Parola Değiştir düğmesi bulunur. Yeni parola orada iki kez girilir; iki giriş eşleşmeden pencere kaydedilemez. Parola üret düğmesi üretilen değeri iki alana da yazar. |
| LDAP'da ara (Search in LDAP) | Kullanıcı Giriş Tipi'nin LDAP olması durumunda bu alan görünür hale gelir. Girilen kullanıcı adı değerine göre LDAP'da arama yapılarak eşleşen kullanıcı bilgileri otomatik olarak gelir. |
| Ayırt Edici Ad (Distinguished Name) | Hesabın bağlı olduğu LDAP kaydı ve bu kaydı tutan LDAP bağlantısı (bağlantı kayıtla birlikte saklanır, ayrı bir alan olarak gösterilmez). İkisi de otomatik doldurulur: LDAP'da ara kaydı ve bulunduğu bağlantıyı kaydeder; Ayırt Edici Ad boş bırakılarak kaydedilen kullanıcı için kullanıcı adı bütün aktif bağlantılarda aranır ve eşleşme kaydedilir; bunun için her bağlantıda arama yapılabilmiş ve kullanıcı adı tam olarak bir bağlantıda bulunmuş olmalıdır (aksi hâlde kayıt, bulunamadığını, birden fazla bağlantıda bulunduğunu ya da bir bağlantıya erişilemediğini söyleyen bir mesajla reddedilir). Girişte yalnız kayıtlı bağlantıya sorulur ve parolayı kabul eden kayıt bu kayıt olmak zorundadır. Başka bir LDAP bağlantısındaki aynı kullanıcı adına sahip hesaba hiç başvurulmaz; aynı dizinin başka bir bölümündeki bir kayıt da bu hesabın oturumunu alamaz; böyle bir deneme Giriş Kayıtları ekranında LDAP_IDENTITY_MISMATCH sebebiyle listelenir.Kullanıcının sıradan bir düzenlemesi (roller, e-posta, aktiflik) kayıtlı bağlantıyı korur. Elle farklı bir Ayırt Edici Ad yazmak ancak dizinde doğrulandıktan sonra kaydedilir: önce daha önce kayıtlı bağlantıya bakılır; o bağlantı bu kaydı tutmuyorsa kayıt tam olarak bir aktif bağlantıda bulunmalıdır; aksi hâlde kayıt, kaydın bulunamadığını, birden fazla bağlantıda bulunduğunu (LDAP'da ara kullanın) ya da bir bağlantıda arama yapılamadığını söyleyen bir mesajla reddedilir. Ayırt Edici Ad'ı değiştirmek ya da boşaltmak hesap için tutulan LDAP grup bilgisini de siler: LDAP grupları üzerinden verilen proje yetkileri hemen sona erer ve hesabın bir sonraki başarılı girişiyle geri gelir (kullanıcıya doğrudan atanan roller etkilenmez; açık bir oturum süresi dolana kadar bunları korur). Tek bir kayda bağlanamayan hesaplar, bir yönetici kaydedene kadar girişte LDAP_IDENTITY_UNRESOLVED sebebiyle reddedilir: boş Ayırt Edici Ad, silinmiş ya da devre dışı bırakılmış kayıtlı bağlantı, ya da birden fazla LDAP bağlantısı olan bir kurulumda bu sürüme yükseltmeden sonra bağlantısı henüz kaydedilmemiş hesap (tek bağlantılı kurulumlarda hesaplar yükseltme sırasında otomatik bağlanır). Kayıt dizin içinde taşınırsa (örneğin başka bir organizasyon birimine) hesabı açın, alanı boşaltıp kaydedin: değer dizinden yeniden aranır. LDAP bağlantısının silinmek yerine pasifleştirildiği kurulumlarda, bağlantısı henüz kayıtlı olmayan hesap da reddedilir: pasif bağlantı hiç aranmaz, dolayısıyla kaydı hangi bağlantının tuttuğu gösterilemez ve bu bağ yalnızca bir kez yazılır. Hesabı kaydedin (bağlantısı böylece kaydedilir) ya da bağlantıyı yeniden aktif edin. Dizinde arama yapılamadığı sürece kayıt reddedilir ve hesap olduğu gibi kalır; dizin erişilebilir olduğunda yeniden deneyin. Aynı kayıt için farklı bir bağlantı kaydetmek de kimlik değişikliği sayılır: aynı şekilde doğrulanır ve grup bilgisini de siler. |
| Tam Adı (Full Name) | Kullanıcının ad soyad bilgisidir. |
| E-Posta (E-Mail) | Kullanıcının e-Posta adresidir. |
| Roller (Roles) | Kullanıcıya verilecek rollerin seçimidir. Kullanıcıya sistem yöneticisi yetkisi vermek için checkbox işaretlenmelidir. Sistem Yöneticisi: Apinizer Management Console'u üzerinde gerçekleştirilebilecek tüm işlemleri yönetebilir. Özellikle Administration menüsündeki, uygulamanın yönetim bazlı işlemlerini sadece bu yetkiye sahip kullanıcı yapabilir. API Portal Yöneticisi: Bu yetkiye sahip kullanıcı, konsol üzerindeki Portal Yönetimi (Portal Management) bazındaki API oluşturma, hesaplar, tüketiciler ve portal ayarlarına ait işlemleri gerçekleştirebilir. Analyzer: Bu yetkiye sahip kullanıcı, Analitik modülündeki grafikler, kullanım özetleri, sorgular oluşturup raporlar hazırlama işlemleri yönetir. Proje Yöneticisi: Bu yetkiye sahip kullanıcı, Tüm projelerde yetkili olup, tüm işlemleri yönetebilir. API Portal İş Kullanıcısı: Bu yetkiye sahip kullanıcı, Portal üzerindeki Apileri görüntüleme, kullanıcılar ile ilgili işlemleri yönetme, organizasyon ile ilgili işlemleri yapabilmektedir. API Portal Geliştirici Kullanıcısı: Bu yetkiye sahip kullanıcı, konsol üzerindeki Portal Yönetimi (Portal Management) bazındaki API oluşturma ve portal ayarlarına ait işlemleri gerçekleştirebilir. Promotion Yöneticisi: Bu yetkiye sahip kullanıcı, Administration ve proje menülerindeki Promotion ekranlarına erişip API'lerin ortamlar arası taşıma işlemlerini yönetebilir. |
| Kilitli (Locked) | Kullanıcının girişinin kilitli olup olmadığı bilgisidir. Hesap, izin verilen ardışık başarısız giriş denemesi sayısına ulaşıldığında (captcha ve kilitleme deneme ayarlarının toplamı, varsayılan 10) otomatik kilitlenir; kilit buradan açılır. Giriş ekranı kullanıcıya hesabın kilitli olduğunu hiçbir zaman söylemez. Kilit tüm yeni girişleri, HTTP Basic kimlik doğrulamasını, APIops token üretimini ve JWT yenilemeyi engeller. Daha önce üretilmiş JWT veya kişisel API token kendi süresi dolana ya da iptal edilene kadar çalışır; böylece otomatik parola kilidi çalışan otomasyonu kesmez. Acil kesme gerektiğinde Aktif işaretini kaldırın, kişisel token'ı iptal edin veya oturumu kapatın/iptal edin. |
Silinen kullanıcı, bulunduğu takımlardan ve üye olduğu projelerden de sistem tarafından silinir. Bu işlem geri alınamaz, bu nedenle silme işlemi öncesi dikkatli olunmalıdır.
Kullanıcılar Nasıl Giriş Yapar
Giriş ekranının yanı sıra Yönetim API'si HTTP Basic kimlik bilgisi de kabul eder ve ikisi aynı kurallara tabidir.
Veritabanı kullanıcıları HTTP Basic kullanabilir. LDAP kullanıcıları kullanamaz: parolalarına yalnız dizin kefil olabilir, Apinizer bu parolayı hiçbir zaman saklamaz. LDAP hesaplarında tutulan herkese açık DUMMY yer tutucusu, yanlışlıkla Veri tabanı tipinde kalmış eski bir kayıtta dahi parola olarak kabul edilmez. LDAP, pasif, kilitli, bilinmeyen ve yanlış-parola istekleri aynı jenerik 401 yanıtını alır. LDAP kullanıcısı kimliğiyle çalışan script ve entegrasyonlar bunun yerine APIops erişim token'ı almalı ya da veritabanı kullanıcısı kullanmalıdır.
Kilitli veya pasif hesap bu yolların hepsinde reddedilir.
Oturumlar ve Çıkış
Oturum, token'ı geçerliliğini yitirene kadar sürer (24 saat, Beni Hatırla kullanıldıysa 30 gün); kullanıcı çıkış yaptığında, oturum iptal edildiğinde, hesap silindiğinde veya yönetici hesabı pasifleştirdiğinde daha erken sona erer. Otomatik parola kilidi açık bir oturumu sonlandırmaz, ancak kilit kalkana kadar bu oturum yenilenemez.
2026.09.2'ye yükseltme sonrasında mevcut Manager JWT'lerinde güçlendirilmiş kimlik bağı için zorunlu olan değişmez kullanıcı kimliği bulunmaz. Bu token'lar bir kez reddedilir ve kullanıcıların yeniden giriş yapması gerekir. Yeni token, imzalı kullanıcı adını kullanıcının değişmez kayıt kimliğine bağlar; aynı kullanıcı adının silinip yeniden oluşturulması eski oturumu devralamaz.
Çıkış işlemi, oturumun aynı token ile sürdürülememesi için kaydedilir. Temizlik ancak hem yapılandırılmış saklama süresi hem de ilgili token'ın imzalı bitiş zamanı ile saat sapması payı geçtikten sonra yapılır. Okunabilir bitiş zamanı bulunmayan eski kayıtlar otomatik silinmez; bkz. blacklist temizliği.
Parola Kuralları ve Zorunlu Değişim
Veri tabanı tipindeki kullanıcılar için geçerli kurallar (en az/en fazla uzunluk, zorunlu karakter türleri, geçerlilik süresi, geçmiş yeniden kullanım yasağı) Sistem Ayarları → Genel Ayarlar ekranındaki Parola Politikası bölümünden yapılandırılır. Yukarıdaki Parola alanı, girilen değeri o anda geçerli politikaya göre canlı olarak kontrol eder ve karşılanmayan kuralları işaretler. LDAP tipindeki kullanıcılar bu politikanın kapsamı dışındadır.
Var olan bir kullanıcıyı LDAP girişinden Veri tabanı girişine geçirirken aynı kayıtta yeni bir parola girilmesi zorunludur: LDAP hesabının kendine ait bir parolası olmadığından, parola girilmeden yapılan geçiş hesabı kullanılabilir bir parolasız bırakırdı. Parola girilene kadar kayıt reddedilir.
Yönetici Parola Ataması ve Zorunlu Değişim
Bir sistem yöneticisi bu ekrandan bir kullanıcının parolasını değiştirdiğinde, Parola Politikası'ndaki Yönetici Parola Atadığında Değişimi Zorunlu Kıl ayarı açıksa kullanıcı bir sonraki girişinde yeni bir parola belirlemek zorunda bırakılır. Bu davranış otomatiktir; kullanıcı bazında ayrıca işaretlenecek bir seçenek yoktur. Bir yöneticinin kendi parolasını bu ekrandan değiştirmesi bu kurala tabi değildir.
Yönetim Konsolu kullanıcılarının kendilerine ait, e-posta tabanlı bir self-servis parola sıfırlama akışı yoktur. Bir kullanıcı parolasını unutursa, yukarıda anlatıldığı gibi bir yönetici bu ekrandan onun için yeni bir parola belirler.
Süre Dolumu ve Zorunlu Değişim Akışı
Parola Geçerlilik Süresi tanımlıysa, bir kullanıcının parolasının bu süreden daha eski olup olmadığı kontrolü giriş anında yapılır. Parolası süresi dolmuş bir kullanıcı doğru bilgilerle giriş yaptığında oturum yine açılır ancak kısıtlı kalır: Parola ekranı ve bu ekranın ihtiyaç duyduğu birkaç temel istek dışında yapılan her istek reddedilir ve kullanıcı otomatik olarak parola değiştirme sayfasına yönlendirilir. Parolasını değiştirdikten sonra kullanıcının oturumu kapatılır ve yeni parolasıyla tekrar giriş yapması istenir. Bu kısıtlama yalnız tarayıcı oturumuyla sınırlı değildir: parolasını değiştirmesi gereken bir kullanıcı eski parolasıyla APIops erişim jetonu alamaz (jeton isteği "unauthorized_client" hatasıyla reddedilir) ve HTTP Basic kimlik bilgileriyle yapılan istekler de aynı kurala göre denetlenir. Parola işaretlenmeden önce üretilmiş erişim jetonları, iptal edilene kadar geçerliliğini korur.
Süre dolumuna Süre Dolumu Uyarı Süresi kadar gün kalmışsa (zorunlu değişim tetiklenmeden önce), kullanıcı giriş yaptığında kalan gün sayısını belirten bir bilgilendirme uyarısı görür.
Parola Geçmişi
Parola Geçmişi Sayısı sıfırdan büyükse, bir kullanıcı yeni bir parola belirlerken — bu değişiklik kendisi ya da bir yönetici tarafından yapılıyor olsun — en son kullandığı bu kadar paroladan hiçbirini tekrar seçemez; mevcut parolası da bu kontrole dahildir.
Bu akışlardaki her olay (parola değişimi, zorunlu değişim tespiti, reddedilen parola) Giriş Kayıtları'na ve SIEM'e yazılır; bkz. Giriş Kayıtları ve SIEM ve Log Yönlendirme.