Wie wird die Identitätsföderation mittels OIDC und SAML 2.0 zwischen einem On-Premise Active Directory und mehreren Azure AD Tenants technisch orchestriert?
Die technische Orchestrierung basiert auf einer mehrstufigen Vertrauensstellung, bei der das On-Premise Active Directory (AD) als primäre Identitätsquelle dient und Azure AD (Entra ID) als Identitäts-Hub fungiert.
In diesem Setup setzen wir AD FS (Active Directory Federation Services) als Identity Provider (IdP) ein, der die Kommunikation via SAML 2.0 mit Azure AD übernimmt. Wenn ein Nutzer auf eine Applikation zugreift, leitet Azure AD (als Service Provider) die Authentifizierungsanfrage per SAML-Request an AD FS weiter. Nach erfolgreicher Validierung im lokalen AD sendet AD FS eine SAML-Assertion zurück an Azure AD. Azure AD transformiert diese Assertion in ein JSON Web Token (JWT) basierend auf dem OpenID Connect (OIDC) Standard, welches dann an die Zielapplikation übergeben wird.
Für die Orchestrierung über mehrere Azure AD Tenants nutzen wir entweder B2B-Collaboration (Gastzugriffe) oder Multi-Tenant-App-Registrierungen. Hierbei wird die Identität im Home-Tenant validiert und über Cross-Tenant-Access-Settings in den Ziel-Tenants zugelassen.
| Segment | Protokoll | Funktion |
|---|---|---|
| On-Prem AD $\rightarrow$ AD FS | Kerberos / LDAP | Lokale Authentifizierung |
| AD FS $\rightarrow$ Azure AD | SAML 2.0 | Föderierter Trust & Assertion |
| Azure AD $\rightarrow$ Applikation | OIDC / OAuth 2.0 | Token-basierter Zugriff (JWT) |
| Tenant A $\rightarrow$ Tenant B | SAML / OIDC | Cross-Tenant Trust / B2B |
Die Steuerung erfolgt über präzise Claims-Mapping-Regeln in AD FS, die sicherstellen, dass die User-IDs über alle Tenants hinweg konsistent bleiben. In komplexen Infrastrukturen integrieren wir diese Architektur in eine übergeordnete IT-Consulting & Digitale Strategie, um die Governance und die Token-Lebenszyklen zentral zu steuern.
Die technische Herausforderung liegt in der Konfiguration des Home Realm Discovery (HRD) Prozesses. Azure AD muss anhand der E-Mail-Domain entscheiden, ob der Nutzer lokal via SAML an AD FS oder direkt via Cloud-Authentifizierung validiert wird. Bei Multi-Tenant-Szenarien wird dies durch die common oder organizations Endpunkte in der OIDC-Konfiguration der Applikation gelöst.
Wir empfehlen den Verzicht auf AD FS zugunsten von Azure AD Connect mit Password Hash Synchronization (PHS) oder Pass-Through Authentication (PTA), da die SAML-basierte Föderation die On-Premise-Infrastruktur unnötig komplex macht und eine Single-Point-of-Failure-Quelle darstellt.
Andere Fragen in dieser Kategorie
Wie wird die Datenkonsistenz in einer Event-Driven Architecture mittels Kafka und Schema Registry in einer Multi-Cloud-Umgebung technisch sichergestellt?
Wie wird die Implementierung eines Data Mesh Architekturkonzepts mittels Domain-Driven Design in GCP BigQuery technisch realisiert?
Andere Nutzer suchten auch nach:
Diese Fragen könnten Sie ebenfalls interessieren.
Welche Auswirkungen hat die Aktivierung von TLS 1.3 auf die Latenzzeiten von Cloud-nativen Application Load Balancern im Vergleich zu TLS 1.2?
cloud-digital-workplaceWelche Konfigurationen von Intune App Protection Policies (MAM) gewährleisten die Datentrennung auf unmanaged Devices ohne vollständige MDM-Registrierung?
cloud-digital-workplaceWelche Konfigurationsoptimierungen für die JVM-Garbage-Collection sind für hochperformante Microservices in Kubernetes-Containern unter Berücksichtigung von Cgroup-Limits notwendig?
cloud-digital-workplaceWelche Konfigurationsparameter sind entscheidend für die Optimierung von FSLogix Cloud Cache in Azure Virtual Desktop bei global verteilten User-Profilen?
cloud-digital-workplaceWelche Konfigurationsparameter von Azure App Service Environment (ASE) v3 sind entscheidend für die Isolation von Netzwerkverkehr in hochregulierten Branchen?
