Dos direcciones
El SSO empresarial inbound significa que XID actúa como proveedor de servicios SAML o relying party OIDC para el IdP de una empresa. El SSO de SaaS downstream significa que XID actúa como proveedor de identidad SAML u OIDC para aplicaciones como Slack, GitHub Enterprise Cloud, aplicaciones personalizadas de Microsoft, Atlassian, Salesforce y Zoom.
Ambas direcciones constituyen líneas de evidencia independientes. Una ejecución local con un IdP simulado o un SaaS simulado verifica la base de implementación, pero solo una ejecución con un IdP externo real o realizada por un administrador de SaaS puede respaldar una declaración de estado production-supported.
flowchart LR IdP -->|SAML / OIDC| xidSp["XID SP / RP"] xidIdP["XID IdP"] -->|SAML / OIDC| SaaS
Estado del IdP empresarial upstream
| Proveedor | Protocolos | Estado |
|---|---|---|
| Microsoft Entra ID | SAML, OIDC, SCIM inbound | Estado provider-ready; falta una L4 real de IdP. |
| Okta | SAML, OIDC, SCIM inbound | Estado provider-ready; falta una L4 real de IdP. |
| Google Workspace | SAML, OIDC, SCIM inbound | Estado provider-ready; falta una L4 real de IdP. |
| OneLogin | SAML, OIDC, SCIM inbound | Estado provider-ready; falta una L4 real de IdP. |
| JumpCloud | SAML, OIDC, SCIM inbound | Estado provider-ready; falta una L4 real de IdP. |
| PingOne | SAML, OIDC | Estado provider-ready; falta una L4 real de IdP. |
| PingFederate | SAML, OIDC | Estado provider-ready; falta una L4 real de IdP. |
| AD FS | SAML, OIDC, WS-Fed legacy baseline | Implementado localmente; aún falta AD FS WS-Fed L4 real. |
| Shibboleth | SAML, OIDC | Estado provider-ready; falta una L4 real de IdP. |
| Keycloak | SAML, OIDC, LDAP legacy baseline | Implementado localmente; el puente Kerberos nativo solo está documentado. |
Estado del SSO de SaaS downstream
| SaaS | Dirección | Estado |
|---|---|---|
| Slack | XID como IdP SAML | Estado provider-ready con una base SAML outbound local; falta una L4 real de administración de Slack. |
| GitHub Enterprise Cloud | XID como IdP SAML | Estado provider-ready con una base SAML outbound local; falta una L4 real de GitHub Enterprise. |
| Aplicación empresarial personalizada de Microsoft | XID como IdP SAML u OIDC | Estado provider-ready con una base genérica de SAML/OIDC; falta una L4 real de una aplicación personalizada de Entra. |
| Atlassian | XID como IdP SAML | Estado provider-ready con una base SAML outbound local; falta una L4 real de administración de Atlassian. |
| Salesforce | XID como IdP SAML u OIDC | Estado provider-ready con una base genérica de SAML/OIDC; falta una L4 real de administración de Salesforce. |
| Zoom | XID como IdP SAML u OIDC | Estado provider-ready con una base genérica de SAML/OIDC; falta una L4 real de administración de Zoom. |
Límites de protocolos heredados
- LDAP direct bind, WS-Federation, bóveda SWA, SSO por encabezados y framework de conector de directorio están implementados localmente con fake harness L3. Aún faltan gateway AD/LDAP real, AD FS WS-Fed, bóveda de app destino y Application Proxy L4.
- El inicio de sesión vinculado, IWA nativo y la terminación Kerberos no están soportados.
- SAML Single Logout está implementado y verificado localmente en L1/L2 para SAML entrante y saliente. El perfil de Slack queda excluido porque Slack no admite SLO; la evidencia L4 con IdPs reales y SaaS posteriores sigue siendo UNKNOWN.
- Las filas con estado provider-ready no deben describirse como production-supported hasta que exista evidencia L4 externa real.