Nachdem ich in meinem letzten Beitrag erkannt hatte, dass ich unbedingt Kommentare aktivieren sollte, machte ich mich daran, dies auf eine Weise umzusetzen, die meinen persönlichen Anforderungen entspricht. Die naheliegendste Lösung war dabei von Anfang an, Entra External ID für Authentifizierung und Benutzerverwaltung hinzuzufügen (wie man es eben so macht 😉).
Entra External ID ist eine Variante von Entra ID (ehemals Azure AD), die für die Verwaltung großer Nutzergruppen gedacht ist, die nicht mit einer Organisation verbunden sind – typischerweise Kunden. Daher der Branchenbegriff "Customer Identity and Access Management" (CIAM).
Nun könnte man denken, dass WordPress, das 40 % des Internets ausmacht, standardmäßig über ein einfaches und robustes Kommentarsystem verfügt. Das trifft auf 99 % der Menschen sicherlich zu. Aber ich bin etwas besonders und habe an mehreren Punkten etwas auszusetzen:
- Anonyme Beiträge sind keine Option, da ich mich mit Spam noch weniger auseinandersetzen möchte, als ich bereit bin, Benutzerinformationen zu speichern. Natürlich könnte man die Benutzerregistrierung nativ aktivieren und erzwingen, aber:
- Ich mag die WordPress-Anmeldeseite nicht. Besonders, da ich ein großer Fan von Multi-Faktor-Authentifizierung bin und die kostenlosen Optionen oft nicht ideal sind. Ich würde hier viel lieber einen etablierten Identitätsanbieter nutzen.
- Die Registrierung erfordert standardmäßig immer eine E-Mail-Adresse. Da ich plane, diesen Blog langfristig zu betreiben, würde ich mit der Zeit eine Menge Nutzerinformationen auf meiner Plattform ansammeln. Besonders bei E-Mail-Adressen fühle ich mich unwohl und würde lieber eine freie Wahl von Benutzernamen ermöglichen.
Abgesehen von den rein praktischen Punkten suchte ich als Entra ID Admin auch nach einer (semi-)realistischen Gelegenheit, Erfahrungen mit Entra External ID zu sammeln. Ich habe immer festgestellt, dass Learning by Doing die effektivste Methode ist.
Voraussetzungen
Ich bin kein Freund davon, in der Produktion zu testen – auch nicht bei persönlichen Projekten. Daher war der erste Schritt, eine temporäre WordPress-Instanz bereitzustellen.
Als Ausgangspunkt habe ich eine WordPress-Seite auf Azure App Service eingerichtet. Für meine Zwecke reichte der kostenlose Hosting-Plan vollkommen aus, und die Bereitstellung auf Azure ist schnell und unkompliziert.
Nachdem die Instanz lief, habe ich mein Theme und eine Testseite installiert, um sicherzustellen, dass alles wie auf meiner Produktionsseite funktioniert. Anschließend habe ich die Konfiguration angepasst:
Erster Schritt: WordPress-Kommentare aktivieren und Login-Anforderung einstellen:
So sieht der Kommentarbereich jetzt aus:
Mit der vorbereiteten WordPress-Seite war es nun an der Zeit, den Identity Provider (IdP) zu erstellen. Dafür habe ich den Tenant Setup Quickstart von Microsoft befolgt.
Erinnerung: Dies ist ein neuer, separater Tenant. Erster Schritt: Ein Breakglass-Konto erstellen, falls der Zugriff verloren geht.
Jetzt, da beide Teile – der Service Provider und der Identity Provider – bereit sind, war es Zeit, die Verbindung herzustellen!
Auswahl eines SSO-Plugins
WordPress unterstützt weder SAML noch OIDC von Haus aus. Das ist verständlich – der durchschnittliche Blogger oder Betreiber einer einfachen Webseite hat wohl kaum Bedarf an einer Integration mit Identitätsanbietern.
Zum Glück bietet WordPress ein großes Ökosystem von Add-ons und Plugins, die diese Lücke schließen können.
Meine Kriterien waren recht einfach:
- IdP-Agnostisch: Das Plugin sollte mit jedem Identitätsanbieter funktionieren. Tools wie das Auth0 Connector Plugin schieden daher aus.
- Open Source: Ich lege großen Wert darauf, wann immer möglich Open-Source-Software zu verwenden.
- OIDC-Protokoll: Ich bevorzuge die Nutzung neuerer Standards, wann immer es möglich ist.
Das Plugin, das alle drei Kriterien erfüllte, war Daggerhart OpenID Connect Generic.
Nach der Installation dieses Plugins wurde meine WordPress-Testinstanz OIDC-fähig. Ab diesem Punkt ging es nur noch um die übliche Entra-SSO-Integration.
Konfiguration von SSO in Entra (External) ID
Zuerst benötigen wir die Redirect-URI unseres Plugins, um die Konfiguration der Entra Enterprise-App abzuschließen. (In meinem Fall zu finden unter Settings > OpenID Connect Client).
Anschließend führen wir die erforderlichen Basiseinstellungen auf der Entra-ID-Seite durch.
Das ist meiner Meinung nach der größte Vorteil bei der Verwendung von Entra External ID: Wenn man Entra-ID-Admin ist, hat man diese Konfigurationen schon unzählige Male gesehen.
Nach der Basiskonfiguration sieht die App-Registration so aus:
Hinzufügen der Standard-OIDC-Berechtigungen
🖹 Kein Admin-Consent erteilen: Wenn Endbenutzer (z. B. Blogleser) und nicht Ihre Mitarbeiter eingebunden werden, ist es sehr hilfreich, eine explizite Zustimmung zu verlangen. Dies gewährleistet Transparenz und macht die Datenerhebung explizit, was besonders wichtig für die Einhaltung der DSGVO in Europa ist.
Konfiguration des OIDC-Plugins
Wichtig! In dem von mir verwendeten Plugin sind die folgenden Felder verpflichtend. Andernfalls funktioniert der SSO-Button nicht!
Idealerweise sollten die
userinfo– undend session-URLs dynamisch aus der Konfigurations-URL gelesen werden:
https://[TenantURL].ciamlogin.com/[TENANTID]/v2.0/.well-known/openid-configuration
Doch Entwickler und Standards verstehen sich nicht immer gut.
| Einstellung | Wert |
|---|---|
| Client ID | [Ihre Client-ID] |
| Client Secret Key | [Ihr Client-Secret] |
| OpenID Scope | profile openid offline_access |
| Login Endpoint URL | https://[TENANTNAME].ciamlogin.com/[TENANTID]/oauth2/v2.0/authorize |
| Userinfo Endpoint URL | https://graph.microsoft.com/oidc/userinfo |
| Token Validation Endpoint URL | https://[TENANTNAME].ciamlogin.com/[TENANTID]/oauth2/v2.0/token |
| End Session Endpoint URL | https://[TENANTNAME].ciamlogin.com/[TENANTID]/oauth2/v2.0/logout |
| Identity Key | sub |
| Nickname Key | name |
| Email Formatting | Entfernt, da ich keine E-Mails in meiner Datenbank speichern möchte |
| Display Name Formatting | {name}, oder die Claims, aus denen der Anzeigename generiert werden soll |
| State Time Limit | 360 s (Mit dem Standardwert 180 erhielt ich zu oft "invalid state" 😉) |
| Identity with User Name | Ja |
| Enable Refresh Token | Ja (Dafür dient der Scope offline_access) |
| Create user if does not exist | Ja |
| Redirect Back to Origin Page | Ja |
Ich bevorzuge es immer, userprincipalname oder preferred_username als Identifikator zu verwenden. Leider nutzt das von mir verwendete Plugin weiterhin den userinfo-Endpoint. Das ist ein schlechtes Zeichen für die Integration mit Entra ID, da wir die Informationen vom userinfo-Endpoint nicht anpassen können.
Falls Ihre Lösung das Arbeiten mit ID-Tokens ermöglicht: Ich empfehle diesen Artikel/Tool zum Testen von Claims von Martin Rublik. Auch wenn ich befürchtete, dass mein Plugin den
userinfo-Endpoint von Anfang an verwendet, habe ich das Tool genutzt, um sicherzustellen, dass das ID-Token korrekt ist, wenn das SSO nicht funktionierte.
Mit dieser Konfiguration können Nutzer ihre E-Mail angeben, müssen es aber nicht – und wir haben erfolgreich SSO eingerichtet. Schauen wir uns das Ergebnis im Detail an.
Benutzererfahrung
Wenn wir den Login-Button klicken, der normalerweise zur Standard-WordPress-Anmeldeseite weiterleitet, werden wir jetzt direkt zur Entra External ID-Anmeldeseite weitergeleitet.
Nach der Anmeldung mit einem zuvor eingeladenen Benutzer können wir uns mit Authenticator MFA anmelden, nachdem wir der Freigabe unserer Informationen zugestimmt haben.
| 1: MFA-Eingabeaufforderung | 2: Einverständniserklärung |
|---|---|
 |
 |
Der Benutzer wird erfolgreich angemeldet und könnte eine E-Mail-Adresse angeben, die jedoch standardmäßig leer bleibt.
Beim Abmelden wird der Microsoft-Kontowähler verwendet.
War es den Aufwand wert?
Wenn Sie jetzt versuchen, auf meinem Blog zu kommentieren, werden Sie eine ganz andere Erfahrung haben. Nach einigen Tests entschied ich mich, ein Plugin zu verwenden, das sich auf Social Logins spezialisiert. Diese Lösung bietet eine größere Auswahl an Social-Login-Anbietern (inklusive dedizierter Login-Buttons) und ermöglicht es den Nutzern, selbst zu entscheiden, welche Informationen sie teilen.
Ich bin in diesem Blog nicht detailliert auf die Integration mit anderen Identitätsanbietern eingegangen, da die Konfiguration und Benutzererfahrung nicht meinen Vorstellungen entsprach. Aber das ist in Ordnung, da Entra External ID für meinen Anwendungsfall nicht vorgesehen ist.
Für meinen kleinen Blog wäre es übertrieben, Anmeldeabläufe, Benutzerverwaltungsprozesse oder benutzerdefinierte Seiten zu verwalten. Für Entwickler oder Organisationen, die eine robuste Identitätsinfrastruktur benötigen, bietet Entra External ID jedoch erhebliche Vorteile, indem es viele Aufgaben abnimmt.
Das gesagt, hinkt Entra External ID seinem Vorgänger Entra B2C in einigen Bereichen – insbesondere bei der Benutzerbereitstellung – hinterher. Ich kenne aktuelle CIAM-Projekte, bei denen Teams sich nach detailliertem Vergleich aufgrund dieser Einschränkungen für B2C entschieden und auf zukünftige Migrationspfade zu External ID hoffen.
Für mich persönlich war das Hauptziel, Erfahrung mit Entra External ID zu sammeln, ein voller Erfolg. Ich habe viel gelernt und wertvolle Praxiserfahrung gesammelt.
Ich bin gespannt, wo sich Entra External ID in den nächsten Jahren hinentwickeln wird – vielleicht werden die Lücken geschlossen, und es wird für eine breitere Palette von Anwendungsfällen noch attraktiver. 😊
Kommentare