Migrer depuis un OIDC auto-hébergé

Migrer d'un OIDC auto-hébergé vers Lurus Auth

L'entreprise dispose déjà d'un IdP (Keycloak / Auth0 / Okta / Azure AD) et souhaite que ses employés continuent à se connecter avec leur compte d'entreprise, tout en externalisant la couche d'identité vers Lurus.

Deux stratégies

Stratégie A : Lurus Auth comme IdP secondaire (recommandé)

Vous ne gérez que le cycle de vie des utilisateurs de l'IdP d'entreprise ; les produits Lurus lisent l'identité via la fédération OIDC.

Stratégie B : déménagement complet

Le Keycloak/Auth0 d'origine est exporté via SCIM vers Lurus Auth (Casdoor), qui devient l'unique source de vérité.

Stratégie A — topologie de fédération

策略 A：联邦

graph LR
  IDP[企业 IdP 既有] -->|OIDC 联邦| LA[Lurus Auth]
  LA --> P[所有 Lurus 产品]

Stratégie B — topologie de déménagement

策略 B：搬家

graph LR
  KC[原 Keycloak/Auth0] -->|SCIM 导出| LA[Lurus Auth · Casdoor]
  LA --> D[所有下游]

Étapes de la stratégie A (recommandée)

1. Créer une connexion de fédération dans la console Lurus — Rendez-vous sur identity.lurus.cn → Paramètres de l'entreprise → Fournisseurs d'identité → Nouveau → choisir OIDC. Renseignez, pour l'IdP de l'entreprise :

   • Issuer URL
   • Client ID
   • Client Secret
   • URL de rappel (fournie par Lurus)

2. Mappage des claims — Mappez les attributs de l'IdP d'entreprise vers les utilisateurs Lurus.

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

3. Bascule progressive — Dans l'IdP d'entreprise, autorisez d'abord 5 % des employés à utiliser le bouton de connexion Lurus. Validez pendant 1 semaine → ouvrez ensuite à l'ensemble du personnel.

Étapes de la stratégie B

1. Exporter via SCIM — Exportez les utilisateurs depuis Keycloak au format JSON :

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

2. Import en masse dans Lurus

   POST/admin/v1/scim/users:batchImport批量导入用户（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. Politique de mot de passe — Par défaut, Lurus ne migre pas les mots de passe (hachages incompatibles) ; à la première connexion, le flux « mot de passe oublié » est imposé. Avec la fédération SSO, aucune migration de mot de passe n'est nécessaire.

Les atouts de la fédération SSO

Conformité d'entreprise

Le cycle de vie des comptes reste entièrement dans l'entreprise.

Révocation immédiate au départ

Désactivation dans l'IdP d'entreprise → connexion Lurus impossible aussitôt.

Audit unifié

Les journaux de connexion résident dans l'IdP d'entreprise.

Réutilisation du MFA

La politique MFA existante de l'entreprise reste en vigueur.

Questions fréquentes

Les sessions vont-elles entrer en conflit ?

Lurus utilise un cookie de session indépendant, sans impact sur le système d'origine.

Peut-on conserver les PAT / JWT ?

Oui, les Tokens de niveau API ne sont pas affectés par la migration SSO.

Comment exporter les journaux d'audit ?

Tous les événements d'identité peuvent être exportés en masse via l'endpoint ci-dessous :

POST/admin/v1/audit:export批量导出身份事件

Étapes suivantes

Étapes suivantes

Présentation de Lurus AuthOIDC / OAuth2Modèles de déploiement en entreprise