OIDC / SSO — connexion via fournisseur d'identité

Cette page décrit le SSO utilisateur : la connexion des personnes à Omniscol via votre fournisseur d'identité. Le cas inverse — Omniscol serveur OAuth2 / OIDC auquel des services tiers se connectent, avec son écran de gestion des clients — est traité sur OAuth2 / OIDC (fournisseur).

Fournisseurs supportés

Omniscol prend en charge :

• Google Workspace,
• Microsoft Entra ID (anciennement Azure AD),
• Keycloak,
• un fournisseur OIDC générique via son issuer / discovery URL (tout fournisseur conforme OIDC).

Configurer côté Omniscol

Dans Administration → Paramètres, section Sécurité, le bouton Configurer ouvre l'écran de configuration OIDC, qui permet de déclarer le fournisseur :

• Nom affiché — le libellé qui apparaîtra sur le bouton de connexion (par exemple Continuer avec Google).
• Type de fournisseur — Google, Microsoft Entra ID (Azure AD), Keycloak ou OIDC générique.
• Tenant / issuer — tenant Microsoft pour Entra ID, ou URL issuer pour Keycloak et les fournisseurs OIDC génériques. Les métadonnées OIDC sont ensuite découvertes par l'application.
• Client ID et Client secret — obtenus en créant une application côté fournisseur (cf. documentation du fournisseur).
• Scopes — par défaut openid profile email. Ajouter les scopes spécifiques au fournisseur si besoin.
• Domaines autorisés — liste optionnelle de domaines de messagerie acceptés à la connexion SSO ; laissée vide, aucun filtrage par domaine n'est appliqué.
• URL de redirection — Omniscol vous donne la valeur exacte à copier dans la configuration côté fournisseur (ainsi que l'URL de redirection post-déconnexion si le fournisseur la demande).
• Connexion uniquement par SSO — une fois le SSO validé, cette option refuse la connexion par mot de passe Omniscol, sauf pour les comptes de secours décrits ci-dessous.

La configuration SSO courante est définie au niveau du compte école.

Accès de secours (break-glass)

En mode Connexion uniquement par SSO, la connexion par mot de passe Omniscol est refusée : tout le monde passe par le fournisseur d'identité. Si ce fournisseur devient indisponible — panne, secret expiré, erreur de configuration — l'accès à Omniscol serait bloqué pour tous.

Le compte de secours (« break-glass ») est le garde-fou contre ce blocage : un compte administrateur autorisé à se connecter par mot de passe Omniscol même lorsque le mode SSO exclusif est actif.

• Dans la fiche d'un compte administrateur, lorsque l'option Connexion uniquement par SSO est active, une case Break-glass (SSO only) apparaît. La cocher autorise ce compte à se connecter par mot de passe si le fournisseur d'identité est indisponible. Seuls les comptes administrateurs peuvent l'être.
• Le support Omniscol conserve par ailleurs un accès de secours indépendant.

Désignez au moins un compte de secours avant d'activer le mode SSO exclusif, et conservez son mot de passe en lieu sûr : c'est votre filet de sécurité si le fournisseur d'identité tombe.

Configurer côté fournisseur (exemples)

Google Workspace

1. Console Google Cloud > APIs & Services > Credentials.
2. Créer un identifiant OAuth 2.0, type Application Web.
3. Coller l'URL de redirection fournie par Omniscol dans Authorized redirect URIs.
4. Récupérer le Client ID et le Client secret pour les coller dans Omniscol.

Microsoft Entra ID

1. Portail Azure > Entra ID > App registrations.
2. New registration, type Web, URL de redirection Omniscol.
3. Certificates & secrets > créer un client secret.
4. API permissions > ajouter openid, profile, email.
5. Récupérer Application (client) ID et le secret.

Keycloak

1. Realm > Clients > Create client, type OpenID Connect.
2. Valid redirect URIs : URL fournie par Omniscol.
3. Credentials > récupérer le client secret.

Faire le lien avec les comptes Omniscol

Quand un utilisateur clique sur le bouton SSO, Omniscol :

1. Le redirige vers le fournisseur,
2. Récupère son adresse e-mail après authentification,
3. Cherche un compte Omniscol avec la même adresse e-mail.

Si le compte existe et qu'il est actif, l'utilisateur est connecté. Sinon, l'accès est refusé. Conséquence : pour que SSO fonctionne, les utilisateurs doivent exister dans Omniscol avec la bonne adresse e-mail — la création n'est pas automatique côté Omniscol par défaut.

Provisioning automatique des comptes

La création automatique de comptes à la première connexion SSO (just-in-time provisioning) n'est pas le comportement par défaut de l'écran de configuration. Si ce mode est nécessaire, il doit être cadré avec Omniscol.