Modern kurumların kimlik mimarisi homojen değildir. Bir ekip merkezi dizin kullanırken, başka bir iş birimi RADIUS tabanlı eski doğrulama sistemine, bir dış kullanıcı grubu sosyal kimliğe, kamu hizmeti veren bir uygulama ise e-Devlet kimliğine ihtiyaç duyabilir. Fintech, sağlık ve kamu projelerinde özel REST kimlik servisleri de sık görülür.
Geleneksel erişim platformları çoğu zaman bu çeşitliliği ayrı ayrı ele alır. Her sağlayıcı için farklı entegrasyon, farklı audit izi, farklı hata davranışı ve farklı MFA akışı oluşur. Sonuçta güvenlik politikası parçalanır; operatör aynı kullanıcıyı farklı sistemlerde farklı biçimde yönetmek zorunda kalır.
Legacy sistemler ayrı bir problemdir. Yıllardır çalışan RADIUS veya web form tabanlı doğrulama altyapısını değiştirmek hem pahalı hem risklidir. Ancak bu sistemlerin önüne MFA, koşullu erişim, lockout, IP kontrolü ve denetim katmanı eklenmeden modern zero-trust seviyesine çıkmak mümkün değildir.
Özel kimlik API'leri de aynı boşluğu gösterir. Kurumun kendi müşteri doğrulama, OTP veya mobil kimlik sistemi bir HTTP endpoint'i sunuyorsa, erişim platformu bunu kimlik sağlayıcı olarak kullanabilmelidir. Aksi halde her uygulama kendi entegrasyonunu yazmak zorunda kalır.
TR7 AAM, farklı kimlik sağlayıcı modellerini tek authentication provider katmanında birleştirir; RADIUS, OAuth2, HTTP API, Web Form, LocalDB ve Portal sağlayıcılarını aynı erişim, MFA ve audit motoruna bağlar.
TR7 AAM, farklı kimlik kaynaklarını tek sağlayıcı modeli altında çalıştırır ve her doğrulama sonucunu aynı erişim karar zincirine taşır.
RADIUS, OAuth2, HTTP API, Web Form, LocalDB ve Portal sağlayıcıları aynı sağlayıcı nesnesi olarak tanımlanır. Akış motoru her sağlayıcıyı başarı, hata, lockout ve MFA geçişleriyle aynı şekilde işler.
PAP ve CHAP desteğiyle mevcut RADIUS kurum servisleri AAM arkasına alınabilir. Var olan doğrulama sistemi korunur; üzerine MFA, koşullu erişim, lockout ve audit eklenir.
Yerleşik OAuth2 sağlayıcıları ve özel OAuth2 konfigürasyonları AAM'e bağlanabilir. Google Workspace domain kısıtı ve e-Devlet kimlik alan eşlemesi gibi senaryolar tek erişim motoruna dahil edilir.
Kurumun kendi REST kimlik servisi, OTP sistemi veya müşteri doğrulama endpoint'i AAM sağlayıcısı olarak kullanılabilir. Method, header, body ve başarı koşulları yapılandırılarak ek geliştirme ihtiyacı azaltılır.
Ek Kimlik Sağlayıcı Entegrasyonları, legacy doğrulama sistemlerinden özel REST API'lere kadar farklı kimlik kaynaklarını AAM'in ortak güvenlik modeline taşır.
TR7 AAM, RADIUS tarafında PAP ve CHAP doğrulama türlerini destekler. PAP daha basit legacy uyumluluk sağlar; CHAP challenge tabanlı doğrulama davranışı sunar. Mevcut RADIUS altyapısı değiştirilmeden AAM'in önüne alınabilir. Bu, telco, NAC, eski VPN ve kurumsal erişim sistemleri için pratik modernizasyon yoludur.
Her RADIUS kurum servisi için ayrı paylaşılan gizli anahtar tanımlanabilir. Böylece AAM ile RADIUS sunucusu arasındaki doğrulama ilişkisi sağlayıcı bazında ayrılır. Çoklu RADIUS ortamlarında her entegrasyon kendi güvenlik sınırına sahip olur. Operasyonel değişiklikler tek merkezi konfigürasyon üzerinden yönetilir.
Bir provider altında birden fazla RADIUS sunucusu tanımlanabilir. Birincil sunucu cevap vermezse ikincil sunucu devreye girebilir. Bu yapı UDP tabanlı RADIUS doğasına uygun kısa timeout ve hızlı geçiş davranışıyla çalışır. Legacy kimlik sistemi yüksek erişilebilirlik modeline daha yakın hale gelir.
Google OAuth2 sağlayıcısı, belirli bir Workspace domain'iyle sınırlandırılabilir. Böylece yalnız kuruma ait domain kullanıcılarının giriş yapması sağlanır. Access type ve prompt davranışları OAuth2 akışına göre yapılandırılabilir. Harici sosyal kimlik, kurumsal erişim politikasıyla kontrollü hale gelir.
e-Devlet OAuth2 sağlayıcısı, Türkiye kamu kimliği senaryoları için yerleşik alan eşlemeleriyle çalışır. Kimlik numarası, ad, soyad, e-posta, telefon ve doğum tarihi gibi alanlar AAM kullanıcı nesnesine taşınabilir. PKCE destekli akış kimlik doğrulama güvenliğini artırır. Kamu hizmeti sunan uygulamalarda vatandaş kimliği AAM erişim zincirine bağlanır.
Custom OAuth2 modunda authorization URL, token URL, userinfo URL, logout URL ve revocation URL ayrı ayrı tanımlanabilir. Client ID, secret, scope, response type, grant type ve PKCE davranışı yapılandırılabilir. Böylece standart OAuth2 konuşan özel kurumsal kimlik sistemleri AAM'e dahil edilir. Entegrasyon tek sağlayıcı modeli içinde yönetilir.
Bazı eski uygulamalar standart protokol sunmaz; yalnız web login formu vardır. TR7 AAM, web form provider ile login URL, form alanları ve başarı koşullarını tanımlayabilir. Başarı, redirect, cookie veya status code davranışıyla anlaşılabilir. Böylece eski uygulama giriş ekranı AAM kontrol zincirine alınabilir.
HTTP API provider, herhangi bir REST endpoint'ini kimlik doğrulama kaynağına dönüştürür. GET, POST veya PUT method'ları; JSON, multipart, URL-encoded veya raw body tipleri kullanılabilir. Başarı koşulu status code, cookie varlığı veya redirect URL üzerinden değerlendirilebilir. Bankacılık OTP, müşteri kimlik doğrulama veya özel mobil doğrulama sistemleri bu modelle bağlanabilir.
LocalDB provider, AAM içinde yönetilen yerel kullanıcı deposunu kullanır. İnternet bağlantısı olmayan ortamlar, test sistemleri, dış partner hesapları veya merkezi kimlik deposundan bağımsız erişimler için uygundur. Parola geçmişi gibi temel güvenlik kontrolleri uygulanabilir. Bu, bağımsız ve self-hosted kullanım senaryolarını kolaylaştırır.
Portal provider, başka bir AAM portal gateway'ini kimlik doğrulama kaynağı olarak kullanabilir. Bu yapı çoklu portal veya farklı erişim kapıları arasında SSO benzeri geçiş senaryolarını destekler. Kullanıcı tek AAM zincirinde doğrulanır ve diğer erişim noktalarına taşınabilir. Büyük kurumsal dağıtımlarda portal mimarisini sadeleştirir.
Her sağlayıcı farklı alan adları döndürebilir. TR7 userMapping ile source attribute değerlerini AAM standart alanlarına eşler. Örneğin kimlik numarası, e-posta, grup, telefon veya display name ortak kullanıcı nesnesine aktarılır. MFA, koşullu erişim ve kurum servisi SSO enjeksiyonu bu standart nesne üzerinden çalışır.
Her authentication provider kendi lockout davranışını devralabilir, genişletebilir veya override edebilir. Böylece RADIUS, HTTP API veya LocalDB gibi sağlayıcılar farklı başarısız giriş eşiğine sahip olabilir. Brute force koruması tek global ayara sıkışmaz. Kimlik sağlayıcısının risk profiline göre politika belirlenir.
Ek kimlik sağlayıcıları; protokol davranışı, ağ erişimi, kullanıcı eşleme, başarısız giriş yönetimi ve audit izleriyle birlikte tasarlanmalıdır.
RADIUS UDP tabanlı çalışır; klasik TCP bağlantı havuzu mantığına sahip değildir. Timeout değerleri kısa ve failover davranışı hızlı planlanmalıdır. Birden fazla RADIUS sunucusu tanımlanıyorsa cevap süresi ve sıralama dikkatle seçilmelidir.
OAuth2 akışlarında state ve PKCE, CSRF ve tekrar oynatma risklerini azaltır. Kamu veya mobil odaklı senaryolarda PKCE davranışı özellikle önemlidir. Provider yapılandırması yapılırken güvenli varsayımlar korunmalıdır.
HTTP API provider yalnız status code'a bakmak zorunda değildir. Cookie varlığı veya redirect URL gibi ek başarı koşulları kullanılabilir. Bu, özel kimlik servislerinin farklı başarı davranışlarına uyum sağlar.
HTTP path, body, header ve Web Form alanlarında kullanıcı girdileri veya AAM değişkenleri kullanılabilir. Kullanıcı adı, OTP veya başka giriş alanları dinamik olarak kimlik isteğine eklenebilir. Bu davranış dikkatli validasyonla kullanılmalıdır.
Bazı provider türleri dış kimlik sağlayıcısına erişmek için doğru ağ alanından çıkmalıdır. OAuth2, OIDC veya Web Form sağlayıcıları farklı route tablolarına ihtiyaç duyabilir. Sağlayıcı bazlı ağ seçimi entegrasyon başarısı için kritiktir.
Her provider denemesi başarılı, başarısız veya kilitlenmiş sonuçlarıyla audit log'a yazılmalıdır. Sağlayıcı tipi, kullanıcı, kaynak IP ve sonuç bilgisi SIEM'e aktarılabilir. Bu, parçalı kimlik altyapısında birleşik denetim sağlar.
Telco veya ISP ortamında çalışan eski RADIUS doğrulama sistemi korunur. TR7 AAM önüne alınarak MFA, koşullu erişim ve merkezi audit eklenir.
Belediye veya kamu portalı vatandaş girişini e-Devlet OAuth2 ile yapabilir. Kimlik alanları AAM oturumuna taşınır ve hizmet erişimi koşullu erişim kurallarıyla yönetilir.
Farklı bölgeler veya ekipler farklı kimlik sistemleri kullanabilir. TR7 AAM, bu sağlayıcıları tek gateway ve tek denetim modeli altında birleştirir.
Bankanın müşteri doğrulama veya OTP servisi REST API sunuyorsa AAM bunu HTTP provider olarak çağırabilir. Başarı status code, cookie veya redirect koşuluyla doğrulanır.
Merkezi kurumsal dizine alınmayacak partner hesapları AAM LocalDB üzerinde yönetilebilir. Bu hesaplara ayrı MFA, lockout ve erişim politikası uygulanır.
RADIUS, OAuth2, HTTP API ve yerel kullanıcı veritabanını aynı koşullu erişim, MFA ve denetim akışında çalıştırın. Kendi ortamınızda canlı bir kurulumla inceleyelim.