Lista de verificación para licitaciones de SSO de Office 365

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.

Protocolo y método de federación: lo primero que hay que preguntar

"Compatible con Office 365" puede significar tres cosas distintas, y cada una tiene implicaciones de seguridad diferentes. Exija que el proveedor especifique por escrito:

• SAML 2.0 u OpenID Connect (OIDC): ambos son válidos, pero necesita saber cuál para planificar la configuración en Azure AD / Entra ID.
• Federación real frente a sincronización de contraseñas: algunos proveedores llaman "SSO" a copiar credenciales. No lo es. Deje claro que exige federación basada en tokens.
• Soporte para SP-initiated y IdP-initiated: el flujo iniciado por el proveedor de servicios suele ser el que exige el equipo de seguridad.

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.

Aprovisionamiento y desaprovisionamiento: el punto que olvida compliance

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.

• SCIM 2.0: confirme si el proveedor admite aprovisionamiento automático. Sin SCIM, cada alta y baja es manual.
• Mapeo de grupos y roles: pregunte si los grupos de seguridad de Azure AD se traducen en permisos dentro de la aplicación.
• Tiempo de propagación de la revocación: exija una cifra concreta. "Inmediato" no es una respuesta técnica.

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.

Autenticación multifactor y políticas condicionales

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.

• Verifique que las políticas de acceso condicional se aplican al iniciar sesión en la plataforma del proveedor.
• Pregunte por el manejo de sesiones: duración del token, renovación silenciosa y cierre de sesión forzado.
• Confirme si existe un mecanismo de acceso de emergencia por si falla el IdP.

Datos, residencia y qué se registra en el inicio de sesión

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.

• Solicite la lista exacta de atributos que el proveedor lee del token (correo, nombre, grupos, identificador único).
• Pregunte por la región de alojamiento y la política de retención de registros de acceso.
• Pida los detalles de certificaciones antes de firmar; verifíquelas con documentación, no con una afirmación en una diapositiva.

Evaluar al proveedor, no solo la casilla

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í.

Lista mínima para la matriz de licitación

• Protocolo confirmado (SAML 2.0 / OIDC) con metadatos entregados.
• Aprovisionamiento SCIM y tiempo de revocación documentado.
• Respeto de políticas de acceso condicional de Azure AD.
• Atributos leídos, región de datos y retención definidos por escrito.

• Join Our Newsletter Community Today!