AGS - AAM

AGS - AAM (Application Access Management), TR7'nin bir vService'in önünde çalışan merkezi kimlik doğrulama ve erişim denetimi modülüdür. AGS etkinleştirilen bir vService'e gelen istek, Kurum Servisi'ne ulaşmadan önce o vService'in erişim akışından geçer: kullanıcıya bir giriş formu gösterilir, kimlik bilgileri seçilen sağlayıcıda doğrulanır, gerekiyorsa ikinci faktör istenir ve doğrulanan kullanıcının kimliği Kurum Servisi'ne aktarılır.

Modülün temel vaadi, kimlik doğrulamayı uygulamanın dışına taşımasıdır. Kurum Servisi'nin kendisinde kod değişikliği, kütüphane kurulumu ya da kimlik sağlayıcı entegrasyonu gerekmez; doğrulama TR7 üzerinde yapılır ve sonuç, Kurum Servisi'nin anladığı biçimde (HTTP başlığı, Basic Auth, Bearer token ya da çerez) isteğe eklenir. Kimlik doğrulaması olmayan eski bir uygulama da, kendi kimlik sistemi olan modern bir uygulama da aynı yolla kapsama alınır.

Erişim akışı tek bir anahtar değil, düzenlenebilir bir adım zinciridir. Hangi formun gösterileceği, kimliğin nerede doğrulanacağı, ikinci faktörün istenip istenmeyeceği ve hangi koşulda hangi dala gidileceği vService başına bir akış şemasında kurulur. Aynı akışta birden çok sağlayıcı yan yana durabilir: kurumsal dizin çalışanlar için, harici bir kimlik sağlayıcısı iş ortakları için, yerel veritabanı ise yükleniciler için kullanılabilir.

Denetim yalnızca giriş anıyla sınırlı değildir. Açılan oturum istemciye bağlanır ve süreleri sınırlanır; başarısız denemeler uyarı, CAPTCHA ve kilit basamaklarından oluşan bir merdivende sayılır; otomatik trafik bot politikalarıyla yanıtlanır. Giriş sayfalarının görünümü ve dili ise ayrı profillerle belirlenir, böylece aynı kurumsal görünüm bütün vService'lerde tek yerden yönetilir.

AGS cihaz genelinde açılıp kapatılan tek bir modül değildir: her HTTP vService için ayrı ayrı etkinleştirilir ve her vService kendi erişim motoruyla çalışır. Akışta ve ayarlarda seçilen profiller ise cihaz genelinde bir kez tanımlanır ve birden çok vService'te ortak kullanılır.

vService üzerinde çalışır

AGS, vService'in HTTP işleme zincirinde çalışır: istek vService tarafından karşılanıp TLS sonlandırıldıktan sonra, Kurum Servisi'ne iletilmeden önce erişim akışından geçer. Bu nedenle AGS yalnızca HTTP tipindeki vService'lerde etkinleştirilir; L7 TCP ve Network (Layer 4) trafiği uygulama katmanında çözümlenmediği için giriş akışına yönlendirilemez.

Aynı vService'te WAF - WAAP ve Bot/DDoS Protection ile birlikte kullanılır; AGS'nin kendi bot koruma politikaları, vService'in Threat Protection bot skorunu okuyabilir.

TR7 Ürünü

AGS - AAM, TR7'nin ayrı lisanslanan dört ürününden biri olan TR7 AAM (Application Access Management) ürünüdür. Ürünler tek başına ya da paketler hâlinde lisanslanır; lisanslama ayrıntıları tr7.com üzerinde yer alır.

TR7 ürünleri: Load Balancer - ADC · WAF - WAAP · AGS - AAM · GTM (Global Traffic Manager)

9

Sağlayıcı Türü

OAuth2, OpenID Connect, SAML 2.0, LDAP, HTTP, Local Database, RADIUS, Portal ve Web Form

14

Hazır OAuth Sağlayıcısı

e-Devlet, Google, Microsoft, Apple, Keycloak, Okta, Auth0 ve diğerleri; uç nokta adresleri TR7'nin kataloğundan gelir

3

MFA Yöntemi

Email OTP · TOTP · HTTP OTP; TOTP'de yedek kodlar ve cihaz güveni

3

Çalışma Modu

Standalone Application · Portal · Portal Application: oturumun kaç uygulamayı kapsadığını belirler

4

Koruma Politikası

Oturum koruma, hesap kilitleme, bot koruma ve CAPTCHA sağlayıcıları ayrı profillerde

18

Form Alanı Türü

Giriş formu alan alan tasarlanır; metinler 10 dillik katalog ve sözlüklerle çözülür

4

Kimlik Aktarım Yolu

Header · Basic Auth · Bearer Token · Cookie; Kurum Servisi'nde değişiklik gerekmez

vService

Etkinleştirme Birimi

Her HTTP vService ayrı açılır ve kendi erişim motoruyla çalışır

Uygulamada kod değişikliği gerekmez

Kimlik doğrulama Kurum Servisi'nin önünde yapılır. Uygulamaya kütüphane eklenmez, kimlik sağlayıcı entegrasyonu yazılmaz; doğrulanan kullanıcının kimliği isteğe başlık, Basic Auth, Bearer token ya da çerez olarak eklenir.

Ayrı bir kimlik sunucusu kurulmaz

Giriş sayfaları, oturum yönetimi, MFA ve kilitleme TR7 üzerinde çalışır. Kurulacak ayrı bir portal uygulaması, yönetilecek ayrı bir oturum veritabanı ya da yönlendirilecek ayrı bir cihaz yoktur.

Profiller bir kez tanımlanır, çok yerde kullanılır

Sağlayıcılar, politikalar, formlar, şablonlar ve sözlükler cihaz genelinde tanımlanır; her vService bunlardan seçer. Bir kurumsal dizin kaydı ya da kurumsal giriş sayfası tek yerde güncellenir, bütün vService'lere yansır.

AGS - AAM Nedir?

Bir kurumun yayımladığı uygulamaların hepsi aynı olgunlukta değildir. Bazısının kendi kullanıcı yönetimi vardır ama kurumsal dizine bağlı değildir; bazısı yalnızca HTTP Basic doğrulama bekler; bazısının hiç kimlik doğrulaması yoktur ve iç ağda açık çalışır; bazısı ise modern bir kimlik sağlayıcısıyla konuşabilir ama çok faktörlü doğrulama, oturum bağlama ya da hesap kilitleme gibi denetimleri kendi başına yapmaz.

Bu tabloda her uygulamaya ayrı ayrı kimlik doğrulama eklemek hem maliyetlidir hem de denetimi dağıtır: kim nereye, hangi kuralla, ne kadar süreyle erişiyor sorusunun tek bir yanıtı kalmaz. AGS, bu soruyu tek bir yere taşır. Kimlik doğrulama ve erişim denetimi uygulamanın içinden alınıp trafiğin geçtiği noktaya, vService'in önüne konur.

Kimlik Doğrulama Nerede Yapılır?

AGS etkin bir vService'e gelen istek üç durumdan birindedir:

• Oturumu yok. İstek erişim akışına yönlendirilir; kullanıcı giriş sayfasını görür.
• Oturumu var ve geçerli. İstek akışa hiç girmez; kimlik bilgileri isteğe eklenip Kurum Servisi'ne iletilir.
• Oturumu var ama geçersiz. Oturum süresi dolmuş, istemciye bağlanmış imza değişmiş ya da eşzamanlı oturum sınırı aşılmışsa oturum düşürülür ve kullanıcı yeniden akışa alınır.

Bu ayrım AGS'nin maliyetini belirler: doğrulama her istekte değil, oturum başına bir kez yapılır. Oturumu olan kullanıcının isteği yalnızca bir oturum denetiminden ve kimlik ekleme adımından geçer.

Oturum çerezi imzalıdır ve imza doğrulaması trafik motorunda yapılır: imzası tutmayan ya da süresi dolmuş bir çerez oturum deposuna hiç ulaşmaz. Çerez ayrıca hangi vService'in yayımladığını taşır; bir vService'e ait çerez, ona güvenmeyen başka bir vService'te kabul edilmez. AGS'nin kendi çerezleri Kurum Servisi'ne iletilmeden önce istekten sökülür, böylece ele geçirilmiş bir Kurum Servisi oturum çerezini okuyamaz.

WAF ve Bot/DDoS ile Farkı

Üç modül de vService'in önünde durur, ancak farklı soruları yanıtlar:

WAF - WAAP İstek zararlı mı?

İsteğin içeriğine bakar: enjeksiyon, betik çalıştırma, protokol ihlali gibi saldırı desenlerini arar. Kullanıcının kim olduğunu sormaz.

Bot/DDoS Protection İsteği kim gönderiyor?

İsteğin kaynağına ve hacmine bakar: ne kadar geliyor, nereden geliyor, gönderen bir tarayıcı mı yoksa otomasyon mu. Kimlik sormaz, davranış ölçer.

AGS - AAM Bu kullanıcı kim ve girebilir mi?

İsteğin sahibine bakar: kullanıcı kimliğini doğrular, ikinci faktör ister, oturumu yönetir ve kimliği Kurum Servisi'ne taşır. İsteğin içeriğiyle ilgilenmez.

Üç katman birbirinin yerine geçmez

Doğrulanmış bir kullanıcı da zararlı istek gönderebilir; bu yüzden AGS, WAF'ın yerini tutmaz. Aynı biçimde WAF, kimliği doğrulanmamış bir kullanıcının erişimini engellemez. Üçü aynı vService'te birlikte çalışır ve her biri kendi sorusunu sorar.

Aynı vService'te üçü birlikte açıldığında sıra şöyledir: önce bot skoru hesaplanır, sonra AGS oturum doğrulaması yapılır, en sonda WAF incelemesi çalışır. Bu sıranın iki sonucu vardır:

• Kimlik, bot kararını yumuşatır. AGS oturumu doğrulanmış bir kullanıcının bot skoru güven indirimi alır; giriş yapmış kullanıcı, anonim bir istemciyle aynı eşikte değerlendirilmez.
• AGS'nin kendi sayfaları WAF ve bot yaptırımının dışındadır. Giriş formu, CAPTCHA ve OTP trafiği parola, kod ve token taşıdığından WAF incelemesine sokulmaz; bu içerikler WAF öğrenmesine ve istatistiklerine de girmez. Aynı biçimde Threat Protection'ın bot sütunu giriş yüzeyinde yaptırım önermez; otomatik trafiğe yanıtı AGS'nin kendi bot koruma politikaları verir, çünkü doğru yanıt bu yüzeyde engelleme değil, forma CAPTCHA eklemektir.

TR7'de AGS

AGS, TR7'de üç parçanın birleşimidir:

• vService başına erişim servisi. AGS bir vService'te açıldığında o vService'e ait bir erişim akışı, ayarlar kümesi ve ayrı bir erişim motoru oluşur. Motor yalnızca o vService'in giriş trafiğini işler.
• Cihaz genelinde profiller. Sağlayıcılar, sunucu kayıtları, yerel veritabanları, MFA profilleri, koruma politikaları, formlar, şablonlar, sözlükler ve entegrasyon profilleri cihaz genelinde tanımlanır; vService'ler bunları paylaşır.
• vService başına izleme yüzeyleri. Oturumlar, kilitler, TOTP kayıtları, denetim olayları, canlı sayaçlar ve motor durumu her vService için ayrı izlenir.

Neden İhtiyaç Duyulur?

İhtiyaç	AGS'nin karşılığı
Kimlik doğrulaması olmayan eski uygulamayı kapsama almak	Uygulamaya dokunmadan önüne giriş akışı konur; kimlik başlık ya da Basic Auth ile aktarılır
Dağınık kullanıcı yönetimini tek yere toplamak	Kurumsal dizin, harici kimlik sağlayıcı ve yerel veritabanı aynı akışta yan yana kullanılır
Çok faktörlü doğrulamayı her uygulamaya ayrı ayrı yazmamak	MFA adımı akışa eklenir; uygulama bundan habersizdir
Bir kez giriş, çok uygulamaya erişim	Portal modundaki bir vService kimliği, kendisine güvenen uygulama vService'leriyle paylaşır
Parola deneme saldırılarını yavaşlatmak	Başarısız denemeler kapsam bazında sayılır; uyarı, CAPTCHA ve kilit basamakları devreye girer
Çalınan oturum çerezini kullanılamaz kılmak	Oturum istemciye bağlanır; imza değişirse oturum düşürülür
Giriş sayfasını kurumsal görünüme uydurmak	Şablon ve sözlük profilleriyle logo, renk, metin ve dil tek yerden yönetilir
Kimin ne zaman giriş yaptığını denetlemek	Denetim olayları vService'te tutulur ve SIEM ya da syslog hedeflerine iletilir

Nasıl Çalışır?

01 · GirişOturumu olmayan istek akışa alınırAkışın form adımı çalışır; tasarlanan giriş formu, vService'in sayfa şablonu görünümü ve sözlüğünün diliyle gösterilir. Kullanıcının girdiği değerler sonraki adımlara girdi olur.

02 · DoğrulamaKimlik seçilen sağlayıcıda sınanırAuthentication provider adımı, kullanıcıyı kurumsal dizinde, harici bir kimlik sağlayıcısında, bir HTTP servisinde ya da yerel veritabanında doğrular. Başarısız denemeler kilitleme politikalarınca sayılır ve gerekirse CAPTCHA sorulur.

03 · İkinci faktörGerekiyorsa MFA adımı çalışırAkışta bir MFA adımı varsa e-posta ya da SMS ile tek kullanımlık kod gönderilir, kimlik doğrulayıcı uygulamasından kod istenir ya da özel bir HTTP servisi üzerinden doğrulama yapılır.

04 · OturumAkış Allow adımına ulaşırsa oturum açılırOturum koruma politikası oturumu istemciye bağlar, sürelerini ve eşzamanlılığını sınırlar. Kullanıcının öznitelikleri oturuma yazılır ve sonraki isteklerde yeniden doğrulama yapılmaz.

05 · Kurum ServisiKimlik isteğe eklenir ve istek iletilirBackend SSO profiline göre kullanıcı kimliği başlık, Basic Auth, Bearer token ya da çerez olarak isteğe eklenir. Kurum Servisi'nin oturum kaybı ve çıkışı izlenir; denetim olayı kaydedilir.

Oturumu olan kullanıcı akışı yeniden görmez

Akış yalnızca geçerli bir oturumu olmayan istekler için çalışır. Oturumu olan kullanıcının isteği doğrudan beşinci aşamaya gider: kimlik bilgileri eklenir ve istek Kurum Servisi'ne iletilir. Bu nedenle giriş maliyeti istek başına değil, oturum başına oluşur.

Varsayılan akış kullanıcıyı içeri almaz

AGS bir vService'te ilk kez açıldığında oluşan varsayılan akış yalnızca hazır Basic Login formundan oluşur ve formun çıkışı Deny adımına bağlıdır; akışta Allow adımına ulaşan bir yol yoktur. Bu, yanlışlıkla açılan bir AGS'nin trafiği doğrulamasız geçirmesini engelleyen bilinçli bir başlangıçtır. Kullanıcıların Kurum Servisi'ne ulaşabilmesi için akışa bir kimlik doğrulama adımı eklenip Allow adımına bağlanması gerekir (bkz. How to Enable AGS?).

Erişim Akışı

Erişim akışı, Flowchart sekmesindeki bir tuvalde adımların birbirine bağlanmasıyla kurulur. Akış Start düğümünden başlar ve her adımın çıkışları başka bir adıma ya da akışın iki bitiş düğümünden birine bağlanır. Çıkış sayısı adım türüne göre değişir: kimlik doğrulama ve MFA adımlarının success ve fail çıkışları, karar adımının yes ve no çıkışları vardır; form ve öznitelik atama adımlarının tek bir çıkışı bulunur.

Akışta kullanılan adımlar ve çıkışları aşağıdaki gibidir:

Adım	Çıkışları	Ne yapar
Start	Tek çıkış	Akışın giriş noktası.
Form	Tek çıkış	Kullanıcıya bir giriş formu gösterir ve girilen değerleri sonraki adımlara taşır. Değerlere %AGS_USER_INPUT(alan adı) ifadeleriyle erişilir.
Authentication Provider	success · fail	Kimliği seçilen sağlayıcı profilinde doğrular. Akışta birden çok kez kullanılabilir; her biri farklı bir sağlayıcıya bağlanabilir.
MFA	success · fail	İkinci faktörü doğrular. Kimlik doğrulama adımından sonra çalışır.
Decision Point	yes · no	Bir koşula göre akışı iki dala ayırır.
Switch	Her dal için bir çıkış · noMatch	Bir değere göre akışı çok dala ayırır; hiçbir dal eşleşmezse noMatch çıkışı işletilir.
Assign User Attributes	Tek çıkış	Oturuma kullanıcı özniteliği yazar; kimlik doğrulama yapmaz.
Backend SSO (Re)Sync	Tek çıkış	Kurum Servisi'nin oturumunu yeniden eşitler; Backend SSO profilinin Re-sync stratejisinde kullanılır.
Allow	Çıkışı yok	Akışın olumlu bitişi. Oturum açılır ve kullanıcı Kurum Servisi'ne ulaşır.
Deny	Çıkışı yok	Akışın olumsuz bitişi. Erişim reddedilir.

Adımlar kullanıcıya ayrı sayfalar olarak sunulur ve her biri AGS kök yolunun altında kendi adresinde çalışır: form adımı /form, kimlik doğrulama adımı /auth (OAuth2 ve OpenID Connect türlerinde /oauth), MFA adımı /mfa, karar ve dallanma adımları /security-check, öznitelik atama adımı /context, Allow adımı ise /access-check yoluna karşılık gelir. Aynı yolu paylaşan ikinci bir adım eklendiğinde yolun sonuna bir sıra soneki eklenir.

Akış tek bir sağlayıcıyla sınırlı değildir

Bir adımın fail çıkışı başka bir sağlayıcı adımına bağlanarak yedekli doğrulama kurulur: kurumsal dizinde bulunamayan kullanıcı yerel veritabanında aranır, orada da bulunamazsa Deny adımına düşer. Aynı yapı, farklı kullanıcı gruplarını farklı sağlayıcılara yönlendirmek için de kullanılır.

Akış Çizilerek Kurulur

Erişim akışı bir yapılandırma dosyasında ya da uzun bir formda değil, tuval üzerinde kurulur. Flowchart sekmesi vService'in giriş mantığını olduğu gibi çizer: hangi adımdan hangi adıma gidildiği, hangi profilin hangi kutuda çalıştığı ve kullanıcının hangi yoldan Allow'a, hangi yoldan Deny'a düştüğü tek bakışta görülür.

AGS Flowchart Erişim Akışı Tuvali

Tuval hem okuma hem düzenleme yüzeyidir. Edit Mode kapalıyken akış salt okunur bir şema olarak incelenir; açıldığında aynı şema üzerinde çalışılır:

Adımlar ekleyip bağlanır

Add AGS action ile yeni bir adım tuvale bırakılır; adımların çıkış noktaları sürüklenerek hedef adıma bağlanır. Kimlik doğrulama ve MFA adımlarının success ve fail çıkışları ayrı ayrı bağlandığı için "başarısız olursa ne olsun" sorusu şemada görünür hâle gelir.

Profil kutunun içinde seçilir

Her adım kutusu, çalıştıracağı profili kendi üzerinde taşır: form kutusunda giriş formu, sağlayıcı kutusunda kimlik doğrulama profili. Profilin yanındaki bilgi simgesiyle ayarlarının özeti açılır, ekleme kısayoluyla tuvalden ayrılmadan yeni profil tanımlanır.

Bitişler renkle ayrılır

Akışın iki bitişi tuvalde açıkça işaretlidir: yeşil Allow kullanıcıyı içeri alır, kırmızı Deny erişimi reddeder. Allow adımına ulaşan bir yol yoksa bu durum şemada hemen fark edilir; varsayılan akışın kullanıcıyı neden içeri almadığı da buradan okunur.

Kullanıcı öznitelikleri yan panelde izlenir

Sağdaki User attributes paneli, akışın ürettiği ve kullandığı kullanıcı alanlarını listeler: hangi öznitelik zorunlu, nerede üretiliyor, kaç yerde kullanılıyor. Needs attention süzgeci, doldurulması beklenen ama akışta karşılığı olmayan alanları ayıklar.

Çalışma modu tuvalin üstünde durur

vService'in Standalone Application, Portal ya da Portal Application modu tuvalin başında bir rozet olarak görünür. Mod, tuvalin neyi çizeceğini de belirler: kimliğini portaldan devralan bir uygulamanın kendi giriş akışı yoktur.

Değişiklik kaydedilene kadar uygulanmaz

Tuvalde yapılan düzenlemeler Save ile kaydedilir; kaydedilene kadar çalışan akış değişmez. Böylece akış canlı trafiği etkilemeden yeniden düzenlenir ve tek seferde yürürlüğe alınır.

Akış şeması aynı zamanda belgedir

Bir erişim akışının nasıl çalıştığını anlatmak için ayrı bir doküman tutmak gerekmez: tuvalin kendisi, hangi kullanıcının hangi adımlardan geçtiğini gösteren güncel bir şemadır. Denetim ve devir teslim sırasında okunacak tek yer burasıdır.

Üç Çalışma Modu

Bir AGS etkin vService'in gateway modu, açılan oturumun kaç uygulamayı kapsadığını belirler:

Standalone Application Varsayılan

vService kendi giriş akışını çalıştırır ve açtığı oturum yalnızca kendisini kapsar. Tek bir uygulamayı korumak için kullanılır; başka vService'lerle oturum paylaşmaz.

Portal Kimliğin kaynağı

Giriş akışını çalıştıran ve kimliği üreten merkezdir. Kullanıcı bir kez burada giriş yapar; portal, kendisine güvenen uygulama vService'lerine kimliği devreder. Portalın yayımladığı uygulamalar ayrıca burada listelenir ve her biri için erişim biçimi seçilir.

Portal Application Kimliğin tüketicisi

Kendi giriş akışını çalıştırmaz; kimliği güvendiği portaldan devralır. Güvenilen portallar bu vService'te ayrıca tanımlanır ve liste boş bırakılamaz.

Kurum genelinde tek oturum açma (SSO) senaryosu bu iki modun birlikte kullanılmasıyla kurulur: bir vService Portal modunda giriş noktası olur, korunacak uygulamalar ise Portal Application modunda o portala bağlanır. Üç modun akış tuvalindeki karşılıkları Standalone Application, Portal ve Portal Application sayfalarında anlatılmıştır.

Temel Yapı Taşları

Erişim Akışı vService başına

Adımların ve dalların tanımlandığı şema. Hangi formun gösterileceğini, kimliğin nerede doğrulanacağını ve hangi koşulda hangi yola gidileceğini belirler.

Kimlik Doğrulama Profilleri Cihaz geneli

Sağlayıcı profilleri kimliğin nerede ve nasıl doğrulanacağını, sunucu kayıtları bağlantı ayarlarını, yerel veritabanları TR7 üzerinde tutulan hesapları, MFA profilleri ise ikinci faktörü tanımlar.

Koruma Politikaları Cihaz geneli

Oturumun istemciye nasıl bağlanacağı, başarısız denemelerin nasıl sayılacağı, otomatik trafiğe nasıl yanıt verileceği ve hangi CAPTCHA servisinin kullanılacağı ayrı profillerde tutulur.

Sayfa ve Dil Profilleri Cihaz geneli

Giriş formunun alanları, erişim sayfalarının logo, renk ve arka plan görünümü ile metinlerin çok dilli çözülmesi ayrı profillerde tanımlanır.

Entegrasyon Profilleri Cihaz geneli

Kimliğin Kurum Servisi'ne hangi yolla aktarılacağı, hangi olaylarda alarm üretileceği ve denetim loglarının nereye iletileceği bu profillerde belirlenir.

Erişim Motoru vService başına

Giriş sayfalarını sunan, doğrulamayı yürüten ve oturumları tutan bileşen. AGS açıldığında vService için kendiliğinden oluşturulur, vService'in belleğinin yarısını kullanır ve trafik motoruyla yerel soket üzerinden konuşur; durumu ve bakımı Engine sekmesinden izlenir.

Kimlik Doğrulama Seçenekleri

Akışa eklenen her Authentication Provider adımı bir sağlayıcı profiline bağlanır. Profilin türü, kimliğin nerede ve hangi protokolle doğrulanacağını belirler:

Tür	Kimliği nerede doğrular	Tipik kullanım
OAuth2	Harici yetkilendirme sunucusu	Hazır katalogdaki sağlayıcılar ya da özel bir OAuth2 servisi; kimlik belirteci üretmeyen sağlayıcılar için
OpenID Connect	Kimlik belirteci üreten harici sağlayıcı	Keycloak, Okta, Auth0, Microsoft Entra ID gibi kurumsal kimlik sağlayıcıları; Apple yalnızca bu türde listelenir
SAML 2.0	Kurumsal kimlik sağlayıcısı (IdP)	SAML tabanlı kurumsal SSO altyapıları
LDAP	Dizin sunucusu	Active Directory ve OpenLDAP; grup üyeliğiyle yetkilendirme
HTTP	Kurumun kendi doğrulama API'si	Özel bir kimlik servisine istek atılıp yanıtına göre karar verilmesi
Local Database	TR7 üzerindeki yerel hesaplar	Dış dizine bağlanmayan yüklenici, iş ortağı ya da test hesapları
RADIUS	RADIUS sunucusu	NPS, FreeRADIUS ve RADIUS konuşan MFA sunucuları
Portal	Portal modundaki başka bir vService	Kurum içi tek oturum açma
Web Form	Mevcut bir uygulamanın giriş formu	Kimlik doğrulama API'si olmayan, yalnızca giriş sayfası bulunan uygulamalar

Doğrulanan kullanıcının öznitelikleri oturuma yazılır. AGS'nin 19 standart kullanıcı alanı vardır (kullanıcı adı, e-posta, görünen ad, ad, soyad, telefon, şirket, birim, unvan, personel numarası, grup üyelikleri ve diğerleri); çoğu türde bu eşleme hazır gelir, gerektiğinde her öznitelik elle eşlenir. Standart dışı adlar vService'te özel kullanıcı alanı olarak tanımlanır.

Oturuma yazılan değerler yalnızca Kurum Servisi'ne aktarılmakla kalmaz; %AGS_USERNAME, %AGS_EMAIL, %AGS_GROUPS ve %AGS_USER_ATTR(ad) gibi Smart Variables ifadeleriyle vService'in koşullarında ve aksiyonlarında da kullanılır. Böylece kullanıcının grubuna göre farklı Kurum Servisi'ne yönlendirme ya da yola göre erişim kısıtı gibi kurallar yazılır.

İkinci Faktör

Multi-Factor Authentication (MFA) profilleri üç yöntem sunar: Email OTP kodu e-posta ile gönderir, TOTP kimlik doğrulayıcı uygulamasından kod ister (yedek kodlar ve cihaz güveni seçenekleriyle), HTTP OTP ise kodun gönderimini kurumun kendi servisine devreder ve SMS gibi kanallar bu yolla kullanılır.

Koruma Katmanları

Giriş akışı tek başına yeterli değildir: parola deneme saldırıları, çalınan oturum çerezleri ve otomatik trafik ayrıca ele alınır. Dört profil ailesi bu işi paylaşır:

Katman	Ne yapar
Session Protection Policies	Oturumu istemciye bağlar (None, IP Address, IP + User Agent ya da smart değişkenlerden oluşan Composite), oturum ve boşta kalma sürelerini sınırlar, kullanıcı başına eşzamanlı oturum sayısını denetler. Bağlama imzası değişirse oturum düşürülür; eşzamanlılık sınırı aşıldığında yeni oturum reddedilir, en eski oturum kapatılır ya da kullanıcının bütün oturumları düşürülür.
Account Lockout Policies	Başarısız denemeleri seçilen kapsamda (kullanıcı adı, IP, ikisinin birleşimi ya da özel bir kombinasyon) sayar ve üç basamaklı bir merdiven uygular: önce uyarı, sonra CAPTCHA, sonra kilit. Tekrarlanan kilitlemelerde süre katlanır.
Bot Protection Policies	Giriş sayfalarına yönelen otomatik trafiği tetikleyicilerle yakalar (her istek, istek oranı, başarısız doğrulama oranı ya da bot skoru) ve reddetme, yavaşlatma, engelleme, bant genişliği sınırlama, CAPTCHA ya da özel içerik gösterme aksiyonlarından birini uygular.
CAPTCHA Providers	Kilitleme merdiveninin CAPTCHA basamağında ve bot politikalarının CAPTCHA aksiyonunda kullanılacak doğrulama servisini tanımlar: TR7'nin kendi CAPTCHA'sı ya da Google reCAPTCHA, hCaptcha, Cloudflare Turnstile.

Politikalar hazır profillerle gelir

TR7, her aile için hazır profillerle gelir: 4 kilitleme, 6 bot koruma, 4 oturum koruma ve 2 CAPTCHA profili. AGS bir vService'te ilk kez açıldığında bunlardan Standard Session Protection, Default Username Lockout, Default IP Lockout, Standard Rate Limiting, Bot Score CAPTCHA Challenge ve Bot Score Deny kendiliğinden bağlanır.

Hazır profiller ekranların listelerinde görünmez; yalnızca vService ayarlarındaki ve akıştaki seçicilerde yer alır ve düzenlenemez. Farklı değerler gerektiğinde ilgili ekranda yeni bir profil oluşturulup vService'e bağlanır.

Kurum Servisi'ne Kimlik Aktarımı

Doğrulanan kullanıcının kimliği, Backend SSO Configurations profiline göre isteğe eklenir. Bir profil birden çok enjeksiyon taşıyabilir ve her enjeksiyon kendi koşuluna bağlanabilir:

Yöntem	Ne ekler
Header	Adı ve değeri belirlenen bir HTTP başlığı; istemciden gelen aynı adlı başlık önce kaldırılır
Basic Auth	kullanıcı:parola değerinden üretilen Authorization: Basic … başlığı
Bearer Token	Authorization: Bearer … başlığı; başlık adı gerektiğinde değiştirilir
Cookie	Adı ve değeri belirlenen bir çerez; istemciden gelen aynı adlı çerez önce kaldırılır

Profil ayrıca Kurum Servisi'nin kendi oturumunun kaybedilmesini ve kullanıcının uygulama içinden çıkış yapmasını izler. Oturum kaybında kullanıcı ya oturumu kapatılarak bilgilendirilir ya da arka plandaki oturum yeniden eşitlenir; uygulamadan çıkışta ise AGS oturumu da kapatılır ve kullanıcı belirlenen adrese yönlendirilir.

İzleme ve Görünürlük

Yüzey	Ne gösterir
Dashboard	vService'in oturum, kimlik doğrulama, kilitleme, MFA, sistem ve bot metriklerinin zaman aralığı seçilebilir panosu
Live Stats	Saniyede bir yenilenen erişim, oturum, kimlik doğrulama, CAPTCHA, MFA, kilitleme ve depolama sayaçları
Sessions	Açık oturumların listesi ve oturum sonlandırma
Lockout	Başarısız deneme sayaçları ve etkin kilitler; kilitlerin kaldırılması ve sayaçların sıfırlanması
TOTP	Kullanıcıların kimlik doğrulayıcı uygulaması kayıtları ve kayıt sıfırlama
Audit Logs	Kimlik doğrulama, MFA, kilitleme ve erişim kararı olayları
Bot Protection	Bot koruma politikalarının canlı sayım ve engel tabloları
Engine	Erişim motorunun cihaz başına durumu ve bakım işlemleri

AGS için cihaz genelinde ayrı bir log ya da rapor ekranı bulunmaz: denetim olayları vService'in Audit Logs sekmesinde incelenir ve Log Forwarding profilleriyle SIEM ve syslog hedeflerine iletilir. Operatöre haber verilmesi gereken durumlar ise Notification Profiles ile tanımlanır.

Denetim olayları cihazda saatlik dosyalar hâlinde tutulur ve iletim bu dosyaları izleyerek yapılır. Bu nedenle denetim kaydı da oturum ve kilit listeleri gibi cihaz başınadır; cluster görünümü iki cihazın kayıtları birleştirilerek üretilir.

Yönetim ve Operasyon

• Etkinleştirme vService başınadır. AGS, AGS-Enabled vService List ekranından topluca ya da vService formundan tek tek açılır. Her vService için ayrı bir erişim motoru oluşturulur.
• Ayrı bir yetki alanı yoktur. AGS ekranları Load Balancer alanında izleme yetkisiyle açılır; kayıtların getirilmesi ve değiştirilmesi de Load Balancer yetki alanına bağlıdır. Yalnızca WAF yetkisi olan kullanıcıda AGS ekranları açılmaz.
• Lisans yalnız yazmayı kapatır. AGS lisansı yokken kayıtların okunması engellenmez; yeni kayıt oluşturma, değiştirme ve motor bakımı reddedilir. Bir vService'te AGS'nin kapatılması da lisanstan bağımsızdır.
• Profiller cluster cihazları arasında eşitlenir. Değişiklikler vService yapılandırmasıyla birlikte dağıtılır; kullanıcı işlemleri User Logs ekranında izlenir.
• Oturumlar, kilitler ve TOTP kayıtları cihaz başınadır. Bu veriler eşitlenmez; her cihaz kendi kayıtlarını tutar. Ekranlar iki cihazı sorgu anında birleştirerek tek liste gösterir ve silme işlemleri iki cihaza birden uygulanır.
• AGS kapatıldığında yapılandırma silinmez. Akış, politika, şablon ve sözlük seçimleri vService var olduğu sürece saklanır; AGS yeniden açıldığında aynı yapılandırma geçerli olur.

Öne Çıkan Özellikler

Dokuz sağlayıcı türüKurumsal dizinden harici kimlik sağlayıcısına, yerel hesaplardan mevcut giriş formuna kadar tek akışta.

14 hazır OAuth sağlayıcısıUç nokta adresleri ve öznitelik eşlemeleri TR7 tarafından sağlanır; yalnız istemci bilgileri girilir.

Düzenlenebilir akışAdımlar ve dallar bir tuvalde kurulur; başarısız doğrulama başka bir sağlayıcıya yönlendirilebilir.

Çok faktörlü doğrulamaE-posta kodu, kimlik doğrulayıcı uygulaması ve kuruma özel HTTP kanalı; yedek kodlar ve cihaz güveni.

Kurum içi tek oturum açmaPortal modundaki bir vService, kimliği kendisine güvenen uygulama vService'leriyle paylaşır.

Oturum bağlamaOturum istemciye bağlanır; çalınan çerez farklı bir istemcide kullanılamaz.

Kademeli hesap kilitlemeUyarı, CAPTCHA ve kilit basamakları; tekrarlanan kilitlemelerde katlanan süre.

Giriş sayfasına özel bot korumasıDört tetikleyici ve altı aksiyon; Threat Protection bot skoru da tetikleyici olarak kullanılır.

Kurumsal görünümLogo, renk, arka plan ve metinler şablon profilleriyle tek yerden yönetilir.

Çok dilli erişim sayfalarıOn dillik katalog ve çeviri anahtarlarıyla aynı sayfa farklı dillerde sunulur.

Dört kimlik aktarım yoluHeader, Basic Auth, Bearer token ve çerez; Kurum Servisi'nde değişiklik gerekmez.

Denetim kaydı ve iletimGiriş, MFA, kilitleme ve erişim kararı olayları kaydedilir ve SIEM ya da syslog hedeflerine iletilir.

Kullanım Senaryoları

Aşağıdaki başlıklar kurumların AGS'ye en sık başvurduğu durumlardır. Her biri bir soruna karşılık gelir; çözüm, uygulamaya dokunmadan TR7 üzerinde kurulur.

"Uygulamanın kimlik doğrulaması yok" Giriş ekranı ekleme

Yıllar önce yazılmış, iç ağda herkese açık çalışan bir uygulama. Kodu değiştirilemiyor, geliştiricisi yok. AGS açılır, akışa kurumsal dizin adımı eklenir ve uygulamanın önüne giriş ekranı gelir. Kullanıcı adı Kurum Servisi'ne başlıkla aktarılır; uygulama isterse kullanıcıyı bu başlıktan tanır, istemezse hiçbir şey yapmaz.

"Dizinimiz var ama MFA'mız yok" İkinci faktör

Kurumda Active Directory ya da RADIUS çalışıyor, kullanıcılar zaten orada. Eksik olan tek şey ikinci faktör. AGS akışında dizin adımının ardına bir MFA adımı eklenir: kod e-posta ile gönderilir, kimlik doğrulayıcı uygulamasından istenir ya da kurumun kendi SMS servisi üzerinden iletilir. Dizine tek bir kayıt eklenmez, uygulamalara tek satır kod yazılmaz.

"Giriş sayfamız bot yağmuru altında" CAPTCHA + kilitleme

Giriş formuna sürekli otomatik istek geliyor, loglar başarısız denemeyle doluyor. Bot koruma politikası formu CAPTCHA'ya yönlendirir, kilitleme politikası ise denemeleri sayar: önce uyarı, sonra CAPTCHA, sonra kilit. CAPTCHA TR7'nin kendi servisiyle ya da reCAPTCHA, hCaptcha veya Turnstile ile çözülür.

"Çalışan her sabah beş kez parola giriyor" Kurum içi SSO

İntranet, rapor aracı, talep sistemi, wiki; her biri ayrı giriş istiyor. Bir vService portal moduna alınır, diğerleri portal application moduna geçip ona bağlanır. Kullanıcı sabah bir kez giriş yapar, gün boyunca uygulamalar arasında yeniden parola sorulmaz.

"Yükleniciye dizinde hesap açmak istemiyoruz" Karma sağlayıcı

Dış paydaşın kurumsal dizinde yeri yok, ama uygulamaya erişmesi gerekiyor. Aynı akışta çalışanlar dizinde, iş ortakları harici kimlik sağlayıcısında, yükleniciler ise TR7'nin yerel veritabanında doğrulanır. Yüklenici hesabı iş bitince tek ekrandan kapatılır; dizin hiç kirlenmez.

"Herkes aynı yere gitmesin" Kimliğe göre yönlendirme

Aynı adres altında farklı ekiplerin farklı ortamlara gitmesi isteniyor. Doğrulanan kullanıcının grubu, kullanıcı adı ve öznitelikleri smart değişkenlerle vService koşullarına taşınır; yönlendirme, erişim kısıtı ve başlık ekleme kuralları bu değerlere göre yazılır.

"Vatandaş e-Devlet ile girsin" e-Devlet + çok dil

Kamuya açık bir hizmette kimlik doğrulaması e-Devlet üzerinden yapılmak isteniyor. Hazır e-Devlet sağlayıcısı akışa eklenir; giriş sayfaları kurumsal şablonla ve kullanıcının diline göre sunulur.

"Uygulama kendi oturumunu düşürüyor" Backend SSO

Kullanıcı AGS tarafında hâlâ oturumlu, ama uygulama kendi oturumunu kaybedip giriş ekranına atıyor. Backend SSO profili bu durumu tanır ve ya kullanıcıyı temiz bir biçimde çıkarır ya da arka plandaki oturumu sessizce yeniden eşitler.

Terminoloji

Terim	Açıklama
Erişim servisi	Bir vService'in AGS yapılandırmasının bütünü: akış, ayarlar ve bağlı profiller.
Erişim akışı (flow)	Giriş adımlarının ve dallarının tanımlandığı şema. Form, kimlik doğrulama ve MFA adımlarıyla Allow ve Deny bitişlerinden oluşur.
Erişim motoru (engine)	Giriş sayfalarını sunan, doğrulamayı yürüten ve oturumları tutan bileşen. vService başına ayrıdır.
Gateway Mode	vService'in çalışma modu: Standalone Application, Portal ya da Portal Application.
Authentication Provider	Kimliğin nerede ve hangi protokolle doğrulanacağını tanımlayan profil; akışta bir adım olarak kullanılır.
Authentication Server	Bir dizin, RADIUS ya da HTTP sunucusunun adres, port ve bağlantı ayarlarını tutan kayıt. Sağlayıcı profilleri bu kayda bağlanır.
Local Database	Kullanıcı hesaplarının TR7 üzerinde tutulduğu yerel veritabanı; parola politikası veritabanı başına tanımlanır.
MFA	Parolanın yanına eklenen ikinci doğrulama adımı: Email OTP, TOTP ya da HTTP OTP.
Policy Scope	Kilitleme politikasının başarısız denemeleri hangi anahtar için saydığı: kullanıcı adı, IP, ikisinin birleşimi ya da özel bir kombinasyon.
Session Binding	Oturumun istemciye bağlanma biçimi. Bağlama imzası değişirse oturum düşürülür.
Backend SSO	Doğrulanan kullanıcının kimliğinin Kurum Servisi'ne aktarılması; dört enjeksiyon yolu bulunur.
User Attribute	Sağlayıcı yanıtından oturuma yazılan kullanıcı bilgisi (kullanıcı adı, e-posta, grup gibi). Standart dışı adlar vService'te özel kullanıcı alanı olur.
Page Template	Erişim sayfalarının logo, renk, üst/alt bilgi ve arka plan görünümünü belirleyen profil.
Dictionary	Erişim sayfalarındaki metinlerin çok dilli karşılıklarını tutan profil.
Trusted Portal	Portal Application modundaki bir vService'in kimliği devralmaya izin verdiği portal. Liste boş bırakılamaz.
AGS kök yolu	Erişim akışının sayfalarının yayımlandığı yol; varsayılanı /ags-portal'dır ve vService başına değiştirilir.
Decision point · Switch	Akışı koşula göre iki dala ya da bir değere göre çok dala ayıran adımlar.
Assign User Attributes	Oturuma kullanıcı özniteliği yazan, kimlik doğrulaması yapmayan akış adımı. Yazılan alanlara %AGS_USER_ATTR(ad) ile erişilir.

Bölümler

Başlangıç

How to Enable AGS?

Bir HTTP vService'te AGS'nin iki yoldan etkinleştirilmesi, oluşan varsayılan yapılandırma ve motor, trafiğe etkisi ve AGS'nin kaldırılması.

→

vService Bazında İzleme ve Yönetim

AGS-Enabled vServices

AGS etkin bir vService'in yönetim ekranı: on sekmenin işbölümü, erişim yolları ve yetkileri.

→

Dashboard

Oturum, kimlik doğrulama, kilitleme, MFA, sistem ve bot metriklerinin zaman aralığı seçilebilir panosu.

→

AGS Management

vService'in AGS yapılandırmasının bölüm bölüm okunduğu ve pencerelerle düzenlendiği yüzey.

→

Flowchart

Giriş akışının şema olarak görüntülendiği ve düzenlendiği tuval; üç gateway modunun akış karşılıkları.

→

Live Stats

Saniyede bir yenilenen erişim, oturum, doğrulama, CAPTCHA, MFA, kilitleme ve depolama sayaçları.

→

Sessions

Erişim motorunun açtığı oturumların listesi ve oturum sonlandırma.

→

Lockout

Başarısız deneme sayaçları ve etkin kilitler; kilitlerin kaldırılması ve sayaçların sıfırlanması.

→

TOTP

Kullanıcıların kimlik doğrulayıcı uygulaması kayıtları ve kayıt sıfırlama.

→

Audit Logs

Kimlik doğrulama, MFA, kilitleme ve erişim kararı olaylarının denetim kaydı.

→

Bot Protection

Bot koruma politikalarının canlı sayım ve engel tabloları.

→

Engine

Erişim motorunun cihaz başına durumu ve bakım işlemleri.

→

Cihaz Geneli Profiller

AGS-Enabled vService List

AGS etkin vService'lerin tek listede toplandığı görünüm; toplu etkinleştirme ve kaldırma.

→

Authentication

Dokuz türde kimlik doğrulama sağlayıcıları, sunucu bağlantı kayıtları, yerel kullanıcı veritabanları ve MFA profilleri.

→

Protection Policies

Oturum koruma, hesap kilitleme ve bot koruma politikaları ile CAPTCHA sağlayıcıları.

→

Pages & Language

Giriş formlarının alan alan tasarımı, erişim sayfalarının görünüm şablonları ve çok dilli sözlükler.

→

Integrations

Kurum Servisi'ne kimlik aktarımı ve oturum izleme, operatör bildirim profilleri, denetim loglarının iletimi.

→

Profillerin vService'e Bağlanması

Profil	vService'te bağlandığı yer
Login Forms, Authentication Providers, MFA	Flowchart (düzenleme modu; form, Authentication Provider ve MFA adımları)
Session Protection Policies	AGS ayarları Session Protection Policy
Account Lockout Policies	AGS ayarları Default Lockout Policies; sağlayıcı profillerinde Lockout Behavior
Bot Protection Policies	AGS ayarları Bot Protection Policies
CAPTCHA Providers	Kilitleme politikası Captcha Provider; bot politikası Captcha aksiyonu
Page Templates, Dictionaries	AGS ayarları Page Template ve Dictionary
Backend SSO Configurations	AGS ayarları Backend SSO Config
Notification Profiles	AGS ayarları Notification Profile
Log Forwarding	AGS ayarları Audit Log Forwarders

Tipik Devreye Alma Akışı

1

Adım 1 AGS'yi etkinleştir

HTTP tipindeki vService'te AGS açılır. Varsayılan akış hazır Basic Login formuyla başlar ve Deny ile biter; bu aşamada kullanıcılar Kurum Servisi'ne ulaşmaz (bkz. How to Enable AGS?).

2

Adım 2 Kimlik kaynağını tanımla

Kurumsal dizin ya da RADIUS kullanılacaksa önce Authentication Servers kaydı, yerel hesaplar kullanılacaksa Local Databases tanımlanır. Ardından Authentication Providers ekranında türüne uygun sağlayıcı profili oluşturulur.

3

Adım 3 Akışı kur ve Allow adımına bağla

Flowchart tuvalinde forma bir Authentication provider adımı eklenir ve adımın success çıkışı Allow adımına bağlanır. Gerekiyorsa fail çıkışı ikinci bir sağlayıcıya yönlendirilir.

4

Adım 4 Kimliği Kurum Servisi'ne aktar

Backend SSO Configurations profili oluşturulup vService'e bağlanır; kullanıcı adı, e-posta ya da grup bilgisi uygulamanın beklediği biçimde (başlık, Basic Auth, Bearer token ya da çerez) eklenir.

5

Adım 5 Görünümü ve dili kurumsallaştır

Page Templates ile logo, renk ve arka plan; Dictionaries ile desteklenen diller ve metinler tanımlanır. Giriş formunun alanları gerekiyorsa Login Forms ekranında düzenlenir.

6

Adım 6 Koruma politikalarını gözden geçir

Hazır politikalar yerine kuruma uygun değerler gerekiyorsa oturum koruma, kilitleme ve bot koruma profilleri oluşturulup vService'e bağlanır. CAPTCHA basamağı için harici bir servis kullanılacaksa CAPTCHA Providers profili tanımlanır.

7

Adım 7 Kritik uygulamalarda ikinci faktörü ekle

MFA profili oluşturulup akışa MFA adımı olarak eklenir. TOTP kullanılacaksa kullanıcı kayıtları TOTP sekmesinden izlenir.

8

Adım 8 Haber almayı ve denetimi kur

Notification Profiles ile alarm üretilecek durumlar, Log Forwarding ile denetim loglarının iletileceği SIEM ya da syslog hedefleri tanımlanır. İlk günlerde Audit Logs ve Lockout ekranları izlenir.