Összehasonlítás · WordPress identitásarchitektúra
Gatey kontra WordPress SSO-bővítmények
Gyakorlati összehasonlítás azoknak a csapatoknak, amelyek arról döntenek, hogy a WordPress maradjon-e az identitásrendszer, általános SSO-bővítményt használjon, vagy az Amazon Cognito legyen a WordPress és a statikus frontendek mögötti identitási réteg.
Röviden A hagyományos WordPress SSO-bővítmény jó választás lehet, ha a teljes élmény dinamikus WordPressben marad, és a cél csak a WordPressbe történő bejelentkezés. A Gatey olyan projektekhez készült, ahol az identitásnak a PHP-n kívül is működnie kell: statikus exportban, Cognito-alapú közösségi/SAML/OIDC föderációval, frontend fiókfelületeken, JWT/IAM által védett API-kban és AWS-natív szolgáltatásokban.
Miért számít ez?
Az SSO nem csak a bejelentkezési oldalról szól.
Sok intranetnél, tagsági oldalnál és dinamikus WordPress-portálnál elegendő egy identitásszolgáltató beállítása és az attribútumok WordPress-felhasználókhoz rendelése. A kérdés akkor változik meg, amikor a WordPress már nem az egyetlen futtatási környezet.
01. döntés
Csak WordPressbe kell belépni, vagy közös identitási gerincre van szükség?
Egy tipikus SSO-bővítmény külső identitásszolgáltatóval lépteti be a felhasználót a WordPressbe. A Gatey a Cognito-identitást WordPressben, statikus oldalakon és AWS API-kban is használhatóvá teszi.
02. döntés
Hol éljenek a felhasználók, a föderáció és a tokenek?
A Gatey modelljében a felhasználók, csoportok, MFA, közösségi/SAML/OIDC föderáció és tokenek a Cognitóban élnek. A WordPress beállítást tárol és felhasználói felületet jelenít meg, nem elsődleges identitás-adatbázisként működik.
03. döntés
Az identitásnak túl kell-e élnie a statikus exportot?
A statikus frontend nem támaszkodhat minden látogatói műveletnél a wp-login.php-ra, és egy API Gatewayt hívó böngészős alkalmazásnak sem megfelelő fő jogosultsági modell a PHP-munkamenetsüti. A Cognito tokenjei statikus oldalakon, CloudFront mögött és downstream API-kban is használhatók.
Következmény A döntő kérdés az, hogy csak SSO-belépés kell-e a WordPressbe, vagy olyan identitási gerinc, amelyben a WordPress is részt vesz, de a bejelentkezett állapot statikus frontendeken és AWS-szolgáltatásokban is érvényes.
Döntési táblázat
Három szempont választja el a Gateyt a tipikus WordPress SSO-bővítményektől
A Gatey szélesebb architekturális feladatot old meg; egy általános SSO-bővítmény egyszerűbb lehet, ha csak WordPress-belépésre van szükség.
| Döntési szempont | Gatey | Tipikus WordPress SSO-bővítmény |
|---|---|---|
| Elsődleges cél és futtatás | A böngésző közvetlenül a Cognitóval kommunikál, így az identitás WordPressben, statikus oldalakon és AWS API-kban is használható. | Külső identitásszolgáltatóval lépteti be a felhasználót a WordPressbe, gyakran a WordPress/PHP munkamenet-folyamatára támaszkodva. |
| Föderáció és API-hozzáférés | Az Amazon Cognito kezeli a közösségi, SAML- és OIDC-szolgáltatókat. Ugyanez a réteg JWT-ellenőrzéssel vagy Cognito Identity Pool/IAM mintákkal védheti az API Gateway- és Lambda-végpontokat. | A bővítmény általában az identitásszolgáltatót WordPress-felhasználókhoz rendeli. A különálló AWS API-k jogosultságkezelése többnyire nem a termék fő feladata. |
| Statikus frontend és legjobb illeszkedés | Statikus portálokhoz, AWS-alapú WordPresshez, védett CloudFront-tartalomhoz, ügyfélportálokhoz és közös identitási gerinchez készült. | Hagyományos dinamikus WordPress SSO-hoz illeszkedik, ahol a wp-admin/wp-login integráció a fő követelmény, és a munkamenetnek nem kell külön AWS-futtatási környezeteket jogosítania. |
Mikor melyik megközelítést érdemes választani?
A Gatey az erősebb választás
A Gateyt válassza, ha az identitási állapotnak a WordPressen túl is használhatónak kell lennie.
- A statikus WordPress-frontendnek továbbra is szüksége van bejelentkezésre, regisztrációra, jelszó-visszaállításra, MFA-ra vagy profilkezelésre.
- A frontendkomponensek AWS API-kat hívnak, és JWT- vagy IAM-alapú jogosultságkezelés szükséges; az identitásnak CloudFront, API Gateway, Lambda, AI- vagy munkafolyamat-szolgáltatások felé is működnie kell.
- Az ügyfél azt szeretné, hogy az identitás, a csoportok és a felhasználói életciklus a saját AWS-fiókjában éljen, az ügynökség pedig ugyanazt a mintát több WordPress- és szerver nélküli projektben használhassa.
Az általános SSO-bővítmény az erősebb
Hagyományos SSO-bővítményt akkor válasszon, ha a WordPress marad a teljes alkalmazás.
- Csak wp-admin SSO-ra vagy hagyományos, dinamikus WordPress-tagsági oldalra van szükség.
- A csapat nem kíván AWS-infrastruktúrát birtokolni vagy konfigurálni, és azt szeretné, hogy a bővítmény elrejtse az identitási infrastruktúrát.
- Nincs szükség statikus kompatibilitásra, API-jogosultságkezelésre vagy Cognito-föderációra, illetve az ügyfél már előírt egy kezelt identitási SaaS-t WordPress-összekötővel.
Összehasonlítási GYIK
Gyakori kérdések a Gatey és a WordPress SSO-bővítmények összehasonlításakor
A Gatey csak SSO-bővítmény?
Nem. SSO-felhasználási eseteket is támogat, de a tágabb minta Cognito-alapú identitást ad WordPresshez, statikus frontendekhez és AWS API-khoz.
Lehet egyszerűbb egy hagyományos WordPress SSO-bővítmény?
Igen. Ha az egyetlen cél, hogy a felhasználók beléphessenek egy dinamikus WordPress-oldalra, a hagyományos SSO-bővítmény egyszerűbb lehet.
Tárol a Gatey Cognito kliens titkos kulcsot a WordPressben?
Az ajánlott böngészőalapú Cognito-folyamat nyilvános alkalmazásklienst használ kliens titkos kulcs nélkül. Az érzékeny identitási állapotnak a Cognitóban és a böngésző munkamenetében kell maradnia, nem a WordPress beállításaiban.
Működik statikus export után, és hogyan segíti az API-kat?
Igen. A frontend közvetlenül a Cognitóval kommunikálhat, ha az exportált elemek és visszahívási URL-ek helyesen vannak beállítva. A Cognito által kiadott tokeneket vagy IAM-hitelesítő adatokat az API Gateway és a Lambda a WordPress közvetítése nélkül ellenőrizheti.
Válassza ki a megfelelő identitási réteget a WordPresshez
Hasonlítsa össze a kizárólag WordPressre épülő SSO-t a Cognito-központú modellel.
A döntést az alapján hozza meg, hol kell érvényesnek lennie az identitásnak: csak a dinamikus WordPressben, vagy statikus frontendeken, fiókfelületeken és AWS API-kban is.