Migrar desde OIDC autoalojado

Migrar desde OIDC autoalojado a Lurus Auth

La empresa ya tiene un IdP (Keycloak / Auth0 / Okta / Azure AD) y quiere que los empleados sigan iniciando sesión con su cuenta corporativa, a la vez que externaliza la capa de identidad a Lurus.

Dos estrategias

Estrategia A: Lurus Auth como IdP secundario (recomendada)

Tú solo gestionas el ciclo de vida de los usuarios en el IdP corporativo; los productos Lurus leen la identidad mediante federación OIDC.

Estrategia B: Migración completa

El Keycloak/Auth0 original se exporta mediante SCIM a Lurus Auth (Casdoor), que pasa a ser la única fuente de verdad.

Estrategia A — Topología de federación

Estrategia A: Federación

graph LR
  IDP[IdP corporativo existente] -->|Federación OIDC| LA[Lurus Auth]
  LA --> P[Todos los productos Lurus]

Estrategia B — Topología de migración

Estrategia B: Migración

graph LR
  KC[Keycloak/Auth0 original] -->|Exportación SCIM| LA[Lurus Auth · Casdoor]
  LA --> D[Todos los sistemas posteriores]

Pasos de la estrategia A (recomendada)

1. Crear la conexión de federación en la consola de Lurus — Accede a identity.lurus.cn → Configuración de empresa → Proveedores de identidad → Nuevo → selecciona OIDC. Introduce los datos del IdP corporativo:

   • Issuer URL
   • Client ID
   • Client Secret
   • URL de callback (la proporciona Lurus)

2. Mapeo de claims — Asigna los atributos del IdP corporativo a los usuarios de Lurus.

   # 将企业 IdP 的属性映射到 Lurus 用户
   email:       email
   display:     name
   department:  department   # custom claim

3. Conmutación gradual — En el IdP corporativo, habilita primero el botón de inicio de sesión de Lurus para el 5 % de los empleados. Valida durante 1 semana → amplía a toda la plantilla.

Pasos de la estrategia B

1. Exportar SCIM — Exporta los usuarios de Keycloak a JSON:

   ./kcadm.sh get users -r myrealm --fields username,email,firstName,lastName -f json > users.json

2. Importación masiva a Lurus

   POST/admin/v1/scim/users:batchImportImportar usuarios de forma masiva (identity.lurus.cn)

   curl -X POST https://identity.lurus.cn/admin/v1/scim/users:batchImport \
     -H "Authorization: Bearer $ADMIN_TOKEN" \
     -H "Content-Type: application/json" \
     -d @users.json

3. Política de contraseñas — Por defecto, Lurus no migra las contraseñas (los hashes no son compatibles); en el primer inicio de sesión se fuerza el flujo de "contraseña olvidada". Si se usa federación SSO, no es necesario migrar contraseñas.

Ventajas de la federación SSO

Cumplimiento corporativo

El ciclo de vida de las cuentas reside por completo en la empresa.

Baja inmediata

Si el IdP corporativo desactiva una cuenta → Lurus deja de permitir el acceso al instante.

Auditoría unificada

Los registros de inicio de sesión permanecen en el IdP corporativo.

Reutilización de MFA

Se aplican las políticas de MFA que ya tiene la empresa.

Preguntas frecuentes

¿Habrá conflictos de sesión?

Lurus usa una cookie de sesión independiente, que no afecta al sistema original.

¿Se pueden conservar los PAT / JWT?

Sí; los tokens a nivel de API no se ven afectados por la migración a SSO.

¿Cómo se exportan los registros de auditoría?

Todos los eventos de identidad pueden exportarse de forma masiva mediante el siguiente endpoint:

POST/admin/v1/audit:exportExportar eventos de identidad de forma masiva

Siguientes pasos

Próximos pasos

Resumen de Lurus AuthOIDC / OAuth2Modelos de despliegue empresarial