La respuesta breve
La arquitectura de identidad en Salesforce no es un proyecto técnico puntual, sino una capa de control que opera a diario: quién accede, con qué identidad, qué permisos tiene y qué sucede cuando ya no debería tener acceso. La elección entre SAML y OIDC, entre JIT y SCIM, y entre una política de MFA a nivel de IdP o una aplicación interna en Salesforce, parecen detalles de configuración. Sin embargo, estas decisiones determinan el tiempo necesario para bloquear el acceso de un empleado desvinculado y qué parte de estos incidentes solo se descubrirá en una auditoría.
El enfoque correcto no comienza con el protocolo, sino con dos preguntas: ¿Quién es la fuente de verdad de la identidad del usuario? y ¿Cuál es el tiempo máximo permitido entre un evento de desvinculación (Offboarding) y el bloqueo de acceso real? A partir de ahí se derivan todas las demás decisiones: el tipo de federación, el método de aprovisionamiento, la política de sesión y el proceso de 'Break Glass'.
Las organizaciones que también se plantean la cuestión de los permisos en sí, y no solo la autenticación, encontrarán más información en el modelo de permisos de Salesforce.
Mapa de decisiones: Cuatro capas de identidad en Salesforce
| Capa | Cuestión a resolver | Opciones principales | Consecuencias de una mala decisión |
|---|---|---|---|
| Federación y autenticación | Quién es el Identity Provider y cómo confía Salesforce en él | SAML 2.0, OIDC, Delegated Authentication | Doble inicio de sesión, incompatibilidad de atributos, brecha de confianza |
| Aprovisionamiento y ciclo de vida | Cómo se crea, actualiza y desactiva un usuario | JIT Provisioning, SCIM, creación manual | Cuentas huérfanas, acceso que permanece tras la desvinculación |
| Sesión y MFA | Dónde se aplica el nivel de autenticación y la duración de la sesión | MFA en IdP, MFA interno en Salesforce, Session Policies | Elusión de MFA por una ruta alternativa, sesión que nunca expira |
| Break Glass y auditoría | Qué sucede si el SSO falla y quién verifica las anomalías | Usuario de emergencia controlado, Login History, Event Monitoring | Dependencia total del IdP, incapacidad de investigar retrospectivamente |
SAML frente a OIDC: No es una cuestión de "qué es más nuevo"
La elección entre los dos protocolos no debe basarse en una tendencia, sino en la infraestructura existente. SAML opera con XML y aserciones firmadas, y es común en organizaciones con Active Directory Federation Services o un IdP establecido que ya sirve a docenas de otros sistemas. OIDC se construye sobre OAuth 2.0, es más ligero de mantener y especialmente conveniente cuando el mismo IdP necesita servir tanto a consumidores de API modernos como al inicio de sesión de usuarios.
El error común es elegir lo que parece "avanzado" sin verificar qué atributos envía el IdP existente y cómo se mapean a Salesforce (Username, Federation ID, Profile, Permission Set Group). Un mapeo incorrecto de atributos en la fase de configuración a menudo lleva a la corrección manual de docenas de usuarios en producción, y no solo a un cambio de configuración.
Un punto que a menudo se olvida: incluso al elegir OIDC o SAML, es conveniente planificar los inicios de sesión Iniciados por el IdP (IdP-Initiated) y por el Proveedor de Servicios (SP-Initiated) por separado. Algunos de los incidentes de seguridad comunes se deben a que el inicio de sesión SP-Initiated permanece abierto a pesar de que se planeó que todo el proceso de inicio de sesión fuera únicamente a través del portal del IdP.
Aprovisionamiento JIT frente a SCIM: Cuándo "justo a tiempo" no es suficiente
El aprovisionamiento JIT (Just-In-Time) crea o actualiza al usuario en Salesforce en el momento del primer inicio de sesión, según los datos proporcionados por el IdP en la aserción SAML o el token OIDC. Esto es conveniente, económico de implementar y suficiente para la mayoría de las organizaciones donde los usuarios inician sesión regularmente.
El problema: JIT no resuelve el desaprovisionamiento. Si un empleado es eliminado del IdP pero nunca vuelve a iniciar sesión, su usuario permanece activo en Salesforce indefinidamente porque no hay un evento que active una actualización. Es aquí donde entra SCIM (System for Cross-domain Identity Management), que permite la sincronización proactiva desde el IdP a Salesforce, incluida la desactivación inmediata cuando un usuario es eliminado en la fuente.
La regla práctica: si la organización tiene un requisito de desvinculación en horas en lugar de días (contratistas, empleados temporales, acceso a datos sensibles), SCIM no es un "deseable", sino un requisito de cumplimiento. Si el ciclo de rotación de empleados es lento y la gobernanza ya incluye una revisión trimestral de accesos, JIT por sí solo puede ser suficiente, siempre y cuando esté acompañado de un proceso manual documentado para un bloqueo inmediato.
La planificación del aprovisionamiento siempre debe considerarse también frente a la complejidad de la automatización que lo rodea, por ejemplo, cuando hay Flows que ejecutan lógica de asignación de permisos durante la creación del usuario. En este contexto, es relevante la comparación en Flow vs. Apex sobre dónde el código personalizado es valioso.
MFA y política de sesión: Dos capas, no una
Un error común es conformarse con el MFA aplicado en el Identity Provider y asumir que cubre todas las rutas de acceso a Salesforce. En la práctica, mientras exista un usuario que pueda iniciar sesión directamente a través de login.salesforce.com (por ejemplo, una integración, un usuario de API o un administrador con acceso de respaldo), se requiere una política de MFA separada configurada dentro del propio Salesforce (verificación de identidad, niveles de seguridad de sesión).
Además, la política de sesión determina aspectos de fácil omisión: tiempo de espera de la sesión (Session Timeout), "forzar cierre de sesión al expirar la sesión" (Force logout on session timeout), rangos de IP de inicio de sesión (Login IP Ranges) y sesiones de alta seguridad (High Assurance Session) obligatorias para operaciones sensibles (como cambiar permisos o exportar grandes volúmenes de datos). Una organización que configura un MFA robusto pero deja el Session Timeout en el valor predeterminado de dos horas, abre una ventana en la que un ordenador robado mantiene un acceso activo mucho más allá de un tiempo razonable.
Break Glass y auditoría: Cuando el SSO falla, ¿quién accede?
La dependencia total de un IdP externo crea un único punto de falla: si el IdP se cae o si hay un error en la configuración de la federación, nadie puede iniciar sesión, incluido quien necesita solucionar el problema. La solución común es un usuario "Break Glass": una cuenta de superadministrador con autenticación independiente (no ligada al SSO), una contraseña gestionada en una bóveda (Vault) y no en la memoria de una persona, y un MFA separado.
Es importante destacar: 'Break Glass' no es una "puerta trasera conveniente", es un mecanismo de emergencia controlado. Su uso debe activar una alerta automática y debe ser revisado en un día hábil por una entidad distinta de quien lo utilizó. Muchas organizaciones configuran correctamente el usuario, pero olvidan el control continuo: la contraseña no se rota y sus permisos son demasiado amplios por defecto.
Escenario empresarial: Fallo de desvinculación en una compañía de seguros mediana
Supongamos una compañía de seguros con unos seiscientos empleados, que utiliza Okta como Identity Provider y una configuración SAML con Salesforce establecida hace aproximadamente tres años. El aprovisionamiento se basa completamente en JIT: cuando un nuevo empleado inicia sesión por primera vez, se le crea un usuario con un perfil (Profile) y un grupo de conjuntos de permisos (Permission Set Group) según el grupo de Okta al que pertenece.
En uno de los casos, un agente de servicio fue despedido un viernes por la tarde. El equipo de TI lo desactivó en Okta de inmediato. En la práctica, dado que no existía un mecanismo SCIM o un Webhook que sincronizara la desactivación con Salesforce, su usuario permaneció activo allí. Y como su sesión ya estaba activa desde la mañana y no se había configurado "Force logout on session timeout", continuó accediendo al sistema incluso después del despido, hasta que alguien lo notó en una revisión semanal de accesos el lunes.
La solución implementada no fue una transición completa a SCIM (que habría requerido un proyecto separado y un presupuesto de integración), sino la combinación inmediata de tres acciones: activación de "Force logout on session timeout" para todos los perfiles sensibles, reducción del Session Timeout de 120 minutos a 30 minutos para los roles de cara al cliente, y la adición de un paso automático en el proceso de desvinculación organizacional que ejecutara una desactivación directa en Salesforce como una acción independiente y no solo como una consecuencia indirecta de la desactivación en Okta. SCIM quedó como objetivo para el próximo trimestre, ya con presupuesto y aprobación, pero la brecha más peligrosa se cerró en una semana.
Riesgos comunes y acciones preventivas
| Riesgo | Cómo se manifiesta en la práctica | Acción preventiva |
|---|---|---|
| Dependencia total de JIT sin desaprovisionamiento | Usuarios que se fueron permanecen activos indefinidamente | Agregar un paso de desvinculación independiente en Salesforce, no dependiente de la sincronización |
| MFA solo en el IdP | Usuarios de integración y administradores eluden MFA mediante inicio de sesión directo | Política de MFA interna en Salesforce para todos los tipos de usuarios |
| Tiempo de espera de sesión demasiado largo | Un ordenador robado o una sesión olvidada abierta mantienen el acceso durante horas | Reducir el tiempo de espera y el cierre de sesión forzado para perfiles sensibles |
| Break Glass sin control | El uso de una cuenta de emergencia no se detecta a tiempo | Alerta automática y revisión en un día hábil para cada uso |
| Mapeo de atributos incorrecto desde el IdP | El usuario obtiene un perfil o rol incorrecto en el primer inicio de sesión | Prueba de mapeo completa en un entorno de Sandbox antes de cambiar en producción |
Lista de verificación para la implementación o auditoría de la arquitectura de identidad
- ☐ Se ha definido un único Identity Provider como fuente de verdad, y se sabe qué sucede si falla.
- ☐ Se ha elegido el protocolo (SAML u OIDC) según la infraestructura existente y no según una tendencia.
- ☐ El mapeo de atributos entre el IdP y el Perfil/Grupo de Conjuntos de Permisos ha sido verificado en un entorno Sandbox.
- ☐ Se ha definido una política clara: solo JIT, o JIT en combinación con SCIM según los requisitos de desvinculación.
- ☐ El MFA se aplica también dentro de Salesforce, no solo en el IdP.
- ☐ El tiempo de espera de la sesión (Session Timeout) y el cierre de sesión forzado (Force Logout) se configuran según la sensibilidad del perfil.
- ☐ Existe un usuario 'Break Glass' controlado, con MFA separado y contraseña en una bóveda segura.
- ☐ El proceso de desvinculación incluye un paso independiente para la desactivación en Salesforce.
- ☐ El historial de inicio de sesión (Login History) y la monitorización de eventos (Event Monitoring) se revisan según un calendario fijo.
- ☐ Existe un plan de revisión periódica (Access Review) que no depende únicamente de la memoria del equipo de TI.
Cómo medir la efectividad de la arquitectura
El indicador principal no es "si el SSO está activo", sino el tiempo de respuesta entre un evento en la fuente de verdad y un cambio correspondiente en Salesforce: cuánto tiempo transcurre entre la eliminación de un usuario en el IdP y su desactivación real. Un indicador complementario es la proporción de inicios de sesión que se realizan a través de una ruta inesperada (inicio de sesión directo en lugar de a través del IdP), que debería tender a cero, salvo en casos documentados de 'Break Glass'. Un tercer indicador es la frecuencia de las revisiones de permisos en comparación con el estado real; no todos los cambios organizacionales llegan a través del IdP, por lo que una revisión trimestral sigue siendo esencial incluso con aprovisionamiento automático completo.
Para la implementación o auditoría de una arquitectura de identidad en un entorno Salesforce existente, puede avanzar a través de nuestro servicio de arquitectura CRM. Las organizaciones que también exploran la conexión a sistemas ERP y de nóminas como parte de la imagen global de identidad encontrarán información complementaria en integración de Salesforce con ERP y una visión más amplia de la arquitectura en la Guía de arquitectura CRM.
Resumen
La arquitectura de identidad en Salesforce se construye una vez, pero se pone a prueba cada día a través de incidentes aislados: un empleado que se va, una sesión que se olvida abierta, una integración que elude el MFA. Las decisiones clave (SAML frente a OIDC, JIT frente a SCIM, MFA doble, 'Break Glass' controlado) no deben derivarse del valor predeterminado del IdP, sino del tiempo de respuesta necesario para bloquear el acceso y del nivel de sensibilidad de la información expuesta. Una organización que planifica esta capa con antelación, en lugar de descubrir las lagunas en una auditoría o después de un incidente de seguridad, ahorra tanto costos de reparación como riesgos reputacionales y regulatorios.