Identity Federation - Organisationsübergreifende Identitätsverwaltung

Identity Federation löst das fundamentale Problem der Identitätsverwaltung in verteilten Systemen: Wie kann ein Benutzer mit seiner bestehenden Unternehmensidentität auf externe Ressourcen zugreifen - ohne separate Passwörter, ohne Provisioning-Aufwand, ohne Datenduplikation?

Federation-Protokolle im Vergleich

SAML 2.0 (Security Assertion Markup Language):

Akteure:
  Identity Provider (IdP): kennt den User (z.B. Microsoft Entra ID)
  Service Provider (SP):   bietet den Dienst an (z.B. Salesforce, SAP)
  Principal:               der User

SAML Flow (SP-initiated, der häufigste Fall):
  1. User → SP: https://app.example.com/dashboard
  2. SP → User (Redirect): SAML AuthnRequest an IdP
  3. User → IdP: wird eingeloggt (SSO-Session vorhanden → direkt)
  4. IdP → User (POST-Binding): SAML Response (signierte XML-Assertion)
  5. User → SP: SAML Response weiterleiten (Browser als Vermittler!)
  6. SP: prüft Signatur, Issuer, NotBefore/NotOnOrAfter, Audience
  7. SP → User: gewährt Zugriff

Was eine SAML Assertion enthält:
  <saml:Assertion>
    <saml:Issuer>https://login.microsoftonline.com/...</saml:Issuer>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        user@firma.de
      </saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="..." NotOnOrAfter="...">
      <saml:AudienceRestriction>
        <saml:Audience>https://saas-app.com/saml</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AttributeStatement>
      <saml:Attribute Name="displayName">
        <saml:AttributeValue>Max Mustermann</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="groups">
        <saml:AttributeValue>IT-Abteilung</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>

---

OpenID Connect (OIDC) / OAuth 2.0 Federation:
  → Modernerer Standard, JSON-basiert (statt XML)
  → ID Token (JWT) statt SAML Assertion
  → Häufig: "Login with Google/GitHub/Microsoft"

B2B OIDC Federation (Cross-Tenant):
  → Firma A hat Entra ID Tenant A
  → Firma B hat Entra ID Tenant B
  → B2B Direct Federation: Tenant A vertraut Tenant B als IdP

---

WS-Federation:
  → Älteres Microsoft-Protokoll (ADFS-Ära)
  → Wird durch SAML/OIDC abgelöst
  → Noch in Legacy-Umgebungen mit ADFS aktiv

Microsoft Entra ID Federation (Praxis)

B2B External Identity (häufigster Enterprise-Use-Case):

Szenario: Lieferant/Partner soll Zugriff auf SharePoint bekommen

Option 1: Entra B2B Collaboration (Guest-Account):
  → Admin einlädt: admin.partner@lieferant.de → wird Guest in Tenant
  → Partner nutzt SEINE eigenen Credentials (Lieferant-Tenant)
  → Entra ID leitet zur Authentifizierung an Lieferant-IdP weiter
  → Kein separates Passwort nötig!
  PowerShell:
  New-AzureADMSInvitation `
    -InvitedUserEmailAddress admin.partner@lieferant.de `
    -SendInvitationMessage $true `
    -InviteRedirectUrl "https://myorg.sharepoint.com"

Option 2: Direct Federation (SAML/OIDC):
  → Lieferant hat eigenen IdP (nicht Entra ID, z.B. Okta, Ping)
  → Direktes Trust-Verhältnis konfigurieren
  → Admin: Entra Extern → Identitätsanbieter → Direkte Verbundkonfiguration
  → Benötigt: SAML-Metadaten-URL oder OIDC well-known-Endpoint des Partners

Conditional Access für externe Identitäten:
  → MFA erzwingen (auch für Partner-Accounts!)
  → Compliant Device-Anforderung (oder nicht, je nach Szenario)
  → Cross-Tenant Access Policy:
    Inbound trust: Partner-MFA als eigene MFA anerkennen?
    Outbound: Was dürfen eigene User beim Partner sehen?

---

Azure AD B2C (Consumer Identity):
  → Business-to-Consumer, nicht B2B
  → Kunden-Login für eigene Apps via Social Login
  → Google, Facebook, GitHub als externe IdPs
  → Custom Policies (Identity Experience Framework) für komplexe Flows

SAML Federation Sicherheitsrisiken

Häufige Fehlkonfigurationen und Angriffe:

1. XML Signature Wrapping (XSW):
   Problem: SP validiert nur TEIL des XML-Dokuments
   Angriff: Angreifer fügt zweite (gefälschte) Assertion ein,
            die nicht signiert ist, aber vom Parser "gelesen" wird

   SAML Response:
   <Response>
     <Assertion ID="good"> <!-- Signiert, valide -->
       <Subject>attacker@evil.com</Subject>
     </Assertion>
     <Assertion ID="evil"> <!-- NICHT signiert! -->
       <Subject>admin@firma.de</Subject>   ← SP liest diese!
     </Assertion>
   </Response>

   Schutz:
   → SAML-Bibliothek auf Sicherheits-Updates halten
   → XML Canonicalization korrekt implementieren
   → Assertion ID immer einzigartig + zufällig

2. SAML Assertion nicht an SP gebunden (Audience validation fehlt):
   Problem: gültige Assertion von SP-A kann bei SP-B verwendet werden!
   Schutz: <Audience>https://NUR-DIESER-SP.com</Audience> IMMER prüfen!

3. NotOnOrAfter zu groß (Replay-Angriff):
   Problem: Assertion 24h gültig → gestohlene Assertion wiederverwendbar
   Schutz: Max. 5 Minuten; SP führt Assertion-ID-Cache gegen Replay

4. IdP-Metadaten-URL manipuliert:
   Problem: Angreifer ändert Metadaten-URL → eigener IdP
   Schutz: Metadaten manuell pinnen; nur HTTPS-Quellen

5. Zu viele Attribute übergeben:
   Problem: IdP sendet interne Rollen/Gruppen an externen SP
   Schutz: Attribute Release Policy - nur benötigte Attribute

---

OIDC/OAuth Federation Angriffe:
  → Sub-Claim Takeover: sub-Claim (User-ID) ist nicht unique bei Provider-Wechsel
  → Issuer Confusion: app akzeptiert Tokens von beliebigen OIDC-Issuers
    Schutz: Issuer-URL fest konfigurieren, nicht aus Token lesen
  → PKCE-Bypass: Autorisierungscode abgefangen
    Schutz: PKCE für alle Public Clients (Pflicht seit OAuth 2.1)

Federation in der Praxis konfigurieren

Okta als IdP für G Suite / Google Workspace:

1. Okta: App "Google Workspace SAML" aus App-Katalog
2. Okta liefert: ACS URL, Entity ID, Signaturzertifikat
3. Google Admin Console: Security → SSO with 3rd party IdP
   Sign-in page URL: https://firma.okta.com/app/google/sso/saml
   Zertifikat: Oktas öffentliches Signaturzertifikat hochladen
4. Test: Admin-Ausnahme konfigurieren (um sich nicht auszusperren!)
5. User: tippen google.com → Redirect zu Okta → zurück mit SAML Assertion

Shibboleth IdP (Open-Source, Hochschulen):
  Konfiguration: /opt/shibboleth-idp/conf/relying-party.xml
  <bean parent="SAML2.SSO" p:signAssertions="true">
    <property name="relyingParties">
      <list>
        <value>https://uni-portal.de/shibboleth</value>
      </list>
    </property>
  </bean>

  Attribute Resolver (welche Attribute an welchen SP?):
  relying-party.xml → AttributeFilterPolicy
  → eduPerson-Attribute freigeben, NIE interne Rollen!

---

Debugging SAML-Probleme:
  Browser-Extension: SAML-tracer (Firefox/Chrome) → SAML-Assertion im Browser sehen
  Wichtige Prüfungen:
  ✓ Assertion gültig (NotBefore/NotOnOrAfter prüfen!)
  ✓ Audience stimmt mit SP Entity ID überein
  ✓ NameID Format stimmt überein
  ✓ Attribute-Namen exakt korrekt (case-sensitive!)
  ✓ Signaturzertifikat nicht abgelaufen
  ✓ Clock Skew < 5 Minuten zwischen IdP und SP