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őben futó WordPress-felület vagy statikus webhely nem tud biztonságosan titkos kulcsot tárolni. A Cognito alkalmazásklienst titkos kulcs 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 látogatói felületnek 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 egyetlen User Poolhoz kapcsolja ezeket a szolgáltatókat, és kiállítja az alkalmazás által használt tokeneket. A Gatey biztosítja a WordPress-felületet. Külső szolgáltatóval történő bejelentkezéskor a hitelesítést és az előírt többtényezős ellenőrzést a külső szolgáltatónál kell beállítani.
- 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 látogatói felületen 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 állítsa be a User Poolt és az alkalmazásklienst?
Induljon ki egy Cognito User Poolból és egy böngészős használatra létrehozott alkalmazáskliensből. A klienshez ne hozzon létre titkos kulcsot. Engedélyezze az engedélyezési kódon alapuló folyamatot (authorization code grant), és pontosan adja meg a webhely visszatérési és kijelentkezési URL-jeit.
Csak a látogatói felület számára szükséges jogosultsági köröket kérje. Gyakori alapbeállítás az openid, az email és a profile. Az aws.cognito.signin.user.admin kört csak akkor adja hozzá, ha a fiókkezelő felületnek szüksége van az általa engedélyezett Cognito-profilműveletekre.
- 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.
Rendelje hozzá a szolgáltató adatait a User Pool kötelező attribútumaihoz, például az e-mail-címhez és a névhez. A külső szolgáltatóval belépő felhasználó nevét a Cognito maga képezi a szolgáltatói azonosítóból; ezt nem kell külön hozzárendelni. Ellenőrizze a kötelező és írható attribútumokat az AWS attribútum-hozzárendelési dokumentációjában.
- Minden szolgáltatót külön teszteljen a Cognito által hosztolt engedélyezési útvonalon.
- Ellenőrizze a tokenben visszaadott adatokat és a hozzárendelt attribútumokat; ne feltételezze, hogy a szolgáltató alapértékei megfelelnek.
- Csak az alkalmazáshoz szükséges szolgáltatói jogosultsági köröket és Cognito-attribútumokat kérje.
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. Az alábbi táblázat a külső szolgáltató beállításait mutatja; ezek jogosultsági körei eltérnek a Cognito alkalmazáskliense által kért köröktől. A pontos mezőkhöz kövesse az AWS szolgáltatóbeállítási útmutatóját.
Közösségi identitásszolgáltatók beállításai
| Szolgáltató | Hitelesítő adatok | Jogosultsági körök | Jellemző leképezés |
|---|---|---|---|
| OAuth Client ID + titok | openid email profile |
email → email, family_name → family_name, given_name → given_name; a felhasználónevet a Cognito képezi a sub értékéből. |
|
| App ID + titok | public_profile, email |
email → email, last_name → family_name, first_name → given_name; a felhasználónevet a Cognito képezi az id értékéből. |
|
| Apple | Services ID, Team ID, Key ID és privát kulcs | name email |
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 → email, name → name, ha 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. Adja meg a Gatey számára a webhely AWS-régióját, a User Pool és az alkalmazáskliens azonosítóját, a Cognito-domaint, az OAuth-jogosultsági köröket, a bejelentkezési módokat és a regisztrációs adatokat.
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
A wp-login.php lecserélése előtt rendelje hozzá az adminisztrátori csoportot a megfelelő szerepkörhöz
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 látogatói felület számára szükséges műveleteket és erőforrásokat engedélyezzék. A csoportok vagy a token adatai alapján végzett jogosultság-ellenőrzés tovább szűkítheti a hozzáférést, de nem helyettesíti a megfelelően korlátozott IAM-szabályzatot.
- 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 hibás eseteket is tesztelje. Az eltérő átirányítási címek, a hiányzó openid jogosultsági kör, a hiányos e-mail-hozzárendelés, az alkalmazásklienshez létrehozott titkos kulcs és a wp-login idő előtti lecserélése egyaránt okozhat nehezen értelmezhető SSO-hibákat.
- Ellenőrizze a pontos visszahívási és kijelentkezési URL-eket a Cognitóban és a WordPressben.
- Ellenőrizze a token szükséges adatait, a hozzárendelt attribútumokat, a csoportokat és a 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 kiszolgálá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á.