Fait avec Chinaski

Mettre en place le SSO

Chinaski prend en charge l'authentification unique (SSO) via n'importe quel fournisseur OAuth 2.0 / OpenID Connect standard (flux authorization-code). Un fournisseur par site. Ce guide couvre les deux côtés : enregistrer l'application auprès de votre fournisseur d'identité, et remplir les réglages.

Quoi enregistrer auprès de votre fournisseur d'identité

  1. Créez une application (client) OAuth/OIDC du type standard « authorization code ».
  2. Donnez à votre fournisseur l'URL de redirection que le CMS utilisera :
https://<your-site-domain>/auth/sso/callback

(Votre fournisseur peut l'appeler Redirect URI, Callback URL, ou similaire.) Ce doit être l'adresse exacte à laquelle votre admin est joignable.

  1. Notez les scopes accordés : Chinaski se connecte avec openid email profile et lit les claims sub, email et (s'il est présent) email_verified de l'utilisateur.
  2. Copiez les trois points de terminaison que votre fournisseur expose : presque tous les fournisseurs conformes publient le même trio sous des noms comme « Authorization endpoint », « Token endpoint » et « Userinfo endpoint ».

Quoi remplir dans Chinaski

Sous Settings → Security, activez la case OAuth. Les champs de points de terminaison apparaissent une fois activé :

  • Client ID : l'identifiant d'application/client de votre fournisseur.
  • Client Secret : collez-le une fois ; il est stocké chiffré et le champ reste vide ensuite (sémantique « laissez vide pour conserver l'existant », comme les autres identifiants).
  • Authorization URL : le point de terminaison authorize de votre fournisseur (se termine typiquement par /authorize).
  • Token URL : le point de terminaison token de votre fournisseur.
  • Userinfo URL : le point de terminaison userinfo de votre fournisseur.

Le bouton SSO n'apparaît sur la page de connexion que lorsque tout ce qui précède plus le secret sont enregistrés : une configuration partiellement remplie se vérifie elle-même plutôt que de fonctionner à moitié.

Comment la connexion fonctionne ensuite

  1. La page de connexion admin affiche un bouton « Sign in with SSO » (à côté du formulaire de mot de passe normal, qui fonctionne toujours).
  2. Le cliquer envoie le navigateur vers votre fournisseur, avec un state aléatoire à usage unique pour garder l'échange sûr.
  3. Après que le fournisseur a authentifié la personne, le flux vérifie le state de la réponse et échange le code contre une identité.
  4. Puis la résolution de compte se produit, dans cet ordre :
    • Utilisateur déjà relié : reconnu par son identité de fournisseur (sub).
    • Compte existant par e-mail : si l'e-mail correspond à l'e-mail d'un utilisateur et que le fournisseur le confirme. Ce compte est relié à l'identité SSO ; son mot de passe reste intact.
    • Personne toute nouvelle : un compte est créé automatiquement comme editor avec un mot de passe aléatoire inutilisable ; le journal d'audit consigne l'auto-création.
  5. La session est la session admin standard de 8 heures ; les utilisateurs SSO sont des utilisateurs normaux une fois connectés.

Règles de compte à connaître

  • Editor par défaut. Les comptes créés via SSO sont des editors ; promouvez les gens en admin manuellement.
  • Un seul emplacement de fournisseur. Si vous avez besoin de deux fournisseurs d'identité, ce n'est pas quelque chose que le logiciel actuel prend en charge ; choisissez-en un.
  • La correspondance par e-mail fait confiance à la sémantique de confirmation du fournisseur. Si le fournisseur marque explicitement une adresse comme non vérifiée, la connexion est refusée (et journalisée). Si le fournisseur n'envoie aucun indicateur de vérification, ce que font beaucoup de fournisseurs OIDC pour des comptes confirmés, Chinaski considère l'adresse comme vérifiée. Si votre IdP autorise les e-mails non vérifiés et que vous ne le voulez pas, activez l'application de la vérification e-mail chez lui.
  • Les utilisateurs provisionnés n'ont pas de mot de passe. Un mot de passe aléatoire que personne ne connaît est défini ; ces utilisateurs entrent par le SSO seul, ou un admin leur envoie une réinitialisation de mot de passe par e-mail.
  • Verrouillé ou déconnecté ? Les règles de session standard s'appliquent : la suspension bloque toujours les utilisateurs SSO exactement comme les utilisateurs par mot de passe ; les changements/réinitialisations de mot de passe déconnectent les gens indépendamment de leur mode de connexion.

Dépannage

  • Le bouton SSO n'apparaît pas : un champ requis (ou la case d'activation) est vide. Vérifiez les cinq.
  • « Invalid OAuth state » après le retour du fournisseur : en général, le callback s'est exécuté dans une session/navigateur différent de celui où il a commencé (cookies bloqués, ou domaine d'admin inadapté), ou l'utilisateur a trop attendu sur la page du fournisseur. Réessayez ; si cela persiste, vérifiez que l'URL d'admin dans la barre d'adresse correspond exactement à la redirect URI enregistrée.
  • « Sign in with SSO » absent de la page de connexion : la configuration est incomplète ou la case est désactivée ; les champs ne font partie du flux que lorsqu'ils sont tous remplis.
  • « Email not verified » pour un utilisateur connu : l'IdP a explicitement déclaré que l'e-mail du compte n'est pas vérifié ; corrigez côté fournisseur (ou définissez son e-mail dans le CMS vers un e-mail vérifié).
  • Le compte créé est un editor, pas ce qui était attendu : c'est la règle d'auto-provisioning ; ajustez les rôles dans l'écran des utilisateurs de l'admin.

La version courte

Enregistrez /auth/sso/callback comme callback auprès de n'importe quel fournisseur OAuth/OIDC standard, remplissez cinq champs sous Settings → Security (interrupteur d'activation + client ID + secret chiffré + trois URL de points de terminaison), et la page de connexion gagne un bouton SSO qui connecte les utilisateurs, en reliant les comptes existants par e-mail confirmé, et en créant automatiquement des editors pour les nouvelles personnes.

Lisez ce site en