WordPress-SSO mit Amazon Cognito und Gatey | Leitfaden für Social- und Enterprise-Login

Vor der Konfiguration

Drei Entscheidungen bestimmen das gesamte SSO-Konzept

Architektur

Warum Cognito als Identity Hub verwenden?

Eine WordPress-Website benötigt möglicherweise eine unkomplizierte Social-Anmeldung für Kunden und Enterprise-SSO für Mitarbeiter, Partner oder Auftraggeber. Wird jeder Provider direkt in WordPress konfiguriert, entstehen mehrere getrennte Callback-Abläufe und spätere Änderungen lassen sich schwerer koordinieren.

Cognito bündelt diese Provider hinter einem User Pool. Gatey stellt anschließend die WordPress-seitige Benutzeroberfläche bereit, während Authentifizierung, MFA, Benutzerattribute, Gruppen und Token-Ausgabe in Cognito verbleiben.

• Verwenden Sie einen User Pool als Identitätsverzeichnis der Anwendung.
• Fügen Sie jeden externen Provider zu Cognito hinzu, statt den WordPress-Anmeldeablauf neu aufzubauen.
• Lassen Sie Gatey die daraus entstehenden Anmeldeoptionen in WordPress darstellen.

Diese Trennung ist besonders nützlich, wenn derselbe Identitätspfad sowohl in einer dynamischen WordPress-Installation als auch in einem statisch veröffentlichten Frontend funktionieren muss. Weitere Informationen zur Grenze auf Anwendungsebene finden Sie unter Amazon Cognito als Identitätsschicht der Anwendung verwenden.

Cognito-Grundlage

Wie sollten User Pool und App Client konfiguriert werden?

Beginnen Sie mit einem Cognito User Pool und einem für Browser vorgesehenen App Client. Der App Client darf kein Secret erzeugen. Aktivieren Sie den Authorization Code Grant und registrieren Sie exakt die Callback- und Abmelde-URLs, die von der Website verwendet werden.

Fordern Sie nur die Scopes an, die das Frontend benötigt. Eine übliche Basis bilden openid, email und profile. Fügen Sie aws.cognito.signin.user.admin nur hinzu, wenn die Kontooberfläche Cognito-Benutzerprofiloperationen benötigt, die von diesem Scope abgedeckt werden.

• Die Callback-URLs müssen einschließlich Protokoll, Hostname, Pfad und abschließendem Schrägstrich exakt übereinstimmen.
• Aktivieren Sie jeden Identity Provider, den der App Client anbieten soll.
• Erstellen Sie eine Cognito-Domain für die verwalteten Autorisierungsendpunkte.

Testen Sie den Cognito-Autorisierungsablauf, bevor Sie die WordPress-Oberfläche gestalten. Ein Provider, der in Cognito fehlschlägt, funktioniert auch beim Aufruf über Gatey nicht.

Identity Provider

Wie werden soziale und Enterprise-Provider eingebunden?

Cognito kann verbreitete soziale Provider wie Google, Facebook, Apple und Amazon föderieren. Enterprise-Verbindungen werden üblicherweise über OIDC oder SAML hergestellt, sodass ein vorhandener Unternehmens-Identity-Provider die Quelle für Mitarbeiter- oder Partneridentitäten bleibt.

Das Attribut-Mapping verursacht am ehesten schwer erkennbare Probleme. Ordnen Sie nach Möglichkeit E-Mail-Adresse, Vorname, Nachname und eine stabile Provider-ID zu. Prüfen Sie, welche Attribute der User Pool verlangt, bevor Sie den Provider für Produktivbenutzer aktivieren.

• Testen Sie jeden Provider einzeln über den von Cognito gehosteten Autorisierungspfad.
• Prüfen Sie die zurückgegebenen Claims und zugeordneten Attribute, statt von passenden Provider-Standardwerten auszugehen.
• Beschränken Sie angeforderte Provider-Scopes und Cognito-Attribute auf das von der Anwendung benötigte Minimum.

Die Anzeigenamen der Provider sind Darstellungsoptionen in Gatey; die eigentlichen Provider-Kennungen und die Vertrauenskonfiguration verbleiben in Cognito. Weitere Informationen zum Föderationspfad finden Sie unter WordPress mit bestehenden SAML- und OIDC-Identity-Providern verbinden.

WordPress-Konfiguration

Wie wird Cognito mit Gatey verbunden?

Öffnen Sie in der WordPress-Administration den SmartCloud-Einstellungsbereich und konfigurieren Sie Gatey mit AWS-Region, User Pool ID, App Client ID, Cognito-Domain, OAuth-Scopes, Anmeldemechanismen und Registrierungsattributen der Website.

Fügen Sie anschließend den Gatey-Authenticator-Block zur Anmelde- oder Kontoseite hinzu. Integrierte soziale Provider lassen sich in den Blockeinstellungen aktivieren; benutzerdefinierte SAML- und OIDC-Provider können mit den für das Projekt benötigten Bezeichnungen dargestellt werden.

• Erstellen und testen Sie zunächst eine eigene Anmelde- oder Kontoseite.
• Prüfen Sie Registrierung, Bestätigung, Passwortwiederherstellung, MFA und Profilabläufe getrennt voneinander.
• Fügen Sie Schaltflächen für benutzerdefinierte Provider erst hinzu, nachdem deren Cognito-Kennungen bestätigt wurden.

Gatey steuert die Darstellungsebene in WordPress, verschiebt aber weder Provider-Secrets und Passwörter noch das Cognito-Benutzerverzeichnis nach WordPress.

AWS-API-Zugriff

Wann werden ein Identity Pool und eine IAM-Rolle benötigt?

Ein User Pool genügt, wenn die Website nur Anmeldung, Kontoansichten und JWT-autorisierte APIs benötigt. Ein Identity Pool wird relevant, wenn authentifizierte Browserbenutzer temporäre AWS-Anmeldedaten erhalten und Anfragen mit AWS IAM signieren müssen.

Die zugehörigen IAM-Rollen sollten ausschließlich die vom Frontend benötigten Aktionen und Ressourcen erlauben. Eine gruppen- oder claimbasierte Autorisierung kann das Anwendungsverhalten weiter einschränken, darf eine zu weit gefasste IAM-Richtlinie jedoch nicht kompensieren.

• Verwenden Sie JWT-Autorisierung, wenn die API Cognito-Tokens direkt validieren kann.
• Fügen Sie einen Identity Pool nur für Anwendungsfälle mit AWS-Anmeldedaten und IAM-Signierung hinzu.
• Begrenzen Sie execute-api und weitere Berechtigungen auf die vorgesehenen APIs und Aktionen.

Behandeln Sie Identitätsauthentifizierung und Ressourcenautorisierung als getrennte Architekturentscheidungen. Eine erfolgreiche Anmeldung darf nicht automatisch einen weitreichenden Zugriff auf AWS-Services bedeuten.

Prüfung vor dem Start

Was sollte vor der Veröffentlichung des SSO-Ablaufs getestet werden?

Führen Sie jeden Provider durch dieselbe Abfolge wie ein realer Benutzer: in WordPress starten, beim Provider authentifizieren, zum registrierten Callback zurückkehren, die resultierenden Kontodaten prüfen, abmelden und den Vorgang mit einem bestehenden Konto wiederholen.

Testen Sie auch Fehlerpfade. Abweichende Redirect-URLs, ein fehlender openid-Scope, unvollständiges E-Mail-Mapping, ein App-Client-Secret und ein vorzeitiger Ersatz von wp-login sind häufige Ursachen für schwer verständliche SSO-Fehler.

• Bestätigen Sie die exakten Callback- und Abmelde-URLs in Cognito und WordPress.
• Bestätigen Sie erforderliche Claims, zugeordnete Attribute, Gruppen und WordPress-Rollen.
• Testen Sie einen Wiederherstellungspfad für Administratoren, bevor Sie die Standardanmeldung ändern.

Sobald der Identitätspfad zuverlässig funktioniert, können Gestaltung und Provider-Bezeichnungen angepasst werden, ohne die zugrunde liegenden Vertrauensbeziehungen zu ändern. Weitere Informationen zur statischen Bereitstellung finden Sie unter Anmeldung ohne Wiederherstellung von PHP-Sitzungen funktionsfähig halten.