Gatey + Unternehmensföderation

WordPress mit vorhandenen SAML- und OIDC-Identitätsanbietern verbinden – ohne separate Anmeldeabläufe

Wenn Ihre Organisation bereits einen Identitätsanbieter nutzt, sollten Sie nicht für jeden Anbieter einen eigenen WordPress-Anmeldeablauf bauen. Verwenden Sie Amazon Cognito als Föderationszentrale und Gatey als Frontend-Schicht für dynamische oder statische WordPress-Erlebnisse.

Kurzantwort Konfigurieren Sie den vorhandenen SAML- oder OIDC-Anbieter in einem Amazon Cognito User Pool und stellen Sie ihn über Gatey bereit. Cognito übernimmt Föderation, Kontoablauf und Token; Gatey zeigt im Frontend die Anmeldung und den authentifizierten Zustand. Jeder geschützte Backend-Dienst prüft die Berechtigung weiterhin selbst.

Warum getrennte SSO-Abläufe teuer werden

Föderation löst die Anmeldung, ersetzt aber keine durchgängige Autorisierung

Die Herausforderung besteht nicht nur darin, eine SAML- oder OIDC-Schaltfläche anzuzeigen. Identitätslebenszyklus, Rückruf-URLs, Abmeldung, statische Frontends und geschützte APIs müssen dieselbe Vertrauensgrenze respektieren.

Doppelte Abläufe

Ein eigener Login pro Anbieter vervielfacht die Identitätslogik

Separate Integrationen wiederholen Weiterleitung, Rückruf, Fehlerbehandlung, Kontoabgleich und Abmeldung. Jede Änderung am Identitätsanbieter muss dann in mehreren WordPress- oder Frontend-Abläufen nachvollzogen werden.

Statische Bereitstellung

Klassische WordPress-Sitzungen passen nicht zu statisch exportierten Seiten

Ein statisches Frontend führt keine WordPress-PHP-Rückrufe aus und kann sich nicht auf serverseitige WordPress-Sitzungen verlassen. Die Anmeldung muss im Browser funktionieren und mit einer externen Identitätsschicht kommunizieren.

Autorisierung

Erfolgreiches SSO schützt eine Backend-API nicht automatisch

Ein sichtbarer Anmeldestatus beweist nur, dass das Frontend einen Identitätskontext besitzt. Jede API muss Token, Zielgruppe, Aussteller und erforderliche Claims selbst prüfen und den Zugriff durchsetzen.

Sicherheitsregel Zentralisieren Sie die Föderation in Cognito, aber belassen Sie die Autorisierungsentscheidung bei jedem geschützten Backend.

Identitätspfad

Cognito vermittelt die Föderation; Gatey bringt sie in das WordPress-Frontend

Der bestehende Identitätsanbieter bleibt die Quelle der Unternehmensidentität. Cognito vermittelt SAML oder OIDC, verwaltet den Benutzerpool-Ablauf und stellt Tokens aus. Gatey nutzt diesen Ablauf im Browser, während WordPress und APIs getrennte Verantwortlichkeiten behalten.

Vorhandener Identitätsanbieter
      |  SAML oder OIDC
      v
Amazon Cognito User Pool
      |  Föderation / Kontoablauf / Tokens
      v
Gatey im Browser
      |
      +--> Dynamisches WordPress
      |
      +--> Statisches WordPress
      |
      +--> Geschützte APIs

Autorisierungsgrenze Cognito zentralisiert Föderation und Identitätskontext. Eine Login-Schaltfläche oder ein angemeldeter UI-Zustand ist jedoch keine Zugriffskontrolle. Geschützte APIs müssen Cognito-Tokens oder die vorgesehene IAM-Autorisierung selbst validieren.

Umsetzung

Konfigurieren Sie zuerst den Föderationsvertrag und danach die Frontend-Erfahrung

Behandeln Sie Domains, Claims, Rückruf-URLs, Abmeldung und Backend-Prüfung als einen zusammenhängenden Ablauf. Testen Sie ihn in jeder tatsächlichen Bereitstellungsumgebung.

  1. Binden Sie den Identitätsanbieter an Cognito an — Konfigurieren Sie SAML-Metadaten oder OIDC-Endpunkte, Client-Daten, Attributzuordnungen und die erforderlichen Scopes im Cognito User Pool. Dokumentieren Sie, welche Claims als stabil gelten.
  2. Richten Sie Domains sowie Rückruf- und Abmelde-URLs ein — Registrieren Sie Produktions-, Staging- und gegebenenfalls statische Domains genau. Stellen Sie sicher, dass Weiterleitungen nur auf zugelassene Ziele führen und Abmeldungen den erwarteten lokalen und föderierten Zustand beenden.
  3. Stellen Sie die Anbieter über Gatey dar — Konfigurieren Sie die passenden Provider-Schaltflächen und den angemeldeten Frontend-Zustand. Halten Sie die Oberfläche verständlich, ohne die Cognito-Föderationslogik in WordPress neu zu implementieren.
  4. Schützen und testen Sie jede Backend-Grenze — Validieren Sie Cognito-JWTs oder IAM-Autorisierung in jeder API. Ordnen Sie Gruppen oder Claims nur dort Rollen zu, wo dies erforderlich ist, und testen Sie abgelaufene, falsche und unzureichend berechtigte Tokens.

Wann dieses Muster passt

Gute Wahl

Nutzen Sie Cognito-Föderation, wenn Identität über WordPress hinausreichen muss

  • Ihre Organisation verwendet bereits einen SAML- oder OIDC-Identitätsanbieter.
  • Dieselbe Identität soll auf dynamischen oder statischen WordPress-Seiten und in geschützten APIs gelten.
  • Sie möchten Föderation und Token-Ausstellung zentralisieren, ohne für jeden Anbieter einen eigenen Frontend-Ablauf zu bauen.

Einfachere Alternative

Ein WordPress-eigenes SSO-Plugin kann genügen, wenn die Grenze wirklich bei WordPress endet

  • Sie schützen nur wp-admin oder eine einzelne dynamische WordPress-Site.
  • Es gibt keine statische Bereitstellung, keine getrennte API und keinen Bedarf an Cognito oder anwendungsübergreifender Identität.
  • Ihr Team möchte Cognito nicht als Identitätsbroker betreiben und akzeptiert die engere WordPress-Kopplung.

FAQ

Häufige Fragen zu WordPress-SSO mit Cognito

Kann Cognito einen vorhandenen SAML-Anbieter verwenden?

Ja. Ein Cognito User Pool kann mit einem konfigurierten SAML-Identitätsanbieter föderieren. Sie müssen Metadaten, Attributzuordnungen, Domains sowie Rückruf- und Abmeldeziele auf beiden Seiten konsistent einrichten.

Funktioniert dasselbe Prinzip mit OIDC?

Ja. Cognito kann einen kompatiblen OIDC-Anbieter über dessen Autorisierungs-, Token-, Benutzerinfo- und Schlüsselendpunkte anbinden. Stimmen Sie Scopes und Claim-Zuordnungen auf den benötigten Identitätskontext ab.

Kann Gatey die Anmeldung auf einer statischen WordPress-Website anzeigen?

Ja. Gatey kann den Cognito-basierten Browserablauf und den Frontend-Zustand auf einer statisch ausgelieferten Site bereitstellen. Die statische Seite führt dabei keine WordPress-PHP-Sitzung aus.

Schützt SSO automatisch unsere APIs?

Nein. SSO liefert Identität und Tokens. Jede API muss das Token oder die vorgesehene IAM-Autorisierung validieren und ihre eigenen Zugriffsregeln durchsetzen. Die Anzeige „angemeldet“ ist kein Ersatz dafür.

Nächster Schritt

Vereinheitlichen Sie die WordPress-Anmeldung über Ihre vorhandenen Identitätsanbieter

Entdecken Sie Gatey für die Cognito-basierte Frontend-Anmeldung und vergleichen Sie diesen Ansatz mit klassischen WordPress-SSO-Plugins.