SSO empresarial en AAA Sentinel: guía práctica con Auth0 (y qué cambia con Microsoft Entra ID u Okta)

AAA Sentinel ve datos sensibles: la factura de tus nubes, las cuentas conectadas, el gasto en modelos de IA y la postura de seguridad. Cuando el equipo crece, gestionar quién entra con contraseñas sueltas deja de escalar: alguien se va de la empresa y su acceso sigue vivo, otra persona necesita permisos de administrador durante una semana y nadie se acuerda de quitárselos. El SSO empresarial lo resuelve conectando AAA Sentinel al directorio que tu empresa ya usa.

Por qué usar SSO empresarial

Con el SSO activado, tu proveedor de identidad (IdP) pasa a ser la única puerta de entrada:

• Bajas en un solo sitio: desactivas a la persona en el directorio y deja de poder iniciar sesión en AAA Sentinel, sin tocar la plataforma.
• Roles sincronizados: cada grupo del IdP se asigna a un rol (Administrador, Aprobador, Finanzas o Visualizador) y el rol se recalcula en cada inicio de sesión.
• Las políticas de tu empresa se aplican también aquí: MFA, acceso condicional o duración de la sesión las decide tu IdP.
• Dominio verificado: sólo entra por SSO quien tiene un email de un dominio que has demostrado controlar con un registro DNS.
• Menos contraseñas y menos soporte: nadie tiene que recordar otra clave ni pedir que se la restablezcan.

Cómo se configura en AAA Sentinel

El SSO está disponible en el plan Business y lo configura el propietario de la organización desde Gestión → Configuración, en la tarjeta «SSO empresarial». Son cinco pasos:

• Elige el protocolo, SAML u OIDC. Queda fijado al guardar; para cambiarlo hay que eliminar la configuración.
• Copia en tu IdP los datos que muestra el panel: con SAML, la URL de respuesta (ACS), el identificador de entidad y la URL de cierre de sesión; con OIDC, la URL de redirección.
• Rellena los datos del IdP (la URL de metadatos en SAML; issuer, client ID y secreto en OIDC), el claim del email, el de los grupos y la tabla grupo → rol.
• Verifica tu dominio publicando el registro TXT que te da el panel. La coincidencia tiene que ser exacta.
• Pulsa «Probar conexión»: abre el login de tu IdP en otra pestaña y confirma que todo responde, sin cambiar tu sesión. Con todo en verde, activa el SSO.

SAML u OIDC: cuál elegir

Los dos protocolos funcionan. La diferencia está en los detalles:

• SAML: el cierre de sesión es completo (al salir de AAA Sentinel también se cierra la sesión del IdP) y los grupos viajan como atributo multivalor. Es la opción recomendada si quieres sincronizar roles con Microsoft Entra ID u Okta.
• OIDC: se configura con menos datos (issuer, client ID y secreto). AAA Sentinel cierra también la sesión del IdP siempre que este publique un end_session_endpoint y permita cerrarla con el client ID.
• En ambos casos, apagar el SSO suspende a quienes entran por él, porque no tienen contraseña, y dejan de contar como puesto. Vuelven al reactivarlo si siguen cabiendo en el plan.

Caso práctico: Auth0 como proveedor de identidad

Probamos la integración completa con un tenant gratuito de Auth0, primero con SAML y después con OIDC. Lo común a los dos se hace una sola vez: una Action que publica los roles de cada persona (Actions → Library → Build Custom, con el trigger Login / Post Login) y los ajustes de la aplicación. La misma Action sirve para los dos protocolos:

// Actions → Library → Build Custom → Login / Post Login
exports.onExecutePostLogin = async (event, api) => {
  const roles = event.authorization?.roles ?? []
  const joined = roles.join(',')

  // OIDC: claim con namespace, en el ID token y en el access token (AAA Sentinel lo lee de userinfo)
  api.idToken.setCustomClaim('https://aaa-sentinel.com/groups', joined)
  api.accessToken.setCustomClaim('https://aaa-sentinel.com/groups', joined)

  // SAML: atributo multivalor "groups"
  if (api.samlResponse) api.samlResponse.setAttribute('groups', roles)
}

• Usa los Roles de Auth0 (User Management → Roles) como grupos: crea uno por cada rol que quieras mapear y asígnalo a cada persona. El nombre del Role es exactamente lo que escribirás después en el mapeo del panel.
• Allowed Callback URLs y Allowed Logout URLs admiten varias URLs separadas por comas: con las de la tabla te sirven para SAML y para OIDC. Pulsa Save Changes al final de la página.

Auth0 con SAML

En la pestaña Addons de la aplicación, activa SAML2 Web App. En su pestaña Settings, Application Callback URL es la URL de respuesta del panel y el campo Settings lleva este JSON, con el bloque logout para el cierre de sesión único:

{
  "audience": "<identificador de entidad que muestra el panel>",
  "recipient": "https://auth.aaa-sentinel.com/saml2/idpresponse",
  "destination": "https://auth.aaa-sentinel.com/saml2/idpresponse",
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  ],
  "logout": {
    "callback": "https://auth.aaa-sentinel.com/saml2/logout",
    "slo_enabled": true
  }
}

• La URL de metadatos está en la pestaña Usage del addon, en Identity Provider Metadata: cópiala con clic derecho → «copiar dirección del enlace». Si haces clic normal, descargas el XML, y el panel pide la URL.

Auth0 con OIDC

Con OIDC no hace falta ningún addon: basta la aplicación y la Action de arriba. En el panel de AAA Sentinel van estos valores:

• El issuer lleva la barra final: es exactamente el valor que Auth0 publica como issuer.
• El secreto no se puede leer de vuelta: escríbelo de nuevo cada vez que guardes la configuración.
• AAA Sentinel lee los grupos del endpoint userinfo, no sólo del ID token. Por eso la Action publica el claim con namespace, también en el access token y con los roles unidos por comas.
• Al salir de AAA Sentinel también se cierra la sesión de Auth0, a través de su end_session_endpoint. Para eso https://app.aaa-sentinel.com/login tiene que estar en Allowed Logout URLs, como en la tabla de la aplicación.

Los errores que más tiempo nos hicieron perder

Ninguno es un fallo de la plataforma, pero desde fuera todos se parecen: «entro, pero no con el rol que toca». Esta es la lista para revisar:

• Nombres de grupo que no coinciden: el mapeo distingue mayúsculas y plurales. Un rol llamado finops-admin no casa con finops-admins, y la persona entra con el rol por defecto.
• La Action desplegada pero fuera del flujo: Auth0 no envía ningún grupo y todo el mundo entra con el rol por defecto.
• Un email que no pertenece al dominio verificado: el SSO no se ofrece para él. Los usuarios de prueba necesitan un email del dominio, aunque no tenga buzón.
• Sesiones del IdP que siguen abiertas: si al cambiar de usuario entras sin que te pida contraseña, revisa que la URL de cierre de sesión esté permitida en el IdP.

¿Y con Microsoft Entra ID u Okta?

Los pasos en AAA Sentinel son los mismos con cualquier proveedor; lo que cambia es la configuración en el IdP. Lo que hicimos en Auth0 (la Action y el namespace del claim) es propio de Auth0. Estos son los puntos a vigilar en los otros dos:

• Microsoft Entra ID: por defecto envía los grupos como Object ID (un GUID), no como nombre, así que el mapeo grupo → rol se rellena con esos identificadores, salvo que configures el claim para enviar nombres. Los usuarios sin buzón tienen el email vacío: mapea el email al UPN. El dominio .onmicrosoft.com no se puede verificar; necesitas un dominio propio. Y Entra no devuelve los grupos en userinfo, así que para sincronizar roles usa SAML.
• Okta: el claim de grupos se define en el servidor de autorización y tiene que incluirse para cualquier scope, porque AAA Sentinel sólo pide openid y email. Su cierre de sesión OIDC exige un token que la plataforma no guarda, así que con OIDC la sesión de Okta sigue abierta al salir; con SAML el cierre es completo.
• Con cualquier proveedor: usa «Probar conexión» antes de activar y entra con un usuario de cada grupo para validar los roles.

Checklist antes de activar

Con todo esto en orden, el día que alguien deje la empresa basta con desactivarlo en el directorio para que no pueda volver a iniciar sesión. Si además quieres cortar una sesión que tenga abierta, quítalo desde Usuarios.

• Plan Business y acceso como propietario de la organización.
• Un dominio propio y acceso a su DNS para publicar el registro TXT.
• Los grupos del IdP creados, con los nombres exactos que vas a mapear.
• La URL de respuesta y la de cierre de sesión dadas de alta en el IdP.
• La prueba de conexión en verde y tres usuarios de prueba validados.