The identity architecture of a modern organization is not homogeneous. One team uses a central directory while another relies on a legacy RADIUS-based VPN authentication system, an external user group depends on social identity, and a public-facing application requires government-issued identity. In fintech, healthcare and public-sector projects, custom REST identity services are also common.
Traditional access platforms typically handle this variety in isolation. Each provider produces a separate integration, a separate audit trail, different error behavior and a different MFA flow. Security policy ends up fragmented, and operators are forced to manage the same user differently across different systems.
Legacy systems are a distinct problem. Replacing years-old RADIUS or web form authentication infrastructure is both expensive and risky. Yet without adding MFA, conditional access, lockout, IP control and an audit layer on top of these systems, reaching modern zero-trust maturity is not possible.
Custom identity APIs surface the same gap. If an organization's own customer authentication system, OTP service or mobile identity backend exposes an HTTP endpoint, the access platform must be able to use it as an identity provider — without requiring custom development for every application.
TR7 AAM unifies different identity provider models in a single authentication provider layer, connecting RADIUS, OAuth2, HTTP API, Web Form, LocalDB and Portal providers to the same access, MFA and audit engine.
TR7 AAM runs different identity sources under a single provider model and carries every authentication result into the same access decision chain.
RADIUS, OAuth2, HTTP API, Web Form, LocalDB and Portal providers are defined as objects in the same provider collection. The flow engine processes every provider with the same success, failure, lockout and MFA transitions.
Existing RADIUS backends can be placed behind AAM using PAP and CHAP support. The existing authentication system is preserved while MFA, conditional access, lockout and audit are layered on top.
Built-in OAuth2 providers and custom OAuth2 configurations can be connected to AAM. Scenarios such as Google Workspace domain restriction and government identity field mapping are brought into the same access engine.
An organization's own REST identity service, OTP system or customer authentication endpoint can be used as an AAM provider. Method, headers, body and success conditions are configured to reduce additional development work.
Additional Identity Provider Integrations bring diverse identity sources — from legacy authentication systems to custom REST APIs — into the common security model of AAM.
TR7 AAM supports both PAP and CHAP authentication types on the RADIUS side. PAP provides simpler legacy compatibility; CHAP offers challenge-based authentication behavior. Existing RADIUS infrastructure can be placed behind AAM without modification. This is a practical modernization path for telco, NAC, legacy VPN and enterprise access systems.
A separate shared secret can be defined for each RADIUS backend. This separates the authentication relationship between AAM and the RADIUS server on a per-provider basis. In multi-RADIUS environments each integration has its own security boundary. Operational changes are managed through a single central configuration.
More than one RADIUS server can be defined under a single provider. If the primary server does not respond, the secondary can take over. This design works with short timeouts and fast switchover behavior consistent with the UDP nature of RADIUS. Legacy identity systems move closer to a high-availability model.
The Google OAuth2 provider can be restricted to a specific Workspace domain, ensuring that only users from the organization's domain can sign in. Access type and prompt behavior are configurable for the OAuth2 flow. External social identity becomes controlled through the corporate access policy.
The e-Devlet OAuth2 provider works with built-in field mappings for Turkish government identity scenarios. Fields such as national ID number, given name, surname, email address, phone number and date of birth can be carried into the AAM user object. The PKCE-enabled flow improves authentication security. In applications serving public-sector users, citizen identity is connected to the AAM access chain.
In custom OAuth2 mode, authorization URL, token URL, userinfo URL, logout URL and revocation URL can each be defined separately. Client ID, secret, scope, response type, grant type and PKCE behavior are all configurable. This allows any standard OAuth2-compliant custom enterprise identity system to be connected to AAM within the same provider model.
Some legacy applications offer no standard protocol — only a web login form. TR7 AAM can define the login URL, form fields and success conditions through the web form provider. Success is determined by redirect, cookie or status code behavior. This brings the legacy application login screen under the AAM control chain.
The HTTP API provider converts any REST endpoint into an authentication source. GET, POST or PUT methods and JSON, multipart, URL-encoded or raw body types can be used. The success condition can be evaluated on status code, cookie presence or redirect URL. Banking OTP services, customer authentication systems and custom mobile verification backends can all be connected through this model.
The LocalDB provider uses a user store managed inside AAM. It is suitable for environments without internet connectivity, test systems, external partner accounts or access that is independent of the central identity directory. Basic security controls such as password history can be applied. This eases self-hosted and standalone deployment scenarios.
The Portal provider can use another AAM portal gateway as the authentication source. This structure supports SSO-like transition scenarios between multiple portals or different access entry points. Users are authenticated within a single AAM chain and can be carried to other access endpoints. This simplifies portal architecture in large enterprise deployments.
Each provider may return different field names. TR7 userMapping translates source attribute values into AAM standard fields. For example, national ID number, email address, group, phone number or display name are all mapped into the common user object. MFA, conditional access and backend SSO injection operate on this standard object regardless of the originating provider.
Each authentication provider can inherit, extend or override its own lockout behavior. This means RADIUS, HTTP API or LocalDB providers can have different failed login thresholds. Brute force protection is not locked to a single global setting. Policy is set according to the risk profile of each identity provider.
Additional identity providers must be designed together with protocol behavior, network access, user mapping, failed login management and audit trails.
RADIUS runs over UDP and does not use classical TCP connection pool semantics. Timeout values should be short and failover behavior planned for speed. When multiple RADIUS servers are defined, response time and ordering must be chosen carefully.
State and PKCE in OAuth2 flows reduce CSRF and replay risks. PKCE behavior is especially important in public-sector or mobile-oriented scenarios. Secure defaults should be preserved when configuring a provider.
The HTTP API provider is not limited to checking the status code. Additional success conditions such as cookie presence or redirect URL can be used. This accommodates the different success behaviors of custom identity services.
User inputs or AAM variables can be used in HTTP path, body, header and Web Form fields. Username, OTP or other input fields can be dynamically injected into the identity request. This behavior should be used with careful validation.
Some provider types must exit through the correct network namespace to reach the external identity source. OAuth2, OIDC or Web Form providers may require different routing tables. Per-provider network selection is critical to integration success.
Every provider attempt — successful, failed or locked — should be written to the audit log with its result. Provider type, user, source IP and outcome can be streamed to SIEM. This provides unified auditing across a fragmented identity infrastructure.
An existing RADIUS authentication system in a telco or ISP environment is preserved. TR7 AAM is placed in front of it, adding MFA, conditional access and centralized audit.
A municipal or government portal enables citizens to log in through e-Devlet OAuth2. Identity fields are carried into the AAM session and service access is governed by conditional access rules.
Different regions or teams may use different identity systems. TR7 AAM brings these providers together under a single gateway and a single audit model.
If a bank's customer authentication or OTP service exposes a REST API, AAM can call it as an HTTP provider. Success is verified through status code, cookie or redirect conditions.
Partner accounts that will not be added to the central enterprise directory can be managed in AAM LocalDB. Separate MFA, lockout and access policy can be applied to these accounts.
Run RADIUS, OAuth2, HTTP API and local user database through the same conditional access, MFA and audit flow. Let us walk through a live setup in your own environment.