Authentik et SSO
Authentik est le fournisseur d'identité du club. Les membres se connectent une fois avec leur compte AD, et Authentik les connecte ensuite aux applications compatibles (GitLab, Vaultwarden…) : c'est l'authentification unique (SSO).
| Élément | Valeur |
|---|---|
| Adresse | https://auth.formuleets.ca (interface d'admin : bouton Admin interface) |
| Machine | VM 131 fsae-auth sur formule-pve-02, Debian 13, 10.194.24.61 |
| Version | Authentik 2026.8.5, en Docker Compose (PostgreSQL 16, server, worker) |
| Gestion | VM créée par OpenTofu (tofu/envs/prod/main.tf), configurée par Ansible (rôles common, ad_dns, authentik, playbook authentik.yml) |
| Compte d'admin | akadmin |
| Comptes des membres | synchronisés depuis l'AD |
L'emplacement dans Vaultwarden du mot de passe d'akadmin, de celui de svc-authentik, et des Client ID / Client Secret de chaque application.
Où en est le SSO
| Application | État | Comment |
|---|---|---|
| GitLab | Pilote | OpenID Connect, groupe sso-pilote |
| Vaultwarden | Pilote | OpenID Connect, groupe sso-pilote |
| Google Workspace (Gmail, Drive…) | Pilote | SAML, groupe sso-pilote dans Authentik et dans Google |
| OpenProject | Mêmes identifiants, sans SSO | Le SSO d'OpenProject est payant (Enterprise). OpenProject se connecte directement à l'AD en LDAPS. |
| OPNsense, TrueNAS, FOG | À faire | Pas d'OpenID Connect : connexion LDAP à l'AD (ou jonction à l'AD pour TrueNAS) |
| WAPT, WD My Cloud | Impossible | Pas de connexion AD dans WAPT Community, ni sur le NAS WD |
Pour l'instant, seuls les membres du groupe sso-pilote (groupe créé dans Authentik, pas dans l'AD) peuvent utiliser le SSO. Pour tous les autres, la connexion classique par mot de passe continue de fonctionner partout.
L'installation
Le rôle Ansible authentik installe Docker et lance le fichier Compose officiel, dans /opt/authentik, avec une différence : le worker n'a pas accès au socket Docker de la machine. Il ne sert qu'aux « outposts » gérés par Docker, qu'on n'utilise pas, et il donnerait au conteneur le contrôle de la machine.
- Secrets : le mot de passe de la base et la clé secrète sont générés une seule fois par Ansible, dans
/opt/authentik/.env(root,0600). Ils ne sont ni dans le dépôt ni dans un coffre. - Publication : Caddy, sur OPNsense, publie
auth.formuleets.cavers10.194.24.61:9000(voir Ajouter un sous-domaine). Un enregistrementAauthchez Cloudflare pointe vers142.137.247.115. - Monter de version : lire les notes de version d'Authentik, changer
authentik_versiondansansible/roles/authentik/defaults/main.yml, puis relancer le playbook.
Pour relancer le playbook, depuis la VM elle-même (Ansible y est installé) :
cd ~/infra-ansible # copie du dossier ansible du dépôt
ansible-playbook playbooks/authentik.yml --limit fsae-auth -e ansible_connection=local
Authentik est sauvegardé chaque nuit sur la VM (voir Sauvegarde Authentik), mais pas encore hors site. Sans le .env, une sauvegarde de la base est inutilisable : il est inclus dans la sauvegarde.
La source Active Directory
Authentik recopie les comptes et les groupes de l'AD : Directory → Federation and Social login → Active Directory.
| Réglage | Valeur |
|---|---|
| Server URI | ldaps://ad-fsae.formulesae.local:636 |
| StartTLS | désactivé (on utilise ldaps://, chiffré dès la connexion) |
| Use Server URI for SNI verification | activé (l'AD répond en TLS 1.3) |
| TLS Verification Certificate | CA FormuleSAE AD : l'autorité du domaine FormuleSAE-AD-FSAE-CA, valide jusqu'en 2036 |
| Bind CN | svc-authentik@formulesae.local : compte de service en lecture seule, dans FormuleSAE → ComptesService, membre d'aucun groupe |
| Base DN | DC=FormuleSAE,DC=local |
| Additional User DN / Group DN | OU=Utilisateurs,OU=FormuleSAE / OU=Groupes,OU=FormuleSAE |
| User object filter | (&(objectClass=user)(!(objectClass=computer))) |
| Object uniqueness field | objectSid |
| User password writeback | désactivé : l'AD reste la seule référence des mots de passe |
| Mappings utilisateurs | les 4 « Active Directory Mapping », plus DN to User Path, mail, Name |
| Mappings groupes | uniquement LDAP Mapping: Name |
La synchronisation passe toutes les deux heures. Pour la forcer (après avoir modifié un compte dans l'AD) : page de la source → Run sync.
Les comptes désactivés dans l'AD arrivent désactivés dans Authentik. Les mots de passe ne sont pas copiés : Authentik les vérifie auprès de l'AD à chaque connexion.
Les applications rattachent la connexion SSO au bon compte par l'adresse courriel, qui vient du champ Adresse de messagerie du compte AD. Un compte AD sans adresse ne peut pas être rattaché. Au 2026-11-10, 37 comptes actifs sur 85 n'en ont pas. Les adresses du club suivent le format prénom.nom@formule-ets.ca, mais pas toutes : vérifie-les dans Google Workspace.
Les applications branchées
GitLab
| Côté Authentik | Valeur |
|---|---|
| Application / slug | GitLab / gitlab |
| Fournisseur | OAuth2/OpenID, Confidential |
| Redirect URI (Strict) | https://gitlab.formuleets.ca/users/auth/openid_connect/callback |
Côté GitLab, la configuration est dans /etc/gitlab/gitlab.rb (bloc omniauth, sauvegarde de l'ancienne version dans /root/gitlab.rb.avant-sso) :
- issuer
https://auth.formuleets.ca/application/o/gitlab/, avec découverte automatique et PKCE ; - l'identifiant du compte est le
preferred_username, c'est-à-dire l'identifiant AD ; - liaison automatique par adresse courriel au compte GitLab existant ;
- un nouveau compte créé par le SSO reste bloqué jusqu'à la validation d'un admin.
Pour lier à la main un compte GitLab existant (quand les adresses diffèrent) : le membre se connecte avec son mot de passe, puis Profil → Compte → Service sign-in → Connect Authentik.
Vaultwarden
| Côté Authentik | Valeur |
|---|---|
| Application / slug | Vaultwarden / vaultwarden |
| Redirect URI (Strict) | https://bitwarden.formuleets.ca/identity/connect/oidc-signin |
| Scopes | openid, profile et Vaultwarden : email vérifié à la place du mapping email par défaut |
Le mapping Vaultwarden : email vérifié déclare les adresses comme vérifiées : Vaultwarden refuse sinon la connexion (« You need to verify your email with your provider »). C'est acceptable, puisque les adresses sont saisies par l'IT dans l'AD.
Côté Vaultwarden (panneau admin → OpenID Connect SSO settings) : SSO activé, Only SSO login désactivé, Allow email association activé, PKCE, et Use SSO only for auth not the session lifecycle activé.
Le mot de passe maître reste demandé après le SSO : le coffre est chiffré avec, et ni Authentik ni l'IT ne peuvent l'ouvrir.
Beaucoup de comptes Vaultwarden utilisent l'adresse de l'école (@ens.etsmtl.ca). Pour que le SSO les reconnaisse, chaque membre doit passer à son adresse du club : Mon compte → Changer d'adresse (mot de passe maître, nouvelle adresse, puis le code reçu par courriel). Le mot de passe maître ne change pas.
Google Workspace
Ici, Authentik est le fournisseur d'identité SAML de Google : le membre tape son adresse sur Google, est renvoyé vers auth.formuleets.ca, entre son mot de passe AD, puis revient dans Gmail. Mis en place le 2026-11-11, testé avec tbarbier.
| Côté Authentik | Valeur |
|---|---|
| Certificat de signature | google-workspace-saml (System → Certificates), RSA, valide jusqu'au 2031-11-10 |
| Application / slug | Google Workspace / google-workspace (le slug est dans l'URL donnée à Google : ne pas le changer) |
| Fournisseur | SAML, flux default-provider-authorization-implicit-consent |
| ACS URL | https://accounts.google.com/samlrp/02ge214q12tm7sw/acs |
| Audience | https://accounts.google.com/samlrp/02ge214q12tm7sw |
| EntityID/Issuer override | https://auth.formuleets.ca |
| Liaison du fournisseur de services | Post (affiché « Appliquer » dans l'interface en français) |
| Signature | assertions et réponses signées, SHA256 |
| Mappage NameID | authentik default SAML Mapping: Email (sans lui, Google reçoit un identifiant opaque et ne trouve pas le compte) |
| Liaison | groupe sso-pilote |
| Côté Google (console d'administration) | Valeur |
|---|---|
| Profil SSO | Sécurité → Authentification → SSO avec un fournisseur d'identité tiers → profil SAML Authentik |
| ID d'entité de l'IdP | https://auth.formuleets.ca |
| URL de connexion | https://auth.formuleets.ca/application/saml/google-workspace/sso/binding/redirect/ |
| Déconnexion, changement de mot de passe | vides |
| Certificat de validation | google-workspace-saml exporté d'Authentik (certificat seulement, jamais la clé privée) |
| Attribution | groupe Google sso-pilote@formule-ets.ca (accès Restricted, Only invited users), profil Authentik - SAML, Google redirige vers l'IdP |
Formule ETSDans Gérer les attributions de profils SSO, la portée par défaut est l'unité organisationnelle Formule ETS. Le Workspace est partagé avec d'autres clubs : sous l'UO Clubs, il y a aussi Baja ETS et Eclipse, qu'on ne touche jamais. L'y attribuer fait passer tout le club par Authentik d'un coup, y compris les comptes sans adresse dans l'AD ou hors de sso-pilote côté Authentik : ils ne peuvent plus se connecter. Toujours choisir l'onglet Groupes à gauche, et vérifier la ligne « Showing settings for users in … » avant Override.
Points à connaître :
- Google n'applique jamais le SSO aux super-admins : ils gardent le mot de passe Google, c'est l'accès de secours. Pour tester, utiliser un compte simple utilisateur.
- Le SSO ne crée pas les comptes Google : un membre doit déjà avoir son compte Google, avec la même adresse que le champ Adresse de messagerie de l'AD.
- Pour ajouter quelqu'un au pilote : l'ajouter au groupe
sso-pilotedans Authentik et au groupe Googlesso-pilote@formule-ets.ca. - Pour tout annuler : retirer l'attribution du profil au groupe Google (Unset). Les membres retrouvent leur mot de passe Google en quelques minutes.
- Le certificat expire le 2031-11-10 : en générer un nouveau avant, l'ajouter au profil Google (deux certificats sont acceptés), puis basculer le fournisseur Authentik dessus.
Ajouter une application
- Applications → Providers → Create → OAuth2/OpenID Provider :
- Authorization flow :
default-provider-authorization-implicit-consent; - Client type : Confidential ;
- Redirect URIs : Strict, l'adresse de retour donnée par la documentation de l'application ;
- Signing Key :
authentik Self-signed Certificate.
- Authorization flow :
- Applications → Applications → New Application (le bouton principal) : nom, slug, et le fournisseur choisi dans la liste. Dans UI settings, la Launch URL de l'application.
- Dans l'application → Policy / Group / User Bindings → Bind existing policy/group/user → Group :
sso-pilotependant les essais. - Dans l'application elle-même : l'issuer
https://auth.formuleets.ca/application/o/<slug>/, le Client ID et le Client Secret (rangés dans Vaultwarden). - Teste avec un compte du pilote, dans une fenêtre de navigation privée.
Le menu New Application → with New Provider… propose un assistant tout-en-un, mais selon la version il n'ouvre que le formulaire simple. Créer le fournisseur d'abord, comme ci-dessus, marche toujours.
Élargir le pilote
- Vérifier que les membres concernés ont une adresse courriel dans l'AD, identique à celle de leurs comptes GitLab, Vaultwarden et Google. Pour Google, élargir aussi le groupe Google auquel le profil SSO est attribué (jamais l'UO entière, voir Google Workspace).
- Ajouter un groupe aux liaisons des applications, par exemple
GG_IT, puisGG_Lead, avant de les ouvrir à tous. - Une fois tout le monde passé, envisager Only SSO login dans Vaultwarden et la désactivation du mot de passe dans GitLab.
Problèmes connus
| Symptôme | Cause | Solution |
|---|---|---|
Synchro AD : LDAPServerPoolExhaustedError | Les conteneurs ne résolvent pas ad-fsae.formulesae.local : le DNS interne de Docker passe par systemd-resolved, qui ignore les noms en .local | Rôle Ansible ad_dns (domaine FormuleSAE.local déclaré au résolveur) |
Synchro AD : invalidCredentials … data 52e | Mauvais identifiant ou mot de passe de svc-authentik | Bind CN svc-authentik@formulesae.local ou FORMULESAE\svc-authentik, mot de passe copié depuis Vaultwarden |
Synchro AD qui échoue avec ldaps:// | StartTLS activé en même temps | Désactiver StartTLS |
Erreur 500, Permission denied: '/templates/…' | Dossiers illisibles pour l'utilisateur 1000 des conteneurs | Corrigé dans le rôle authentik |
| « Request has been denied » sur l'installation initiale | Il faut partir de l'adresse racine | Ouvrir http://10.194.24.61:9000/, qui redirige vers l'assistant |
| GitLab : compte « en attente d'approbation » au lieu du compte existant | Pas d'adresse (ou adresse différente) côté AD | Rejeter le compte créé, remplir l'adresse dans l'AD, ou lier le compte à la main |
| GitLab : « Extern uid has already been taken » | L'identité est encore attachée au compte créé par le SSO | Rejeter ce compte, attendre une minute, puis relier |
| Vaultwarden : « You need to verify your email with your provider » | Authentik envoie l'adresse comme non vérifiée | Mapping Vaultwarden : email vérifié sur le fournisseur |
Sur une installation neuve, le premier qui ouvre la page d'installation crée le compte akadmin. Elle est joignable depuis tout le réseau de l'école : crée ce compte immédiatement après l'installation, avant de publier le site.