Gatey + fédération d’entreprise
Connectez WordPress aux fournisseurs SAML et OIDC existants sans créer de parcours de connexion séparés
Si votre organisation dispose déjà d’un fournisseur d’identité, vous ne devriez pas créer un parcours WordPress spécifique pour chaque fournisseur. Utilisez Amazon Cognito comme centre de fédération et Gatey comme couche frontend pour les expériences WordPress dynamiques ou statiques.
Réponse courte Configurez le fournisseur SAML ou OIDC existant dans un Amazon Cognito User Pool, puis exposez-le avec Gatey. Cognito gère la fédération, le parcours de compte et les jetons ; Gatey présente la connexion et l’état authentifié dans le frontend. Chaque backend protégé conserve la responsabilité d’autoriser les requêtes.
Pourquoi les parcours SSO séparés coûtent cher
La fédération résout la connexion, mais ne remplace pas l’autorisation de bout en bout
Le défi ne consiste pas seulement à afficher un bouton SAML ou OIDC. Cycle d’identité, URL de rappel, déconnexion, frontends statiques et API protégées doivent respecter la même frontière de confiance.
Parcours dupliqués
Une connexion par fournisseur multiplie la logique d’identité
Des intégrations distinctes répètent redirections, rappels, gestion des erreurs, rapprochement des comptes et déconnexion. Chaque modification du fournisseur doit alors être reproduite dans plusieurs parcours WordPress ou frontend.
Diffusion statique
Les sessions WordPress classiques ne conviennent pas aux pages exportées statiquement
Un frontend statique n’exécute pas les rappels PHP de WordPress et ne peut pas dépendre de ses sessions serveur. La connexion doit fonctionner dans le navigateur et communiquer avec une couche d’identité externe.
Autorisation
Une fédération SSO réussie ne protège pas automatiquement une API
L’état connecté visible indique seulement que le frontend détient un contexte d’identité. Chaque API doit valider le jeton, son émetteur, son audience et les claims requis, puis appliquer l’accès.
Règle de sécurité Centralisez la fédération dans Cognito, mais laissez chaque backend protégé prendre sa décision d’autorisation.
Parcours d’identité
Cognito assure la fédération ; Gatey l’intègre au frontend WordPress
Le fournisseur existant reste la source de l’identité d’entreprise. Cognito assure l’intermédiation SAML ou OIDC, gère le parcours User Pool et émet les jetons. Gatey exploite ce parcours dans le navigateur, tandis que WordPress et les API gardent des responsabilités séparées.
Fournisseur d’identité existant
| SAML ou OIDC
v
Amazon Cognito User Pool
| fédération / parcours de compte / jetons
v
Gatey dans le navigateur
|
+--> WordPress dynamique
|
+--> WordPress statique
|
+--> API protégées
Frontière d’autorisation Cognito centralise la fédération et le contexte d’identité. Un bouton de connexion ou un état connecté dans l’interface ne constitue toutefois pas un contrôle d’accès. Les API doivent valider les jetons Cognito ou l’autorisation IAM prévue.
Mise en œuvre
Configurez d’abord le contrat de fédération, puis l’expérience frontend
Traitez les domaines, claims, URL de rappel, déconnexion et contrôles backend comme un seul parcours. Testez-le dans chaque environnement réellement utilisé.
- Reliez le fournisseur d’identité à Cognito — Configurez les métadonnées SAML ou endpoints OIDC, les informations du client, la correspondance des attributs et les scopes nécessaires dans le Cognito User Pool. Documentez les claims considérés comme stables.
- Configurez domaines, URL de rappel et de déconnexion — Enregistrez exactement les domaines de production, de staging et, le cas échéant, statiques. Limitez les redirections aux destinations autorisées et vérifiez que la déconnexion termine les états local et fédéré attendus.
- Exposez les fournisseurs avec Gatey — Configurez les boutons appropriés et l’état connecté dans le frontend. Gardez une expérience claire sans réimplémenter dans WordPress la logique de fédération qui appartient à Cognito.
- Protégez et testez chaque frontière backend — Validez les JWT Cognito ou l’autorisation IAM dans chaque API. N’associez groupes ou claims à des rôles que lorsque c’est nécessaire et testez les jetons expirés, erronés ou insuffisamment autorisés.
Quand ce modèle convient
Bon choix
Utilisez la fédération Cognito lorsque l’identité doit dépasser WordPress
- Votre organisation utilise déjà un ou plusieurs fournisseurs d’identité SAML ou OIDC.
- La même identité doit fonctionner sur WordPress dynamique ou statique et dans des API protégées.
- Vous souhaitez centraliser la fédération et l’émission des jetons sans créer un parcours frontend par fournisseur.
Alternative plus simple
Un plugin SSO WordPress peut suffire si la frontière s’arrête réellement à WordPress
- Vous protégez uniquement wp-admin ou un seul site WordPress dynamique.
- Il n’existe ni diffusion statique, ni API séparée, ni besoin de Cognito ou d’identité inter-applications.
- Votre équipe ne veut pas exploiter Cognito comme intermédiaire et accepte un couplage plus étroit à WordPress.
FAQ
Questions fréquentes sur le SSO WordPress avec Cognito
Cognito peut-il utiliser un fournisseur SAML existant ?
Oui. Un Cognito User Pool peut fédérer un fournisseur SAML configuré. Vous devez aligner les métadonnées, la correspondance des attributs, les domaines ainsi que les destinations de rappel et de déconnexion des deux côtés.
La même approche fonctionne-t-elle avec OIDC ?
Oui. Cognito peut se connecter à un fournisseur OIDC compatible via ses endpoints d’autorisation, de jeton, d’informations utilisateur et de clés. Adaptez scopes et claims au contexte d’identité requis.
Gatey peut-il afficher la connexion sur un site WordPress statique ?
Oui. Gatey peut fournir le parcours navigateur fondé sur Cognito et l’état frontend sur un site diffusé statiquement. La page statique n’exécute pas pour autant de session PHP WordPress.
Le SSO protège-t-il automatiquement nos API ?
Non. Le SSO fournit une identité et des jetons. Chaque API doit valider le jeton ou l’autorisation IAM prévue et appliquer ses propres règles d’accès. Un état « connecté » dans l’interface ne remplace pas ce contrôle.
Étape suivante
Unifiez la connexion WordPress avec vos fournisseurs d’identité existants
Découvrez Gatey pour la connexion frontend via Cognito et comparez cette approche aux plugins SSO WordPress traditionnels.