Die Identitätsarchitektur moderner Unternehmen ist nicht homogen. Während ein Team ein zentrales Verzeichnis nutzt, kann eine andere Geschäftseinheit ein altes RADIUS-basiertes Authentifizierungssystem benötigen, eine externe Benutzergruppe eine Social-Identität und eine behördliche Anwendung eine nationale eID. In Fintech-, Gesundheits- und Behördenprojekten sind auch benutzerdefinierte REST-Identitätsdienste häufig.
Herkömmliche Zugriffsplattformen behandeln diese Vielfalt meist einzeln. Für jeden Provider entstehen eine andere Integration, ein anderer Audit-Trail, ein anderes Fehlerverhalten und ein anderer MFA-Ablauf. Im Ergebnis fragmentiert die Sicherheitsrichtlinie; der Operator muss denselben Benutzer in verschiedenen Systemen unterschiedlich verwalten.
Legacy-Systeme sind ein eigenes Problem. Eine seit Jahren laufende RADIUS- oder Web-Form-basierte Authentifizierungsinfrastruktur zu ersetzen, ist sowohl teuer als auch riskant. Doch ohne eine vorgeschaltete Ebene aus MFA, Conditional Access, Lockout, IP-Kontrolle und Audit ist es nicht möglich, diese Systeme auf modernes Zero-Trust-Niveau zu heben.
Benutzerdefinierte Identitäts-APIs zeigen dieselbe Lücke. Wenn das eigene Kundenauthentifizierungs-, OTP- oder mobile Identitätssystem eines Unternehmens einen HTTP-Endpunkt bereitstellt, sollte die Zugriffsplattform diesen als Identitätsanbieter nutzen können. Andernfalls muss jede Anwendung ihre eigene Integration schreiben.
TR7 AAM vereint verschiedene Identitätsanbietermodelle in einer einzigen Authentication-Provider-Ebene; es bindet RADIUS-, OAuth2-, HTTP-API-, Web-Form-, LocalDB- und Portal-Provider an dieselbe Zugriffs-, MFA- und Audit-Engine.
TR7 AAM betreibt verschiedene Identitätsquellen unter einem einzigen Provider-Modell und überführt jedes Authentifizierungsergebnis in dieselbe Zugriffsentscheidungskette.
RADIUS-, OAuth2-, HTTP-API-, Web-Form-, LocalDB- und Portal-Provider werden als dasselbe Provider-Objekt definiert. Die Ablauf-Engine verarbeitet jeden Provider mit Erfolgs-, Fehler-, Lockout- und MFA-Übergängen auf dieselbe Weise.
Mit PAP- und CHAP-Unterstützung können bestehende RADIUS-Backend-Dienste hinter AAM gestellt werden. Das vorhandene Authentifizierungssystem bleibt erhalten; darüber werden MFA, Conditional Access, Lockout und Audit hinzugefügt.
Integrierte OAuth2-Provider und benutzerdefinierte OAuth2-Konfigurationen können an AAM angebunden werden. Szenarien wie die Google-Workspace-Domaineinschränkung und das Feld-Mapping einer nationalen eID werden in eine einzige Zugriffs-Engine einbezogen.
Der eigene REST-Identitätsdienst, das OTP-System oder der Kundenauthentifizierungs-Endpunkt eines Unternehmens kann als AAM-Provider genutzt werden. Durch Konfiguration von Methode, Header, Body und Erfolgsbedingungen wird der Bedarf an zusätzlicher Entwicklung reduziert.
Die zusätzlichen Identitätsanbieter-Integrationen überführen verschiedene Identitätsquellen — von Legacy-Authentifizierungssystemen bis zu benutzerdefinierten REST-APIs — in das gemeinsame Sicherheitsmodell von AAM.
TR7 AAM unterstützt auf der RADIUS-Seite die Authentifizierungstypen PAP und CHAP. PAP bietet einfachere Legacy-Kompatibilität; CHAP bietet ein challenge-basiertes Authentifizierungsverhalten. Die bestehende RADIUS-Infrastruktur kann AAM vorgeschaltet werden, ohne sie zu ersetzen. Dies ist ein praktischer Modernisierungsweg für Telco-, NAC-, alte VPN- und Unternehmens-Zugriffssysteme.
Für jeden RADIUS-Backend-Dienst kann ein eigener Shared-Secret-Schlüssel definiert werden. So wird die Authentifizierungsbeziehung zwischen AAM und dem RADIUS-Server pro Provider getrennt. In Umgebungen mit mehreren RADIUS-Servern erhält jede Integration ihre eigene Sicherheitsgrenze. Operative Änderungen werden über eine einzige zentrale Konfiguration verwaltet.
Unter einem Provider können mehrere RADIUS-Server definiert werden. Antwortet der primäre Server nicht, kann der sekundäre Server einspringen. Diese Struktur arbeitet mit kurzem Timeout und schnellem Übergangsverhalten, passend zur UDP-basierten Natur von RADIUS. Das Legacy-Identitätssystem rückt näher an ein Hochverfügbarkeitsmodell.
Der Google-OAuth2-Provider kann auf eine bestimmte Workspace-Domain beschränkt werden. So wird sichergestellt, dass sich nur Benutzer der unternehmenseigenen Domain anmelden. Access-Type- und Prompt-Verhalten können entsprechend dem OAuth2-Ablauf konfiguriert werden. Eine externe Social-Identität wird durch die Unternehmens-Zugriffsrichtlinie kontrolliert.
Der nationale eID-OAuth2-Provider arbeitet mit integrierten Feld-Mappings für Szenarien mit staatlicher Bürgeridentität. Felder wie Personenkennnummer, Vorname, Nachname, E-Mail, Telefon und Geburtsdatum können in das AAM-Benutzerobjekt überführt werden. Der PKCE-gestützte Ablauf erhöht die Authentifizierungssicherheit. In Anwendungen mit öffentlichem Bürgerservice wird die Bürgeridentität an die AAM-Zugriffskette gebunden.
Im Custom-OAuth2-Modus können Authorization-URL, Token-URL, Userinfo-URL, Logout-URL und Revocation-URL einzeln definiert werden. Client-ID, Secret, Scope, Response-Type, Grant-Type und PKCE-Verhalten sind konfigurierbar. So werden benutzerdefinierte Unternehmens-Identitätssysteme, die standardisiertes OAuth2 sprechen, in AAM einbezogen. Die Integration wird innerhalb des einheitlichen Provider-Modells verwaltet.
Einige alte Anwendungen bieten kein Standardprotokoll; sie haben nur ein Web-Login-Formular. TR7 AAM kann mit dem Web-Form-Provider Login-URL, Formularfelder und Erfolgsbedingungen definieren. Der Erfolg kann anhand von Redirect-, Cookie- oder Statuscode-Verhalten erkannt werden. So kann der Login-Bildschirm einer alten Anwendung in die AAM-Kontrollkette einbezogen werden.
Der HTTP-API-Provider verwandelt jeden beliebigen REST-Endpunkt in eine Authentifizierungsquelle. GET-, POST- oder PUT-Methoden; JSON-, Multipart-, URL-encoded- oder Raw-Body-Typen können verwendet werden. Die Erfolgsbedingung kann anhand von Statuscode, Vorhandensein eines Cookies oder Redirect-URL bewertet werden. Banking-OTP-, Kundenauthentifizierungs- oder benutzerdefinierte mobile Authentifizierungssysteme können mit diesem Modell angebunden werden.
Der LocalDB-Provider nutzt einen innerhalb von AAM verwalteten lokalen Benutzerspeicher. Er eignet sich für Umgebungen ohne Internetverbindung, Testsysteme, externe Partnerkonten oder Zugriffe unabhängig vom zentralen Identitätsspeicher. Grundlegende Sicherheitskontrollen wie Passwortverlauf können angewendet werden. Dies erleichtert eigenständige und self-hosted Nutzungsszenarien.
Der Portal-Provider kann ein anderes AAM-Portal-Gateway als Authentifizierungsquelle nutzen. Diese Struktur unterstützt SSO-ähnliche Übergangsszenarien zwischen mehreren Portalen oder verschiedenen Zugriffstoren. Der Benutzer wird in einer einzigen AAM-Kette authentifiziert und kann zu anderen Zugriffspunkten überführt werden. In großen Unternehmens-Deployments vereinfacht dies die Portal-Architektur.
Jeder Provider kann unterschiedliche Feldnamen zurückgeben. TR7 bildet mit userMapping Source-Attribute-Werte auf die AAM-Standardfelder ab. So werden beispielsweise Personenkennnummer, E-Mail, Gruppe, Telefon oder Display-Name in ein gemeinsames Benutzerobjekt überführt. MFA, Conditional Access und Backend-SSO-Injection arbeiten über dieses standardisierte Objekt.
Jeder Authentication-Provider kann sein eigenes Lockout-Verhalten erben, erweitern oder überschreiben. So können Provider wie RADIUS, HTTP-API oder LocalDB unterschiedliche Schwellen für fehlgeschlagene Logins haben. Der Brute-Force-Schutz ist nicht in eine einzige globale Einstellung gepresst. Die Richtlinie wird nach dem Risikoprofil des Identitätsanbieters bestimmt.
Zusätzliche Identitätsanbieter müssen gemeinsam mit Protokollverhalten, Netzwerkzugriff, Benutzer-Mapping, Verwaltung fehlgeschlagener Logins und Audit-Trails entworfen werden.
RADIUS arbeitet UDP-basiert; es verfügt nicht über die klassische TCP-Verbindungspool-Logik. Die Timeout-Werte sollten kurz und das Failover-Verhalten schnell geplant werden. Werden mehrere RADIUS-Server definiert, müssen Antwortzeit und Reihenfolge sorgfältig gewählt werden.
In OAuth2-Abläufen verringern State und PKCE die Risiken von CSRF und Replay. In behörden- oder mobil-orientierten Szenarien ist das PKCE-Verhalten besonders wichtig. Bei der Provider-Konfiguration sollten sichere Voreinstellungen gewahrt bleiben.
Der HTTP-API-Provider muss nicht nur auf den Statuscode schauen. Zusätzliche Erfolgsbedingungen wie das Vorhandensein eines Cookies oder eine Redirect-URL können verwendet werden. Dies passt sich an die unterschiedlichen Erfolgsverhalten benutzerdefinierter Identitätsdienste an.
In HTTP-Path, -Body, -Header und Web-Form-Feldern können Benutzereingaben oder AAM-Variablen verwendet werden. Benutzername, OTP oder andere Eingabefelder können dynamisch in die Identitätsanfrage eingefügt werden. Dieses Verhalten sollte mit sorgfältiger Validierung genutzt werden.
Einige Provider-Typen müssen aus dem richtigen Netzwerkbereich ausgehen, um den externen Identitätsanbieter zu erreichen. OAuth2-, OIDC- oder Web-Form-Provider können unterschiedliche Route-Tables benötigen. Die providerbasierte Netzwerkauswahl ist für den Integrationserfolg kritisch.
Jeder Provider-Versuch sollte mit erfolgreichem, fehlgeschlagenem oder gesperrtem Ergebnis ins Audit-Log geschrieben werden. Provider-Typ, Benutzer, Quell-IP und Ergebnisinformation können an das SIEM übertragen werden. Dies bietet ein einheitliches Audit in einer fragmentierten Identitätsinfrastruktur.
Das in einer Telco- oder ISP-Umgebung laufende alte RADIUS-Authentifizierungssystem bleibt erhalten. Indem TR7 AAM vorgeschaltet wird, werden MFA, Conditional Access und zentrales Audit hinzugefügt.
Ein Kommunal- oder Behördenportal kann das Bürger-Login mit der nationalen eID-OAuth2 durchführen. Die Identitätsfelder werden in die AAM-Sitzung überführt, und der Dienstzugriff wird mit Conditional-Access-Regeln verwaltet.
Verschiedene Regionen oder Teams können unterschiedliche Identitätssysteme nutzen. TR7 AAM vereint diese Provider unter einem einzigen Gateway und einem einzigen Audit-Modell.
Bietet der Kundenauthentifizierungs- oder OTP-Dienst einer Bank eine REST-API, kann AAM diese als HTTP-Provider aufrufen. Der Erfolg wird über Statuscode-, Cookie- oder Redirect-Bedingung verifiziert.
Partnerkonten, die nicht in das zentrale Unternehmensverzeichnis aufgenommen werden, können in der AAM-LocalDB verwaltet werden. Auf diese Konten werden separate MFA-, Lockout- und Zugriffsrichtlinien angewendet.
Betreiben Sie RADIUS, OAuth2, HTTP-API und die lokale Benutzerdatenbank im selben Ablauf aus Conditional Access, MFA und Audit. Wir betrachten dies gemeinsam in einer Live-Installation in Ihrer eigenen Umgebung.