Protocolos de federación y aprovisionamiento
Elige y opera únicamente las interfaces de federación y aprovisionamiento registradas para una aplicación o tenant.
- Identifica la interfazDistingue entre inicio de sesión en navegador, autorización de API, aprovisionamiento de directorio e intercambio con agentes.
- Comprueba el registroConfirma tenant, ciclo de vida, metadatos de proveedor, redirección y perfil de garantía habilitado.
- Intercambia valoresUtiliza los metadatos registrados y el contrato de API de gestión generado.
- Prueba el comportamientoVerifica identidad, asignación, afiliación, cierre de sesión o aprovisionamiento con una identidad de prueba.
- Mantén la integraciónRota credenciales, supervisa la sincronización y desactiva registros obsoletos mediante controles de ciclo de vida.
OIDC, OAuth y PKCE
Los clientes OIDC registrados usan autorización en navegador, selección de cuenta, consentimiento y condiciones cuando están configurados. La autorización de dispositivos es una interfaz distinta, no sustituye al registro del cliente. PKCE y las opciones de mayor garantía dependen de la política del cliente y del tenant. PAR, private-key JWT, mTLS, DPoP y FAPI son condicionales; que existan en el código no significa que estén habilitados.
- Registra el issuer, la redirección y las opciones de respuesta exactos del cliente.
- Completa consentimiento y selección de cuenta; verifica identidad y audience.
- Confirma en la política el soporte de PKCE o de garantía; no debilites la validación para eliminar una denegación.
SAML y cierre remoto de sesión
Las rutas de proveedores de identidad y de servicio SAML exponen metadatos y flujos de aserción en navegador. Configura la conexión mediante la gestión de SAML. Con el socio, valida issuer, audience, destino de respuesta, firma y condiciones temporales. El cierre de sesión es independiente: la revocación local no demuestra que se hayan borrado todas las cookies o sesiones del proveedor de servicio.
- Compara los metadatos de conexión, la clave de firma y los endpoints con los del socio.
- Prueba una aserción firmada y verifica tenant, sujeto, afiliación y vencimiento.
- Usa el cierre admitido y distingue la revocación local de cerrar la sesión remota.
SCIM y sincronización de directorios
El aprovisionamiento es distinto de la federación interactiva. Los esquemas SCIM y la reconciliación conviven con conectores de directorio que usan un agente desplegado en el entorno del cliente. Las importaciones conservan la procedencia del tenant y ponen los conflictos en cuarentena; el correo electrónico por sí solo no vincula cuentas. El servidor no incluye el binario del agente del cliente.
- Registra el destino del tenant y asigna atributos admitidos e identificadores inmutables.
- Ejecuta una sincronización controlada, inspecciona los resultados y resuelve las cuarentenas en el flujo del tenant.
- Despliega y registra por separado el agente compatible antes de encolar tareas del conector.
CAS, WS-Federation y RADIUS
CAS requiere habilitación explícita. WS-Federation y WS-Trust siguen desactivados salvo que un registro o una política permitidos los habiliten; siguen siendo obligatorias las comprobaciones de realm, audience, respuesta, afiliación, firma y vencimiento. RADIUS usa un agente firmado opcional, no un listener del sitio. Su referencia mantenida prefiere RADIUS/1.1 sobre TLS o DTLS; el UDP heredado solo es compatible con redes privadas.
- Antes de probar CAS o WS-Federation, comprueba que estén habilitados y registrados.
- Para RADIUS, confirma el agente del cliente, el conector del tenant y el transporte permitido.
- Si está deshabilitado o el agente no está registrado, resuelve la configuración; no cambies de protocolo para eludir la política.
Registros y credenciales
El registro del cliente debe permanecer dentro del tenant y la aplicación propietarios. El registro dinámico, private-key JWT, mTLS y FAPI describen contratos condicionales, no habilitación universal. Conserva las claves privadas con sus propietarios y rota o revoca las credenciales mediante el control de gestión correspondiente. Las claves de agentes no son credenciales de cliente OAuth.
- Reúne propietario, tenant, redirección o metadatos, scopes y tipo de credencial.
- Guarda de forma segura los secretos que se devuelvan y rótalos o revócalos mediante la gestión.
- Para registrar un agente, crea la clave privada en el lado del cliente y envía su CSR.
Contrato y resolución de problemas
Usa /api/auth/management/openapi.json para consultar operaciones, campos y seguridad actuales de la gestión. Las notas de protocolo mantenidas describen comportamientos más específicos de conectores y garantías. Entre los problemas habituales están tenant incorrecto, redirección no registrada, metadatos o certificado obsoletos, perfil deshabilitado, firma no válida, cuarentena SCIM o agente revocado. Corrige el límite de confianza correspondiente; no desactives la verificación.
- Comprueba el esquema OpenAPI y los requisitos de seguridad de la operación.
- Compara los errores seguros y los valores registrados con los metadatos actuales del proveedor.
- Repite el flujo controlado y confirma identidad o sincronización antes del despliegue.
Preguntas frecuentes
¿Que existan DPoP o FAPI significa que están habilitados?
No. Los perfiles de mayor garantía requieren habilitación explícita y una configuración completa del cliente.
¿Se incluye el agente del cliente?
No. Despliega un agente compatible por separado y confirma que esté registrado y vigente.
¿El cierre SAML elimina todas las sesiones?
No. La revocación local es distinta del cierre remoto y de eliminar la sesión del socio.
¿SCIM vincula usuarios por correo?
No. Asigna tenant, issuer y subject inmutable; resuelve conflictos mediante revisión de cuarentena.
¿Puedo conectar RADIUS directamente al sitio?
No. RADIUS es una interfaz opcional para agentes firmados, no un endpoint de navegador.
¿Dónde están los campos exactos de la API?
Usa /api/auth/management/openapi.json; los ejemplos no constituyen un contrato completo de SDK.