WordPress-hitelesítés
WordPress SSO Amazon Cognitóval és Gatey-jel | Útmutató közösségi és vállalati bejelentkezéshez
Az Amazon Cognito egységes identitásközpontként szolgálhat a közösségi szolgáltatókhoz, valamint a szervezet meglévő SAML- vagy OIDC-szolgáltatójához. A Gatey ezt az identitásréteget konfigurálható bejelentkezési, regisztrációs, MFA- és fiókkezelési folyamatokon keresztül teszi elérhetővé a WordPressben, amelyek statikus exportálás után is működőképesek maradhatnak.
Konfigurálás előtt
Három döntés határozza meg a teljes SSO-architektúrát
Válassza ki az identitásközpontot
A közösségi és vállalati szolgáltatókat egyetlen Cognito User Pool mögött kezelje, hogy az alkalmazások egységes felhasználó-, attribútum-, csoport- és tokenkészlettel dolgozzanak.
Használjon nyilvános alkalmazásklienst
A böngészőalapú WordPress vagy statikus frontend nem tud biztonságosan kliens-titkot tárolni. A Cognito alkalmazásklienst titok nélkül hozza létre.
Határozza meg az engedélyezési határt
A Cognito-bejelentkezés megállhat a böngészőmunkameneteknél és JWT-knél, vagy Identity Pool használatával továbbvihető, ha a frontendnek ideiglenes AWS-hitelesítő adatokra van szüksége.
Architektúra
Miért érdemes a Cognitót identitásközpontként használni?
Egy WordPress-webhelynek szüksége lehet egyszerű közösségi bejelentkezésre az ügyfelek, valamint vállalati SSO-ra a munkatársak, partnerek vagy ügyfelek számára. Ha minden szolgáltatót közvetlenül a WordPressben konfigurál, több külön visszahívási folyamat jön létre, és a későbbi módosítások összehangolása nehezebbé válik.
A Cognito ezeket a szolgáltatókat egyetlen User Pool mögé helyezi. A Gatey jeleníti meg a WordPress felé néző felületet, miközben a hitelesítés, az MFA, a felhasználói attribútumok, a csoportok és a tokenkibocsátás a Cognitóban marad.
- Egyetlen User Pool szolgáljon az alkalmazás identitásjegyzékeként.
- Minden külső szolgáltatót a Cognitóhoz adjon hozzá a WordPress bejelentkezési folyamatának újjáépítése helyett.
- A Gatey jelenítse meg az így létrejövő bejelentkezési lehetőségeket a WordPressben.
Ez a szétválasztás különösen hasznos, ha ugyanannak az identitási útvonalnak dinamikus WordPress-telepítésen és statikusan közzétett frontenden is működnie kell. Az alkalmazásszintű határ kialakításáról itt olvashat: az Amazon Cognito használata alkalmazásszintű identitásrétegként.
Cognito-alapok
Hogyan kell konfigurálni a User Poolt és az App Clientet?
Induljon ki egy Cognito User Poolból és egy böngészőre szánt alkalmazáskliensből. Az alkalmazáskliens ne hozzon létre titkot. Engedélyezze az authorization code grant folyamatot, és pontosan regisztrálja a webhely által használt visszahívási és kijelentkezési URL-eket.
Csak a frontend számára szükséges scope-okat kérje. Gyakori alapbeállítás az openid, az email és a profile. Az aws.cognito.signin.user.admin scope-ot csak akkor adja hozzá, ha a fiókkezelési felületnek az általa lefedett Cognito-felhasználóiprofil-műveletekre van szüksége.
- A visszahívási URL-ek pontosan egyezzenek, beleértve a protokollt, a gazdagépnevet, az elérési utat és a záró perjelet.
- Engedélyezzen minden identitásszolgáltatót, amelyet az alkalmazáskliensnek kínálnia kell.
- Hozzon létre Cognito-domaint a felügyelt engedélyezési végpontokhoz.
A WordPress-felület kialakítása előtt tesztelje a Cognito engedélyezési folyamatát. Az a szolgáltató, amely a Cognitóban hibázik, a Gateyn keresztül indítva is hibázni fog.
Identitásszolgáltatók
Hogyan illeszkednek a rendszerbe a közösségi és vállalati szolgáltatók?
A Cognito képes olyan gyakori közösségi szolgáltatók összevonására, mint a Google, a Facebook, az Apple és az Amazon. A vállalati kapcsolatok jellemzően OIDC-n vagy SAML-en keresztül érkeznek, így a meglévő vállalati identitásszolgáltató maradhat a munkatársi vagy partneridentitások forrása.
Az attribútumok leképezése okozza leggyakrabban a nehezen észrevehető problémákat. Ahol elérhető, képezze le az e-mail-címet, az utónevet, a vezetéknevet és egy stabil szolgáltatói azonosítót. Mielőtt a szolgáltatót éles felhasználók számára engedélyezi, ellenőrizze, mely attribútumokat követeli meg a User Pool.
- Minden szolgáltatót külön teszteljen a Cognito által hosztolt engedélyezési útvonalon.
- Ellenőrizze a visszaadott claim-eket és a leképezett attribútumokat; ne feltételezze, hogy a szolgáltatói alapértékek megfelelnek.
- A kért szolgáltatói scope-okat és Cognito-attribútumokat tartsa az alkalmazás által megengedett minimumon.
A szolgáltatók megjelenített neve a Gatey prezentációs beállítása; a tényleges szolgáltatói azonosítók és a bizalmi konfiguráció továbbra is a Cognitóhoz tartoznak. A föderációs útvonalról itt olvashat: a WordPress összekapcsolása meglévő SAML- és OIDC-identitásszolgáltatókkal.
Közösségi identitásszolgáltatók beállításai
| Szolgáltató | Hitelesítő adatok | Scope-ok | Jellemző leképezés |
|---|---|---|---|
| OAuth Client ID + titok | openid email profile |
email → email, family_name → family_name, given_name → given_name, sub → username |
|
| App ID + titok | email public_profile |
email → email, last_name → family_name, first_name → given_name, id → username |
|
| Apple | Services ID, kulcs, Team ID | openid email name |
Képezze le: email; a felhasználói élmény tervezésekor vegye figyelembe az Apple privát továbbítási e-mail-címeit. |
| Amazon | Login with Amazon Security Profile | profile (+ email igény szerint) |
email → email, name → given/family ahol elérhető |
WordPress-konfiguráció
Hogyan kapcsolható össze a Cognito a Gatey-jel?
A WordPress adminisztrációs felületén nyissa meg a SmartCloud beállításait, majd konfigurálja a Gateyt a webhely által használt AWS-régióval, User Pool ID-val, App Client ID-val, Cognito-domainnel, OAuth scope-okkal, bejelentkezési mechanizmusokkal és regisztrációs attribútumokkal.
Ezután adja hozzá a Gatey Authenticator blokkot a bejelentkezési vagy fiókoldalhoz. A beépített közösségi szolgáltatók a blokk beállításaiban engedélyezhetők, az egyéni SAML- és OIDC-szolgáltatók pedig a projekthez szükséges címkékkel jeleníthetők meg.
- Először hozzon létre és teszteljen egy külön bejelentkezési vagy fiókoldalt.
- Külön ellenőrizze a regisztrációs, megerősítési, jelszó-helyreállítási, MFA- és profilfolyamatokat.
- Egyéni szolgáltatói gombokat csak a Cognito-azonosítók ellenőrzése után adjon hozzá.
A Gatey a WordPress megjelenítési rétegét vezérli, de a szolgáltatói titkokat, jelszavakat és a Cognito felhasználói címtárát nem helyezi át a WordPressbe.
Adminisztrátori hozzáférés
Az wp-login.php lecserélése előtt képezzen le egy adminisztrátori csoportot
Ne irányítsa át és ne cserélje le a WordPress natív bejelentkezését addig, amíg legalább egy tesztelt Cognito-identitás nincs hozzárendelve a szükséges WordPress-adminisztrátori szerepkörhöz. Ellenőrizze a teljes folyamatot külön böngészőmunkamenetben, és tartson fenn helyreállítási útvonalat, hogy egy szolgáltatói vagy leképezési hiba ne zárhassa ki az összes adminisztrátort.
AWS API-hozzáférés
Mikor van szükség Identity Poolra és IAM-szerepkörre?
A User Pool elegendő, ha a webhelynek csak bejelentkezésre, fiókkezelő képernyőkre és JWT-vel engedélyezett API-kra van szüksége. Az Identity Pool akkor válik fontossá, ha a hitelesített böngészőfelhasználóknak ideiglenes AWS-hitelesítő adatokat kell kapniuk, és AWS IAM használatával kell aláírniuk a kéréseket.
A kapcsolódó IAM-szerepkörök csak a frontend számára szükséges műveleteket és erőforrásokat engedélyezzék. A csoport- vagy claim-alapú engedélyezés tovább szűkítheti az alkalmazás viselkedését, de nem ellensúlyozhat túl tág IAM-házirendet.
- Használjon JWT-alapú engedélyezést, ha az API közvetlenül képes ellenőrizni a Cognito-tokeneket.
- Csak AWS-hitelesítő adatokat és IAM-aláírást igénylő esetekhez adjon hozzá Identity Poolt.
- Az execute-api és más jogosultságokat korlátozza a kijelölt API-kra és műveletekre.
Az identitáshitelesítést és az erőforrás-engedélyezést külön tervezési döntésként kezelje. A sikeres bejelentkezés nem jelenthet automatikusan széles körű hozzáférést az AWS-szolgáltatásokhoz.
Indítás előtti ellenőrzés
Mit kell tesztelni az SSO-folyamat közzététele előtt?
Minden szolgáltatót futtasson végig ugyanazon a folyamaton, amelyet egy valódi felhasználó követ: induljon a WordPressből, hitelesítsen a szolgáltatónál, térjen vissza a regisztrált visszahívási címre, ellenőrizze a létrejött fiókadatokat, jelentkezzen ki, majd ismételje meg egy meglévő fiókkal.
A hibafolyamatokat is tesztelje. Az eltérő átirányítási címek, a hiányzó openid scope, a hiányos e-mail-leképezés, az alkalmazáskliens titka és az wp-login idő előtti lecserélése gyakori oka az egyébként nehezen értelmezhető SSO-hibáknak.
- Ellenőrizze a pontos visszahívási és kijelentkezési URL-eket a Cognitóban és a WordPressben.
- Ellenőrizze a szükséges claim-eket, leképezett attribútumokat, csoportokat és WordPress-szerepköröket.
- Az alapértelmezett bejelentkezés módosítása előtt teszteljen adminisztrátori helyreállítási útvonalat.
Ha az identitási útvonal már megbízható, a stílus és a szolgáltatói címkék az alapul szolgáló bizalmi kapcsolatok módosítása nélkül finomíthatók. Statikus kézbesítés esetén tekintse át, hogyan tartható működésben a bejelentkezés a PHP-munkamenetek visszaállítása nélkül.
Először az identitási útvonalat konfigurálja
A WordPress-bejelentkezés formázása előtt tesztelje a Cognitót
Először építse fel és ellenőrizze a User Poolt, a nyilvános alkalmazásklienst, a szolgáltatói leképezéseket, a visszahívásokat és a szerepkörhatárokat. Ezután a Gatey segítségével helyezze el a létrejövő bejelentkezési és fiókkezelési folyamatot ott, ahol a WordPress-felhasználók számítanak rá.