Kullanıcılar

bilgi

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ı (User)

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 (Admin)

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ı

Proje Bazlı Organizasyon

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

Takım Bazlı Organizasyon

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

Portal Yöneticisi

Bu yetkiye sahip kullanıcı, konsol üzerindeki Portal Yönetimi (Portal Management) bazındaki API oluşturma, hesaplar, kimlik bilgileri 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.

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.

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.

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. Portal Yöneticisi: Bu yetkiye sahip kullanıcı, konsol üzerindeki Portal Yönetimi (Portal Management) bazındaki API oluşturma, hesaplar, kimlik bilgileri 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. 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 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.
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 her yerde aynı anda etkili olur: kullanıcının açık oturumu bir sonraki isteğinde sona erer, kişisel API erişim token'ları hem Yönetim API'sinde hem Entegrasyon servisinde çalışmaz olur ve yeni token alınamaz. Kilit açıldığında kullanıcı yeniden giriş yapabilir, iptal edilmemiş token'ları yeniden çalışır. Kullanıcıyı pasifleştirmek (Aktif işaretini kaldırmak) da aynı kapsamda etki eder.

uyarı

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. HTTP Basic ile sunulan bir LDAP hesabı, yanlış parola nasıl reddediliyorsa aynı biçimde reddedilir; böylece yanıt hesabın tipini ele vermez. 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); daha erken sona ermesi de mümkündür. Kullanıcı çıkış yaptığında ve yönetici hesabı kilitlediğinde veya pasifleştirdiğinde oturum hemen biter: o oturumdan gelen ilk istek reddedilir ve kullanıcı giriş ekranına döner.

Çıkış işlemi, oturumun aynı token ile sürdürülememesi için kaydedilir. Bu kayıtlar, kurulumun üretebileceği en uzun ömürlü token kadar süreyle saklanır; bunlar için daha kısa bir temizleme süresi tanımlandıysa süre bu nedenle otomatik olarak uzatılır.

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.

bilgi

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.