Gatey + federación empresarial
Conecte WordPress con proveedores SAML y OIDC existentes sin crear flujos de acceso independientes
Si su organización ya utiliza un proveedor de identidad, no debería crear un flujo de acceso específico en WordPress para cada proveedor. Use Amazon Cognito como centro de federación y Gatey como capa de frontend para experiencias WordPress dinámicas o estáticas.
Respuesta breve Configure el proveedor SAML u OIDC existente en un Amazon Cognito User Pool y ofrézcalo mediante Gatey. Cognito gestiona la federación, el flujo de cuenta y los tokens; Gatey presenta el acceso y el estado autenticado en el frontend. Cada backend protegido sigue siendo responsable de autorizar las solicitudes.
Por qué los flujos SSO separados se encarecen
La federación resuelve el acceso, pero no sustituye la autorización integral
El reto no consiste solo en mostrar un botón SAML u OIDC. El ciclo de identidad, las URL de retorno, el cierre de sesión, los frontends estáticos y las API protegidas deben respetar la misma frontera de confianza.
Flujos duplicados
Un acceso distinto por proveedor multiplica la lógica de identidad
Las integraciones separadas repiten redirecciones, retornos, gestión de errores, correspondencia de cuentas y cierre de sesión. Cada cambio del proveedor debe reproducirse después en varios flujos de WordPress o frontend.
Entrega estática
Las sesiones tradicionales de WordPress no encajan en páginas exportadas estáticamente
Un frontend estático no ejecuta retornos PHP de WordPress ni puede depender de sesiones de servidor. El acceso debe funcionar en el navegador y comunicarse con una capa de identidad externa.
Autorización
Un SSO correcto no protege automáticamente una API
El estado autenticado visible solo indica que el frontend dispone de un contexto de identidad. Cada API debe validar el token, su emisor, audiencia y claims, y aplicar las reglas de acceso.
Regla de seguridad Centralice la federación en Cognito, pero mantenga la decisión de autorización en cada backend protegido.
Ruta de identidad
Cognito intermedia la federación; Gatey la lleva al frontend de WordPress
El proveedor existente sigue siendo la fuente de identidad empresarial. Cognito intermedia SAML u OIDC, gestiona el flujo del User Pool y emite tokens. Gatey usa ese flujo en el navegador, mientras WordPress y las API conservan responsabilidades separadas.
Proveedor de identidad existente
| SAML u OIDC
v
Amazon Cognito User Pool
| federación / flujo de cuenta / tokens
v
Gatey en el navegador
|
+--> WordPress dinámico
|
+--> WordPress estático
|
+--> API protegidas
Límite de autorización Cognito centraliza la federación y el contexto de identidad. Sin embargo, un botón de acceso o un estado autenticado en la interfaz no controla el acceso. Las API deben validar los tokens de Cognito o la autorización IAM prevista.
Implementación
Configure primero el contrato de federación y después la experiencia del frontend
Trate dominios, claims, URL de retorno, cierre de sesión y validación del backend como un único flujo. Pruébelo en cada entorno real de entrega.
- Conecte el proveedor de identidad con Cognito — Configure los metadatos SAML o endpoints OIDC, los datos del cliente, la asignación de atributos y los scopes necesarios en el Cognito User Pool. Documente qué claims se consideran estables.
- Configure dominios y URL de retorno y cierre de sesión — Registre con exactitud los dominios de producción, staging y, cuando corresponda, estáticos. Limite las redirecciones a destinos autorizados y confirme que el cierre termina los estados local y federado previstos.
- Exponga los proveedores mediante Gatey — Configure los botones adecuados y el estado autenticado del frontend. Mantenga la experiencia clara sin volver a implementar dentro de WordPress la lógica de federación que pertenece a Cognito.
- Proteja y pruebe cada frontera del backend — Valide los JWT de Cognito o la autorización IAM en cada API. Asocie grupos o claims con roles solo donde sea necesario y pruebe tokens caducados, incorrectos o con privilegios insuficientes.
Cuándo encaja este patrón
Buena opción
Use la federación de Cognito cuando la identidad deba extenderse más allá de WordPress
- Su organización ya utiliza uno o varios proveedores de identidad SAML u OIDC.
- La misma identidad debe servir en WordPress dinámico o estático y en API protegidas.
- Quiere centralizar la federación y la emisión de tokens sin crear un flujo de frontend para cada proveedor.
Alternativa más sencilla
Un plugin SSO nativo de WordPress puede bastar si la frontera termina realmente en WordPress
- Solo necesita proteger wp-admin o un único sitio WordPress dinámico.
- No hay entrega estática, API independiente ni necesidad de Cognito o identidad compartida entre aplicaciones.
- Su equipo no quiere operar Cognito como intermediario y acepta un acoplamiento mayor con WordPress.
Preguntas frecuentes
Preguntas habituales sobre SSO de WordPress con Cognito
¿Puede Cognito utilizar un proveedor SAML existente?
Sí. Un Cognito User Pool puede federarse con un proveedor SAML configurado. Debe alinear en ambos lados los metadatos, las asignaciones de atributos, los dominios y los destinos de retorno y cierre de sesión.
¿Funciona el mismo enfoque con OIDC?
Sí. Cognito puede conectarse a un proveedor OIDC compatible mediante sus endpoints de autorización, token, información de usuario y claves. Ajuste los scopes y claims al contexto de identidad necesario.
¿Puede Gatey mostrar el acceso en un sitio WordPress estático?
Sí. Gatey puede ofrecer el flujo de navegador basado en Cognito y el estado de frontend en un sitio entregado estáticamente. La página estática no ejecuta por ello una sesión PHP de WordPress.
¿El SSO protege automáticamente nuestras API?
No. El SSO proporciona identidad y tokens. Cada API debe validar el token o la autorización IAM prevista y aplicar sus propias reglas. Un indicador de sesión iniciada en la interfaz no sustituye ese control.
Siguiente paso
Unifique el acceso de WordPress con sus proveedores de identidad existentes
Explore Gatey para el acceso de frontend basado en Cognito y compare este enfoque con los plugins SSO tradicionales de WordPress.