Összehasonlítás: Gatey és a népszerű WordPress SSO-bővítmények és IdP-k

Az összehasonlítás szempontjai

Három kérdéssel elkerülhető a legtöbb kategóriatévesztés

Termékkategóriák

Milyen termékeket hasonlítunk valójában össze?

A Gatey és az Amazon Cognito egyetlen architektúra két részét alkotja. A Gatey biztosítja a WordPress-blokkokat, a fiókképernyőket, a lokalizációt és a frontend-integrációt. A Cognito biztosítja a felhasználói címtárat, a föderációt, az MFA-t, a csoportokat és a tokeneket.

Egy közösségi bejelentkezést kínáló bővítmény szűkebb problémát old meg. Egy vállalati SSO-bővítmény gyakran meglévő SAML- vagy OIDC-szolgáltatóhoz kapcsolja a WordPresst. Az Auth0-hoz vagy Oktához hasonló hosztolt platformok működtetik az identitásszolgáltatást. A Keycloak saját üzemeltetésű identitásszolgáltató. Egy WordPress OAuth-szerver megfordítja az irányt, és a WordPresst teszi más alkalmazások identitásforrásává.

• Kliensréteg: megjeleníti a bejelentkezést és felhasználja a tokeneket.
• Föderációs híd: külső szolgáltatóhoz kapcsolja a WordPresst.
• Identitásszolgáltató: kezeli a felhasználókat, szabályzatokat, munkameneteket és a tokenkibocsátást.

Ezek a kategóriák átfedhetik egymást, de azonos termékként való kezelésük félrevezető összehasonlításokhoz és rossz megvalósítási döntésekhez vezet.

Futtatási modell

Hol fut a hitelesítés?

A Gatey használatakor a böngésző közvetlenül kommunikál a beállított Cognito User Poollal. A WordPress biztosítja a felületet és a nem érzékeny konfigurációt, de nem kell jelszavakat továbbítania vagy Cognito alkalmazáskliens-titkot tárolnia.

Számos natív WordPress OAuth- vagy SAML-integráció a visszahívások, a munkamenet-létrehozás, a szerepkör-hozzárendelés vagy a konfiguráció tárolása során a WordPress futtatási környezetére támaszkodik. Ez teljesen megfelelő lehet egy dinamikus WordPress-webhelynél, de tervezési korláttá válik, ha a nyilvános frontendnek a statikus közzététel után is működnie kell.

• Ellenőrizze, hová irányítja vissza a szolgáltató a böngészőt a hitelesítés után.
• Ellenőrizze, kell-e kliens titkot vagy aláíró tanúsítványt tárolni a WordPressben.
• Ellenőrizze, hogy a bejelentkezési folyamat minden munkamenetnél vagy visszahívásnál függ-e a PHP-től.

Ne feltételezze, hogy minden alternatíva ugyanazt a modellt követi. Tekintse át az értékelt bővítmény, szolgáltató és kiadás aktuális dokumentációját.

Föderációs igények

Közösségi bejelentkezésre, vállalati SSO-ra vagy mindkettőre van szükség?

Egy célzott közösségi bejelentkezési bővítmény gyakran a legegyszerűbb választás, ha az igény fogyasztói szolgáltatókra korlátozódik, és a webhely hagyományos WordPress-alkalmazás marad. Így nem kell olyan identitásplatformot bevezetni, amelyre a projektnek egyébként nincs szüksége.

A vállalati projektek számára általában fontosabb a SAML- vagy OIDC-föderáció, az attribútumok és csoportok megfeleltetése, az adminisztrátori helyreállítás és az életciklus tulajdonlása. A Cognito egyetlen User Pool mögé helyezheti a közösségi és vállalati szolgáltatókat, a Gatey pedig megjeleníti ezeket a lehetőségeket a WordPress-felületen.

• Szűk, fogyasztói bejelentkezési igényhez válasszon kizárólag közösségi szolgáltatókat kezelő eszközt.
• Vállalati SSO-hidat válasszon, ha a WordPressnek egy meglévő vállalati identitáskörnyezethez kell csatlakoznia.
• Föderációs identitásközpontot válasszon, ha több alkalmazásnak vagy szolgáltatótípusnak közös token- és felhasználói modellt kell használnia.

A megfelelő választás kevésbé függ a szolgáltatói emblémák számától, mint attól, ki működteti az identitáscímtárat, és hogyan mozognak a felhasználók az alkalmazások között. A vállalati föderációs útvonalhoz tekintse át, hogyan kapcsolható a WordPress meglévő SAML- és OIDC-identitásszolgáltatókhoz.

API-engedélyezés

A hitelesített felhasználók védett API-kat is hívnak?

A Gatey Cognito ID- vagy hozzáférési tokeneket használhat JWT-vel engedélyezett végpontokhoz. Ha a böngészőnek AWS-kéréseket kell aláírnia, egy Cognito Identity Pool ideiglenes, IAM-szerepkörhöz társított hitelesítő adatokra cserélheti a hitelesített munkamenetet.

Más hosztolt és saját üzemeltetésű identitásszolgáltatók is kibocsáthatnak szabványos tokeneket, de előfordulhat, hogy a WordPress-bővítmény csak egy WordPress-munkamenetet hoz létre. Ellenőrizze, hogy a kiválasztott kombináció elérhetővé tesz-e használható tokeneket a frontend számára, és hogyan ellenőrzik azokat a további API-k.

• Csak WordPress-munkamenet: elegendő a védett, dinamikus WordPress-tartalomhoz.
• JWT-hozzáférés: olyan API-khoz hasznos, amelyek ellenőrzik a kibocsátót, a célközönséget, a hatóköröket és az állításokat.
• Ideiglenes AWS-hitelesítő adatok: szűken korlátozott, IAM-mel aláírt böngészőkérésekhez hasznosak.

A WordPress OAuth-szerver más használati esetre való: akkor értékes, ha a WordPressnek tokeneket kell kibocsátania más alkalmazások számára, nem pedig külső szolgáltatótól kell identitást fogadnia.

Tulajdonlás és üzemeltetés

Ki felel a felhasználókért, szabályzatokért, rendelkezésre állásért és karbantartásért?

A Gatey és a Cognito használatakor az identitáserőforrások és a használati díjak az ügyfél AWS-fiókjában vannak. Egy hosztolt identitásplatform több üzemeltetési feladatot ad át a szolgáltatónak. A Keycloakhoz hasonló saját üzemeltetésű platform irányítást biztosít, de felelősséget teremt az infrastruktúráért, frissítésekért, biztonsági mentésekért és rendelkezésre állásért is.

Egy natív WordPress-bővítmény a tartalomkezelő rendszer közelében tartja az adminisztrációt, de a nyilvános hitelesítési útvonal örökölheti a WordPress-környezet rendelkezésre állási és biztonsági jellemzőit. Egyik modell sem automatikusan jobb; eltérően osztják el a felelősséget.

• Ügyfél felhője: közvetlen tulajdonlás felhőszolgáltatási konfigurációval és számlázással.
• Hosztolt IdP: kevesebb infrastrukturális munka, de függés a szolgáltató platformjától.
• Saját üzemeltetésű IdP: maximális üzemeltetési irányítás a legnagyobb karbantartási felülettel.

Az összehasonlításba ne csak a telepítési időt, hanem az incidens utáni helyreállítást, az adminisztrátori hozzáférést, a monitorozást, a szolgáltatói tanúsítványok cseréjét, a felhasználói életciklust és a támogatási felelősséget is vegye bele. Az alapvető tulajdonlási döntéshez hasonlítsa össze az Amazon Cognitót a natív WordPress-hitelesítéssel.

Gyakorlati választási útmutató

Melyik irány milyen WordPress-projekthez illik?

A Gatey és a Cognito mellett döntsön, ha a webhely már használ AWS-t, statikus frontendet kell támogatnia, egyetlen User Pool mögött közösségi és vállalati szolgáltatókra egyaránt szüksége van, vagy a böngészőből JWT-vel vagy IAM-mel védett API-kat kell hívnia.

Natív WordPress vállalati SSO-bővítményt válasszon, ha a webhely dinamikus marad, a fő cél egy meglévő vállalati identitás WordPress-szerepkörökhöz rendelése, és az adminisztrátorok teljes egészében a tartalomkezelő rendszerben szeretnék kezelni az integrációt.

• Célzott közösségi bejelentkezési bővítményt válasszon néhány fogyasztói szolgáltatóhoz és hagyományos WordPress-futtatási környezethez.
• Hosztolt identitásplatformot válasszon, ha a szolgáltató által kezelt identitásműveletek és a széles körű alkalmazástámogatás fontosabb az ügyfél felhőjében fennálló tulajdonlásnál.
• Saját üzemeltetésű IdP-t válasszon, ha a szervezet vállalja a teljes irányításhoz szükséges üzemeltetési felelősséget.

WordPress OAuth-szervert akkor válasszon, ha a WordPressnek más alkalmazások identitás- vagy tokenforrásává kell válnia. Bármely bővítmény kiválasztása előtt rajzolja fel a teljes identitási útvonalat. Az alkalmazásarchitektúrához tekintse át, hogyan használható az Amazon Cognito alkalmazásszintű identitási rétegként.

Értékelési ellenőrzőlista

Mit kell igazolnia egy megvalósíthatósági próbának?

Telepítse a kiválasztott lehetőségeket nem éles környezetben, és egy funkciómátrixra hagyatkozás helyett tesztelje a teljes böngészőfolyamatot. Vegye bele az új és visszatérő felhasználókat, a kijelentkezést, a jelszó-helyreállítást, az MFA-t, a szolgáltatói hibákat, a fiókok összekapcsolását és az adminisztrátori helyreállítást.

Ezután tesztelje a tervezett telepítési modellt. Egy dinamikus WordPress-webhely, statikus frontend, tagi portál és API-alapú alkalmazás eltérő követelményeket támaszt a visszahívásokkal, munkamenetekkel, tokenekkel és a backend rendelkezésre állásával szemben.

• Ellenőrizze, hol tárolódnak a hitelesítő adatok, titkok, tokenek és felhasználói attribútumok.
• Szükség esetén ellenőrizze a statikus webhely működését és az API-tokenek elérhetőségét.
• Ellenőrizze a szerepkör-hozzárendelést, a helyreállítási hozzáférést, a naplókat és az üzemeltetési felelősséget.

A legjobb SSO-megoldás az, amelynek identitásmodellje illeszkedik az alkalmazáshoz, nem pedig az, amelyik a leghosszabb ellenőrzőlistával rendelkezik.