Architektúra · Alkalmazásidentitás
Cognito-identitásarchitektúra a WordPress napi üzemeltetéséhez
A Cognitót ne egyszerű bejelentkezési képernyőként, hanem identitási alrendszerként kezelje: a böngészős hitelesítés, a föderáció, a csoportok, a tokenkontextus és az opcionális AWS-hitelesítő adatok maradjanak elkülönítve a WordPress-tartalomtól és -munkamenetektől.
WordPress-oldal → Gatey felület
↓ böngésző
Amazon Cognito User Pool
├→ közösségi / SAML / OIDC szolgáltatók
├→ MFA + profilfolyamatok
├→ csoportok / tokenkontextus
└→ opcionális Identity Pool
↓
védett API-k / statikus hozzáférés
Identitási határ
A WordPress jeleníti meg az élményt; az alkalmazásidentitás a Cognitóé
A Gatey biztosítja a frontendélményt, a Cognito pedig hitelesíti a felhasználókat, és más szolgáltatások által ellenőrizhető identitási elemeket ad ki. Így a bejelentkezés dinamikus vagy statikus WordPressen is működik anélkül, hogy a WordPress felhasználói táblája lenne az alkalmazásidentitás forrása.
Látogató böngészője
→ Gatey hitelesítő
→ Cognito User Pool
├→ bejelentkezés / regisztráció / MFA / profil
├→ SAML / OIDC / közösségi föderáció
└→ csoport- és tokenkontextus
├→ JWT-vel engedélyezett API-k
├→ opcionális IAM-hitelesítő adatok
└→ aláírói döntés a védett statikus hozzáféréshez
Jogosultsági határ A sikeres hitelesítés nem ad általános alkalmazás-hozzáférést. A védett API-knak és statikus erőforrásoknak saját scope-, IAM- vagy aláírt hozzáférési szabályaikat kell érvényesíteniük a Cognito identitáskontextusával.
Mit hoz létre a sablon
Az identitásstack több egy User Poolnál. Ez a leltár bemutatja a böngészőklienst, a föderációs és domainbeállításokat, az életciklus-triggereket, az opcionális AWS-hitelesítő adatokat és az alkalmazásidentitási határt alkotó outputokat.
| Építőelem | Miért szükséges | Fő tervezési döntés | Üzemeltetési megjegyzés |
|---|---|---|---|
| User Pool + App Client | Elsődleges felhasználói címtár és OAuth-kliens a böngészőalapú WordPress-belépéshez | Nincs client secret; kód- vagy SRP-kompatibilis nyilvános kliens | A stack létrehozhatja, vagy a sablonmódtól függően meglévő poolhoz kapcsolódhat. |
| Opcionális egyedi domain | Márkázott bejelentkezés és OAuth-visszahívások | ACM-tanúsítvány és opcionális Route53-alias, ha elérhető a hosted zone | A DNS és a tanúsítvány tulajdonlását az éles indulás előtt egyértelműsíteni kell. |
| Identity Pool | A hitelesített Cognito-felhasználókat AWS-hitelesítő adatokra váltja IAM-aláírt API-khoz | Az AuthenticatedRole és RegisteredRole elkülönítése | Statikus frontendről indított, IAM-védett API Gateway-hívásokhoz hasznos. |
| Custom Email Sender | HTML-sablonokra és márkázott folyamatokra cseréli az egyszerű Cognito-e-maileket | A sablonok S3-ban vannak; konfigurálva SES küld, különben maradhat Cognito-fallback | A sablonokat verziózott termékeszközként, ne konzolba írt szövegként kezelje. |
| Pre Sign-Up trigger | Ellenőrzi a regisztráció minőségét, mielőtt a felhasználó bekerül a poolba | Opcionális reCAPTCHA, megbízható domainek és külső IdP-k e-mailes összekapcsolása | A hibák legyenek érthetők a frontendnek és kellően naplózottak a hibakereséshez. |
| Pre Token Generation trigger | A csoporttagságot access-token-scope-okba vetíti | Például sc.group.registered vagy sc.group.admin scope-ok hozzáadása | Deklaratívabbá teszi az API Gateway scope-ellenőrzését. |
| Post Confirmation trigger | A megerősített felhasználót a Registered csoportba helyezi | Csak valódi regisztráció-megerősítéseket kezeljen | Elválasztja a „hitelesített” és „API-hívásra eléggé regisztrált” állapotot. |
| Outputok | Lehetővé teszik, hogy más stackek és bővítmények felhasználják az identitási elemeket | Pool- és kliensazonosítók, domain, szerepkörök, csoportok és Lambda ARN-ek kiadása | Az outputok jelentik a szerződést e stack és a platform többi része között. |
Token- és jogosultsági modell
A Cognito többféle identitási elemet biztosít, de mindegyiknek más a szerepe. A táblázat különválasztja a böngészős hitelesítést, csoportokat, scope-okat, ideiglenes AWS-hitelesítő adatokat és szolgáltatásoldali jogosultságkezelést.
| Réteg | Elem | Mit bizonyít | Mire nem használható |
|---|---|---|---|
| Gatey / böngésző | Cognito-tokenek és helyi hitelesítési állapot | A felhasználó végrehajtotta a konfigurált Cognito-folyamatot | Titkok tárolása a WordPress-szerveren vagy jelszavak továbbítása PHP-n keresztül. |
| User Pool-csoportok | registered, admin vagy projektspecifikus csoportok | A felhasználó egy üzleti szerepkörhöz tartozik | Az egyetlen futásidejű szabályérvényesítési pontként működni. |
| Access-token-scope-ok | sc.group.<group> | A token API által olvasható szerepkör-kontextust hordoz | Helyettesíteni a backend jogosultságkezelését, amikor az erőforrás tulajdonlása számít. |
| Identity Pool-szerepkör | AuthenticatedRole vagy RegisteredRole | A böngésző ideiglenes AWS-hitelesítő adatokat kaphat engedélyezett műveletekhez | Széles körű fiókszintű jogosultságokat adni. |
| API Gateway-metódus | Cognito-scope vagy IAM-jogosultság | Az útvonal a szolgáltatáshatáron érvényesíti az identitást | Rejtett gombokra vagy kizárólag CSS-alapú korlátozásokra támaszkodni. |
Üzemeltetési hibamódok
Az identitási hibák gyakran általános bejelentkezési problémának látszanak, miközben az ok e-mail-kézbesítés, föderáció, token-scope vagy DNS. A táblázat a látható tünetet a vizsgálandó üzemeltetési határhoz rendeli.
| Hibamód | Felhasználó által látható tünet | Valószínű ok | Runbook iránya |
|---|---|---|---|
| A reCAPTCHA elutasítja a regisztrációt | A felhasználó nem tud fiókot létrehozni | Hibás site key vagy secret, elavult token, alacsony pontszám vagy eltérő action | Ellenőrizze a clientMetadata tokenútját, az SSM-secretet, a küszöböt és a Lambda-logokat. |
| Az egyedi e-mail nem érkezik meg | Nem érkezik megerősítő vagy jelszó-e-mail | Nem ellenőrzött SES-identitás, sandbox-korlát, sablonolvasási hiba vagy FROM-eltérés | Ellenőrizze az SES-identitást, CloudWatch-logokat, S3-sablonkulcsot és fallbacket. |
| A közösségi belépés duplikált felhasználót hoz létre | Ugyanaz az e-mail külön szolgáltatói identitások alatt jelenik meg | A külső IdP-összekapcsolás ki van kapcsolva vagy hibás | Vizsgálja meg a Pre Sign-Up logokat és az AdminLinkProviderForUser jogosultságait. |
| Az API-hívás belépés után elutasítva | A frontend hitelesít, de az API 401/403 választ ad | A felhasználó nincs a Registered csoportban, hiányzik a scope, nincs szerepkörleképezés vagy hibás az authorizer | Ellenőrizze a token-scope-okat, csoporttagságot, Post Confirmation logokat és az API Gateway authorizert. |
| Az egyedi domain hibás | A Hosted UI vagy callback domain nem oldható fel | Tanúsítványrégió vagy -ellenőrzés, Route53-zónaeltérés vagy aliascél | Ellenőrizze az ACM-tanúsítványt, a DNS-zóna tulajdonlását és a Cognito-domain állapotát. |
Megvalósítási út
Az identitást az alkalmazáshatár, ne egy WordPress-munkamenet köré építse
Az érdemi napi üzemeltetési munka a User Pool létrejötte után kezdődik: föderáció, életciklus, jogosultságkezelés és ismételhető konfiguráció.
- Határozza meg, ki birtokolja az identitást — A WordPress a tartalomra és megjelenítésre összpontosítson. Akkor használjon Cognitót, ha ugyanannak a látogatói identitásnak statikus oldalakra, API-kra vagy más alkalmazásfelületekre is ki kell terjednie.
- Konfigurálja a szükséges bejelentkezési és föderációs utakat — A Cognito és a Gatey segítségével csak a projekt által valóban igényelt bejelentkezési, regisztrációs, MFA-, profil-, közösségi, SAML- vagy OIDC-folyamatokat engedélyezze.
- Rendelje az identitást futásidejű jogosultságokhoz — Token-claim-ekkel, scope-okkal, csoportokkal vagy opcionális IAM-hitelesítő adatokkal tegye lehetővé, hogy a háttérszolgáltatások a frontend láthatóságától függetlenül engedélyezzék a műveleteket.
- Tesztelje az életciklust és a hibákat — A megerősítést, jelszó-visszaállítást, MFA-t, szolgáltatói belépést, csoporttagság-változást, tokenlejáratot és API-elutasítást az oldalrendereléstől elkülönítve ellenőrizze.
Mikor legyen a Cognito az alkalmazásidentitási réteg tulajdonosa
Jó választás
Az identitásnak túl kell terjednie a WordPressen
- Ugyanazoknak a felhasználóknak statikus frontenden vagy olyan oldalakon is be kell jelentkezniük, ahol nem WordPress PHP szolgálja ki a kérést.
- A frontendidentitásnak API-kat, védett erőforrásokat vagy más alkalmazásfelületeket kell engedélyeznie.
- A szervezetnek már van vagy várható közösségi, SAML- vagy OIDC-föderációs igénye.
Maradjon a WordPress-natív hitelesítés
A WordPress-munkamenetek egyszerűbbek lehetnek, ha
- csak a wp-adminhoz vagy szokásos dinamikus WordPress-oldalakhoz kellenek hitelesített felhasználók.
- nincs külső alkalmazás, védett API vagy statikus frontend, amelynek ugyanarra az identitásra lenne szüksége.
- a meglévő bővítmények közvetlenül a WordPress felhasználói és munkamenet-viselkedésétől függenek, és nincs üzleti ok külön identitási alrendszerre.
Problémamegoldó útmutatók
Az architektúra által támogatott identitási döntések
Mikor váltsa fel az Amazon Cognito a WordPresst alkalmazásidentitási rétegként?
Lásd Az Amazon Cognito használata WordPress helyett alkalmazásidentitási rétegként. A WordPress marad a CMS, a szélesebb alkalmazás látogatói identitását pedig a Cognito kezeli.
Hogyan csatlakoztathatók meglévő SAML- vagy OIDC-identitásszolgáltatók?
Lásd WordPress csatlakoztatása meglévő SAML- és OIDC-szolgáltatókhoz. A Cognito a föderációs központ, a Gatey pedig egységes frontend-bejelentkezést biztosít.
Hogyan működik ez statikus WordPressen?
Lásd Bejelentkezés hozzáadása statikus WordPresshez PHP-munkamenetek nélkül. A böngészőoldali Cognito-belépés túléli a statikus közzétételt, mert nem függ WordPress PHP-munkamenettől.
Miben különböznek a védett statikus fájlok a védett API-któl?
A statikus kiszolgáláshoz lásd Statikus WordPress védelme CloudFront Signed Cookies segítségével. Az API-knak külön kell ellenőrizniük a JWT-, IAM- vagy más támogatott jogosultságot.
Az identitási döntéssel kezdjen
Akkor használjon Cognitót, ha a látogatói identitásnak túl kell élnie a WordPress-kérést
Az alapdöntéshez válassza az alkalmazásidentitási útmutatót, vagy az SSO-útmutatót, ha a meglévő identitásszolgáltatókkal való föderáció az elsődleges igény.