La mayoría de las licitaciones que exigen SSO de Office 365 fracasan en el mismo punto: el proveedor marca la casilla "compatible con SSO" y nadie pregunta con qué protocolo, cómo se aprovisionan los usuarios ni qué ocurre cuando se revoca un acceso. Un "sí" en una hoja de requisitos no significa una integración funcional con Azure AD. Significa que alguien tiene que verificarlo antes de firmar.
Esta lista está pensada para directores de TI, responsables de cumplimiento y equipos de compras que ya han leído artículos genéricos sobre autenticación única. Lo que sigue son los puntos que separan una integración real de una promesa comercial.
"Compatible con Office 365" puede significar tres cosas distintas, y cada una tiene implicaciones de seguridad diferentes. Exija que el proveedor especifique por escrito:
Pida los metadatos SAML o el endpoint OIDC de ejemplo durante la fase de evaluación, no después de adjudicar. Un proveedor que no puede entregar un archivo de metadatos en 24 horas probablemente no tenga la integración madura.
El SSO resuelve el inicio de sesión, no el ciclo de vida de la cuenta. Cuando un empleado deja la empresa, ¿su acceso a la plataforma del proveedor desaparece automáticamente o queda una cuenta huérfana? Esta pregunta es donde los auditores encuentran hallazgos.
Una observación de quien ha implementado esto: muchos fallos de aprovisionamiento no se detectan en las pruebas porque el entorno de sandbox tiene tres usuarios y el de producción tiene tres mil. Pruebe la baja de un usuario con grupos anidados antes de considerar la integración cerrada.
Si delega la autenticación en Azure AD, debe confirmar que el proveedor respeta sus políticas de acceso condicional. Un buen SSO no reimplementa MFA por su cuenta; deja que su proveedor de identidad aplique las reglas de dispositivo, ubicación y riesgo que ya tiene definidas.
El SSO transporta atributos de identidad. Su equipo de cumplimiento necesita saber qué recibe el proveedor y dónde se almacena. Aquí la naturaleza del producto importa: cuanto menos dato personal maneje la plataforma, más simple es la conversación con protección de datos.
Vemco, por ejemplo, trabaja con conteo de personas conforme al RGPD: sin identificación personal, con exclusión del personal y recuentos agregados. Esto significa que la superficie de datos personales asociada al inicio de sesión de los empleados que administran el sistema queda separada de los datos operativos, que ya son anónimos por diseño. Para un comprador, esa separación reduce el alcance de la evaluación de impacto. La plataforma puede desplegarse en nube alojada o nube privada e integrarse con los sistemas de TI existentes, lo que da margen para alinear la residencia de datos con sus requisitos internos.
La madurez de un proveedor de análisis retail no se mide solo por su SSO, sino por cuántos entornos empresariales ha atravesado. Un fabricante activo desde 2005, con más de 2000 clientes en más de 95 países, ha configurado suficientes integraciones de identidad como para conocer los casos límite: sincronización de directorios híbridos, dominios federados múltiples y renovaciones de certificados SAML que caducan un viernes por la noche.
Ese historial también aparece en la parte operativa del producto. Cuando evalúe precisión de conteo, sea igual de riguroso: la cifra honesta es un mínimo contractual del 96%, con un rendimiento típico del 98–99% cuando la iluminación, el diseño de la tienda y el comportamiento de los visitantes lo permiten. Desconfíe de cualquier proveedor que garantice un 99% plano; las condiciones reales no funcionan así.