Conclusión por adelantado: antes de conectar el SSO en tu WMS, OMS y TMS, no empieces por la documentación del protocolo. Dedica una tarde a armar una hoja de cálculo de tres columnas — persona, rol en cada sistema, quién desactiva la cuenta cuando se va. Si no puedes llenar esa hoja, no importa si eliges SAML u OIDC. He visto fracasar este proyecto exactamente de la misma forma tres veces, y el punto de quiebre siempre es el mismo: el proveedor de identidad se conecta sin problemas, y el mapeo de roles del lado del negocio es un desastre.
Por qué siempre revienta la noche anterior al lanzamiento
Septiembre de 2023. Un 3PL de 60,000 pies cuadrados en el sur de California, lanzando WMS, OMS y TMS en la misma semana. Para simplificar, el cliente dio al piso un único usuario y contraseña compartidos en los tres sistemas. Suena eficiente, ¿verdad?
Reventó al tercer día. Un representante de servicio al cliente que podía ver pedidos en el OMS también podía editar tarifas de transportistas en el TMS — porque el rol "CSR" significaba cosas completamente distintas en cada sistema, y el login compartido heredaba los permisos más amplios de los tres. El dueño me preguntó: "¿No es esto el single sign-on? ¿Por qué todo se pone más desordenado?" Mi respuesta: eso no es single sign-on. Es un punto único de falla con una pantalla de login.
Cómo lo salvamos fue feo pero efectivo: congelamos de un día para otro unas 40 cuentas compartidas, reconstruimos 120 cuentas individuales mapeadas persona–sistema–rol, pusimos el negocio a andar y luego pasamos dos semanas alineando las matrices de roles y conectando todo a una única fuente de identidad. Ese proyecto me grabó una lección: el SSO responde "quién eres". La autorización responde "qué puedes hacer". Son dos problemas distintos, y nunca debes delegar el segundo en el primero.
La lista: de cero a SSO, paso a paso
Paso 1: Inventaria cada cuenta. Exporta todas las cuentas de los tres sistemas a una hoja de cálculo con tres columnas: usuario, sistema, rol actual. Marca tres tipos — cuentas zombi de empleados que se fueron (casi todos los proyectos tienen entre un 5–10% de ellas), logins "públicos" compartidos (los más comunes en las tablets de picking) y "cuentas dios" con privilegios excesivos. Si no se limpian antes del lanzamiento, el SSO no cambia nada.
Paso 2: Arma la matriz de mapeo de roles. Las filas son roles de negocio (picker, CSR, despachador, supervisor de almacén, finanzas, administrador de TI); las columnas son los tres sistemas; cada celda dice exactamente qué botones puede pulsar ese rol en ese sistema. Cuidado: un "dispatcher" en el TMS y un "dispatcher" en el WMS probablemente no sean lo mismo. Mismo nombre, distintos poderes. Haz que el dueño del negocio firme esta hoja. Sin firma, no hay lanzamiento.
Paso 3: Elige tu fuente de identidad. Si la empresa ya tiene un sistema corporativo de identidad, úsalo como proveedor de identidad — no construyas un segundo. Solo si no hay nada en su lugar pasas a la decisión de protocolo del paso 4.
Paso 4: Elige el protocolo. Sistemas nuevos: primero OIDC. Sistemas legacy: verifica soporte de SAML 2.0. Muchos productos WMS tradicionales solo hablan SAML — no les fuerces OIDC ni reescribas su código. Los agujeros de conejo de la adaptación de protocolos son más profundos de lo que parecen.
Paso 5: Mapea los atributos de usuario. Decide qué pasa el proveedor de identidad hacia abajo: ID de empleado, email, departamento, rol. Pasa al menos un identificador estable y globalmente único — el ID de empleado, no el email, porque los emails se renombran. Para cada campo, nombra la fuente autoritativa: el departamento viene de RR. HH., punto final.
Paso 6: Conecta el flujo de offboarding. La desactivación de cuentas debe engancharse al proceso de terminación de RR. HH., con el objetivo de "desactivado el último día". ¿No se puede automatizar? Entonces TI concilia manualmente la lista de bajas cada viernes por la tarde. He visto este hueco tres veces. A principios de 2024, un almacén de comercio electrónico de artículos para el hogar hizo una auditoría de permisos seis meses después de un lanzamiento limpio de SSO y encontró que un despachador que había renunciado tres meses antes todavía podía entrar al TMS y consultar tarifas de transportistas — porque nadie había sincronizado jamás la lista de bajas de RR. HH. con TI.
Paso 7: Despliega por etapas. Piloto con 5–10 personas de TI durante una semana, luego un almacén, luego todos. Mantén disponible la vía de login anterior como rollback durante el piloto — esa línea está en la parte superior de mi lista de la noche del lanzamiento, permanentemente.
Haz primero los números: SAML vs. OIDC vs. cuentas propias
| SAML 2.0 | OIDC | Cuentas propias | |
|---|---|---|---|
| Ideal para | Sistemas legacy, WMS/ERP tradicionales | Sistemas nuevos, apps cloud-native | Equipos pequeños con uno o dos sistemas |
| Esfuerzo de implementación | Medio (config XML verbosa) | Menor (JSON, ecosistema maduro) | Bajo al inicio, alto después |
| Mantenimiento continuo | Bajo (estándar maduro) | Bajo | Alto (política de contraseñas, auditoría, MFA — todo DIY) |
| Soporte móvil/tablet | Débil | Fuerte | Depende de tu código |
| Costo total a largo plazo | Viejo pero estable | Opción por defecto en proyectos nuevos | Pierde dinero pasado dos sistemas — no |
El marco de decisión es simple: si alguno de los tres sistemas solo soporta SAML, apuesta todo a SAML. ¿Todos los sistemas son nuevos? OIDC. Considera cuentas propias solo si tienes la certeza de no superar dos sistemas en los próximos dos años. El verdadero costo de un sistema de cuentas propio no es construirlo — es el día en que conectas el sistema número cuatro y descubres que los tres primeros inventaron cada uno su propia política de contraseñas.
Lista de la noche del lanzamiento: cada falla vive aquí
- Borra las cuentas de prueba. Casi todos los proyectos descubren entre tres y cinco cuentas estilo test01 aún vivas la noche anterior al lanzamiento.
- No pases las cuentas de administrador por el SSO. Mantén al menos una cuenta local de superadministrador por sistema para el día en que el proveedor de identidad se caiga. Escribe la contraseña en papel y guárdala en una caja fuerte — sí, es primitivo, y sí, ha salvado un lanzamiento.
- Alinea los tiempos de sesión en los tres sistemas. WMS a 8 horas y TMS a 30 minutos van a volver locos a los despachadores. Estandariza en 4–8 horas, con una política separada para las tablets de temporada alta que nunca se bloquean.
- Prueba el escenario de zona muerta. Cuando se cae el Wi-Fi del almacén, la página de redirección del SSO no carga en la tablet y el picker se queda frente al rack mirando al vacío. El fallback en modo degradado debe probarse de verdad, en el piso real.
- Asegúrate de que los logs de auditoría se puedan unir. Cuando algo se rompa, necesitas responder "qué cambió este usuario en el TMS ayer a las 2 p.m." — y los logs de los tres sistemas deben llevar el mismo identificador de usuario.
Una nota contraria para cerrar: mucha gente se siente más segura después de que el SSO sale en vivo. La verdad corre al revés — el SSO convierte "una llave, una puerta" en "una llave, tres puertas", así que una llave perdida cuesta tres veces más. El MFA no es opcional con SSO; es parte del paquete. ¿Demasiada fricción? Entonces aplícalo al menos para los roles de administradores y finanzas.
Una cosa que puedes hacer mañana: exporta las cuentas de los tres sistemas y colócalas en las tres columnas del paso 1. La primera verdad que descubrirás suele ser esta — las 80 cuentas que creías tener son en realidad 110.
Por Lin Xiao, Consultor de Implementación de WMS
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
