Authentification et sécurité, SSO compris

Au départ, tout le monde se connecte avec un nom d'utilisateur et un mot de passe. L'adresse e-mail fonctionne à la place du nom d'utilisateur. Si l'envoi de courrier électronique est configuré, le lien « Do you need a password reset? » apparaît sous le formulaire. L'envoi de courrier électronique fait partie de Professional.

Après la connexion, le navigateur reçoit un laissez-passer valable pour une durée définie. La carte « JWT token timer » décide de la durée. Les valeurs de 1 à 24 heures sont autorisées, 12 est la recommandation. Ensuite, la personne doit se reconnecter.

La carte « Password policy » s'applique à chaque mot de passe défini dans le système. Elle est appliquée à la création d'un compte, quand une personne change son propre mot de passe et quand un administrateur en réinitialise un.

Tu définis la longueur minimale, les types de caractères qui doivent apparaître, au bout de combien de jours un mot de passe expire et combien d'anciens mots de passe restent bloqués. Pour les jours et pour la liste de blocage, 0 signifie « désactivé ».

Les règles sur les majuscules et les minuscules n'excluent aucune langue. Beaucoup de systèmes d'écriture n'ont pas cette distinction, et un caractère de l'un d'eux satisfait les deux règles à lui seul.

Les comptes qui se connectent uniquement par SSO ou par un annuaire n'ont pas de mot de passe local, l'expiration ne les concerne donc pas. Leurs règles se trouvent chez le fournisseur. Si un compte existant a été lié au SSO et possède encore son propre mot de passe, l'expiration et la politique de mots de passe continuent de s'appliquer à ce mot de passe.

La carte « 2FA Settings » détermine qui doit utiliser la connexion à deux facteurs. Sous « Two-factor requirement », tu choisis l'un des quatre niveaux : « Off », « Administrators only », « Administrators and agents » ou « Everyone ». « Everyone » inclut les clients. Une nouvelle installation commence avec « Administrators only ». Une installation qui existait déjà garde son réglage précédent après une mise à jour.

La personne qui se connecte ensuite sans second facteur en met un en place. Le système affiche un code QR pour une application d'authentification et la même clé à saisir à la main. Après le premier code, le facteur est actif. Avec « Set up later », la mise en place peut être reportée, et la connexion continue sans elle. Cela fonctionne pendant 7 jours au plus, comptés à partir du premier report. La ligne sous le bouton indique les jours restants. Ensuite, la mise en place est obligatoire.

Juste après, dix codes de secours apparaissent. Chacun d'eux remplace une fois le code de l'application. Ils sont affichés exactement une fois. Tu les sauvegardes avec « Copy » ou « Download ». « Download » fonctionne toujours. « Copy » fonctionne aussi la plupart du temps.

Si quelqu'un perd son appareil et ses codes, l'administrateur aide. Dans la liste des utilisateurs, le bouton avec le bouclier barré réinitialise la connexion à deux facteurs de cette personne. Elle la remet en place à la prochaine connexion.

Les codes dépendent de l'horloge du serveur. Si elle est fausse, aucun code n'est accepté. Le bouton « Check now » sur la même carte compare l'heure du serveur à une source de temps publique.

Si quelqu'un se connecte par un service de connexion externe, le système ne demande pas de code. Le fournisseur a déjà vérifié le second facteur. La connexion par annuaire est différente : là, la règle ci-dessus s'applique toujours.

Chaque utilisateur peut activer la connexion à deux facteurs pour son propre compte. Cela vaut pour chaque rôle, même quand la carte « 2FA Settings » ne l'exige pas. Ouvre le menu utilisateur en bas à gauche de la barre latérale et choisis « Profile picture ». La même page contient la zone « Two-factor authentication ».

La zone indique si la connexion à deux facteurs est active. Tant qu'elle est désactivée, le bouton « Turn on » s'y trouve. Il demande d'abord ton mot de passe. Ensuite apparaissent un code QR pour l'application d'authentification et la même clé à saisir à la main. Après le premier code de l'application, le facteur est actif.

Juste après, dix codes de secours apparaissent. Sauvegarde-les avec « Copy » ou « Download ». « I have saved my codes » ferme la liste. Elle n'est affichée que cette seule fois.

Tant que la connexion à deux facteurs est active, la zone indique combien de codes de secours il reste. « New recovery codes » en crée dix nouveaux. Les anciens codes cessent alors de fonctionner. « Turn off » désactive de nouveau la connexion à deux facteurs. Les deux boutons demandent le code actuel de l'application. Un code de secours n'y est pas accepté.

Si la carte « 2FA Settings » exige la connexion à deux facteurs pour ton rôle, « Turn off » est absent. Une ligne dans la zone l'indique.

Un mauvais mot de passe ou un mauvais code compte comme une connexion échouée. La protection contre les tentatives de deviner un mot de passe s'applique donc ici aussi. L'activation et la désactivation sont inscrites dans le journal de sécurité. Si un administrateur désactive sa propre connexion à deux facteurs, le journal déclenche une alerte.

Les comptes qui se connectent uniquement par un service de connexion externe voient une phrase à la place des boutons. Leur fournisseur gère le second facteur. Les comptes issus d'un annuaire saisissent à la première étape leur mot de passe de l'annuaire.

La protection fonctionne sans aucun réglage. Il n'y a rien à activer. La remarque à ce sujet figure dans la carte « 2FA Settings ».

Elle fonctionne en deux niveaux. Après cinq tentatives ratées sur le même compte, l'adresse d'où elles venaient est mise en pause. La pause prend fin au plus tard 15 minutes après la première de ces tentatives. Depuis toute autre adresse, le compte reste utilisable tout de suite.

C'est la partie importante. Sinon, quiconque connaît un nom de connexion pourrait bloquer un collègue avec cinq mauvais mots de passe. Il n'aurait jamais besoin d'un mot de passe pour cela.

Le deuxième niveau est le compte lui-même. Il est verrouillé pendant 15 minutes après 20 tentatives ratées. Comme une seule adresse peut en fournir cinq au maximum, cela demande plusieurs adresses.

Une connexion réussie remet les deux compteurs à zéro. Après un redémarrage du serveur, la pause de l'adresse disparaît, le verrouillage du compte demeure. Les mêmes compteurs s'appliquent à la connexion par un annuaire. Un annuaire injoignable ne compte pas comme une tentative ratée. S'il n'existe pas encore de compte pour ce nom dans le système de tickets, seule la pause de l'adresse s'applique.

Dans la liste des utilisateurs, un compte verrouillé de cette façon porte la pastille « temporarily locked ». Il reste dans la liste. Après 15 minutes, la pastille disparaît d'elle-même.

Tu n'es pas obligé d'attendre. Dans la même ligne, il y a un bouton avec un cadenas ouvert. Il lève le verrouillage immédiatement et remet les deux compteurs à zéro.

Ce n'est pas la même chose que « Archive ». Ce bouton-là ferme un compte définitivement, et lui seul prend ou libère une place de personnel.

Le journal de sécurité enregistre deux sortes d’événements. Le domaine « Sign-in » contient les connexions échouées, les comptes verrouillés, les tentatives de connexion pendant un verrouillage, les codes à deux facteurs refusés et les changements de mot de passe. Cela vaut pour la connexion par mot de passe, via un annuaire et via SSO.

Le domaine « Administration » montre qui a modifié quoi. Cela couvre les comptes, les rôles, les autorisations, les paramètres de sécurité et les archives. Chaque export du journal y est aussi enregistré.

Les connexions réussies ne sont enregistrées que dans deux cas. Le premier cas est un administrateur. Le second cas est une connexion après des tentatives échouées sur le même compte. La connexion ordinaire d’un agent ou d’un client ne figure pas dans le journal. Le journal n’est pas une liste de présence.

Si quelqu’un se connecte avec un nom qui n’existe pas, l’entrée indique « unknown account ». Le système n’enregistre pas le nom saisi. C’est parfois un mot de passe tapé dans le mauvais champ.

Les événements de connexion enregistrent l’adresse IP et le navigateur. Les actions d’administration enregistrent qui les a effectuées, mais aucune adresse IP. Les mots de passe, les codes et le contenu des tickets ou des e-mails ne figurent jamais dans le journal.

La page montre d’abord les entrées les plus récentes, 50 par page. La carte « Filters » restreint la liste. « Area » choisit les connexions ou l’administration, « Event » un seul type d’événement. « Person » cherche dans le nom de celui qui a agi et de celui qui est concerné. « From » et « To » limitent les jours. « Failures only » masque tout ce qui a réussi.

Les filtres ne s’appliquent qu’après un clic sur « Apply ». « Reset » les retire.

« Export CSV » et « Export PDF » téléchargent exactement ce que montrent les filtres. Chaque fichier contient au maximum 10 000 entrées. Si plus d’entrées correspondent aux filtres, une remarque près des boutons d’export l’indique. Le PDF est dans ta langue et indique en haut les filtres et la période. La date et l’heure suivent le format réglé sous « Settings → General Settings ».

Le fichier CSV reste toujours en anglais, et les heures sont en UTC. Ainsi, un programme peut le lire quelle que soit la langue. Chaque export figure lui-même dans le journal, sous « Security log exported ».

Six événements déclenchent une alerte. Ce sont un compte verrouillé après des tentatives échouées, un rôle passé à « Admin », un compte créé directement avec le rôle « Admin » et une connexion à deux facteurs réinitialisée d’un administrateur. S’y ajoutent les tickets archivés retirés des données courantes et la connexion d’un administrateur après des tentatives échouées.

Après une alerte, toute personne qui a l’autorisation voit une bannière jaune en haut de chaque page. Elle indique le nombre d’alertes depuis sa dernière visite du journal. Le lien « Open security log » y mène. À l’ouverture du journal, la bannière disparaît. Avant la première visite, elle compte les alertes des sept derniers jours.

En plus, chaque compte actif qui a l’autorisation et une adresse e-mail reçoit un e-mail d’alerte. Le système regroupe les alertes toutes les 15 minutes et envoie un e-mail par personne, pas un par événement. L’e-mail indique l’événement, la personne concernée et l’heure. Il ne contient aucune adresse IP. L’e-mail d’alerte fait partie de Professional.

L’exécution nocturne supprime les anciennes entrées. Les délais se trouvent sous « Settings → Security », dans la carte « Data protection », bloc « Security log retention ». Par défaut, les événements de connexion sont conservés 90 jours ; de 7 à 365 jours sont autorisés. Par défaut, les actions d’administration sont conservées 12 mois ; de 1 à 120 mois sont autorisés.

Chaque délai a son propre interrupteur : « Delete old sign-in events » et « Delete old administrator actions ». Si un interrupteur est désactivé, ces entrées restent. La carte « Délais de conservation » explique l’exécution nocturne.

Lors d’une demande d’accès, la personne reçoit chaque entrée dans laquelle elle a agi ou a été concernée. L’adresse IP et le navigateur ne sont joints que pour les entrées qu’elle a déclenchées elle-même, par exemple sa propre connexion. Si la personne est anonymisée, le système supprime ses événements de connexion. Ses actions d’administration restent. Son nom y est remplacé par l’espace réservé.

Une remarque pour toi en tant qu’exploitant : les connexions réussies ne figurent dans le journal que pour les administrateurs et après des tentatives échouées. Le journal montre malgré tout qui a fait quoi et quand. Dans une entreprise dotée d’un comité social et économique, c’est donc un sujet de codécision.

Tout en haut se trouve l'interrupteur principal « Enable single sign-on ». Tant qu'il est désactivé, on reste au nom d'utilisateur et au mot de passe. Tout ce que tu configures en dessous est enregistré et ne prend effet qu'une fois que tu l'actives.

La carte « Active Directory / LDAP » relie un annuaire sur site. Tu saisis le serveur, la base de recherche, le filtre qui trouve une personne, et les champs de l'adresse e-mail et des noms.

Le compte utilisé pour les recherches est facultatif. Sans lui, le système interroge de façon anonyme. Le mot de passe d'une personne ne sert qu'à se lier à l'annuaire et n'est jamais enregistré.

Un annuaire n'apporte pas de second facteur propre. Si la page de sécurité exige la connexion à deux facteurs, on la demande aussi à ces personnes.

La carte « Identity providers » contient les services de connexion externes. Chacun reçoit sa propre tuile et son propre bouton sur la page de connexion. « Add provider » en crée un nouveau.

Sous « Provider type », tu choisis le type. « Generic OIDC Provider » convient à des services comme Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 ou Ping Identity. « SAML 2.0 Provider » convient aux mêmes maisons quand elles doivent être reliées par SAML.

À côté se trouvent six services régionaux : LINE, Kakao, Naver, WeChat, WeCom et DingTalk. Leurs adresses sont préremplies et apparaissent en gris dans le champ.

Le nom sous « Display name » apparaît ensuite sur le bouton. L'interrupteur à côté ne s'applique qu'à ce fournisseur.

Pour l'adresse de retour, procède dans cet ordre. Saisis d'abord seulement un nom et clique sur « Save provider ». Ce n'est qu'alors que le système connaît le numéro du fournisseur et affiche l'adresse complète sous « Redirect URI ». Elle est construite à partir de l'adresse publique de cette installation, celle enregistrée sous « Settings → Security ». C'est exactement l'adresse que le système utilise quand quelqu'un se connecte.

Tu copies cette adresse et tu l'enregistres chez le fournisseur. Elle doit y correspondre caractère par caractère. En retour, le fournisseur te donne un identifiant et un secret, et tu les saisis ici par « Edit ».

Le champ « Allowed e-mail domains » limite qui peut entrer par ce fournisseur. Laissé vide, tous les domaines sont autorisés.

S'il manque encore quelque chose à un fournisseur, sa tuile porte la pastille rouge « Incomplete ». Il n'apparaît alors pas sur la page de connexion. Le texte à côté indique les champs dont son type a besoin.

Les fournisseurs entièrement configurés n'apparaissent toujours pas tant que l'interrupteur principal est désactivé. La tuile le dit dans une ligne jaune.

Si ta licence repasse en Basic, la connexion par SSO et par l'annuaire continue de fonctionner. Sur cette page, tu peux alors seulement désactiver les fournisseurs et l'annuaire. Le journal des tentatives de connexion reste lisible.

L'interrupteur « Automatically create accounts on first sign-in » se trouve dans la même carte que l'interrupteur principal. Il est activé par défaut.

Quand quelqu'un se connecte pour la première fois par un fournisseur, le système cherche d'abord un compte qui appartient déjà à ce fournisseur. S'il n'en trouve aucun, un nouveau est créé.

Le nouveau compte reçoit le rôle « Customer » et aucune équipe. Un client n'a pas besoin d'appartenir à une équipe pour créer un ticket, il peut donc travailler tout de suite.

Les clients sont illimités dans les deux éditions, un compte créé ainsi n'utilise donc aucune place de personnel. Celui qui doit devenir agent reçoit le rôle ensuite dans la gestion des utilisateurs.

S'il existe déjà un compte avec la même adresse e-mail, les deux sont reliés. Cela n'arrive que si le fournisseur signale l'adresse comme vérifiée. Sinon, la connexion est refusée.

Si tu le désactives, seules les personnes qui ont déjà un compte entrent. Toutes les autres sont refusées.

La carte « Recent sign-in attempts », tout en bas, montre les 100 derniers événements de connexion via SSO et l’annuaire. Ils proviennent du journal de sécurité. Les tentatives échouées y figurent toujours. Une connexion réussie n’y figure que pour les administrateurs et après des tentatives échouées sur le même compte. Toutes les connexions n’apparaissent donc pas dans la liste.

Chaque ligne nomme l'heure, le fournisseur, le résultat et l'adresse d'origine. En cas d'échec, le motif figure à côté. La colonne « User » montre le nom du compte. S’il n’y a pas de compte, elle montre l’adresse communiquée par le fournisseur, sinon « unknown account ». Le système n’enregistre pas le nom saisi.

La connexion avec un nom d'utilisateur et un mot de passe n'apparaît pas dans ce tableau. Ce n'est pas du SSO. Tu la trouves dans le journal de sécurité.

Par défaut, les entrées sont supprimées au bout de 90 jours. La phrase sous le titre de la carte indique le délai réglé. La carte « Délais de conservation » explique ce réglage.

Après l'installation, ton équipe utilise le système dans n'importe quel navigateur web. Le programme d'installation demande comment le système doit être joignable. Dans le programme d'installation Windows, tu le choisis sur la page « Accessibilité ». Sous Linux, install.sh pose la même question et numérote les options de 1 à 5. Plus tard, tu le modifies avec « Modifier la manière dont SMITEY est joignable ». Tes données restent où elles sont.

L'option « Réseau local uniquement, via l'adresse IP (HTTP) - option la plus simple » est le réglage par défaut. Ton équipe ouvre le système à http:// suivi de l'adresse IP du serveur et du port, par exemple http://192.168.1.20:8088. Le port est 8088, sauf si tu en choisis un autre. Le port 80 fonctionne aussi. L'adresse n'a alors pas besoin de port. Cette option n'a besoin ni d'un nom ni d'un certificat.

L'option « Dans le réseau local sous un nom propre (HTTP, HTTPS possible plus tard) - vous disposez d'un DNS interne » fonctionne comme la première, mais sous un nom comme ticket.company.local. Tu crées le nom toi-même dans ton DNS interne. Il pointe vers l'adresse IP du serveur. Ton équipe joint alors le système par le nom et toujours aussi par l'adresse IP. Le programme d'installation affiche ensuite l'adresse avec ce nom.

Avec les deux options HTTP, les mots de passe et les tickets traversent ton réseau en clair. Les administrateurs voient alors un avertissement en haut de la page.

Les trois autres options utilisent HTTPS : « Via un domaine public avec HTTPS (automatique, avec Let's Encrypt) », « Dans le réseau local avec HTTPS et votre propre certificat » et « Dans le réseau local avec HTTPS, certificat créé par SMITEY ». Elles ont besoin des ports 80 et 443 sur le serveur. La carte suivante les décrit.

Pour un premier test, la première option suffit. Si ton réseau a un DNS interne, choisis la deuxième. Si le système doit être joignable depuis Internet, choisis le domaine public. Si ton entreprise a sa propre autorité de certification, choisis ton propre certificat dans le réseau local. Sinon, laisse SMITEY créer le certificat.

Sans HTTPS, les mots de passe et les tickets traversent ton réseau en clair. Une nouvelle installation commence en simple HTTP, pour fonctionner tout de suite dans n'importe quel navigateur web. Tant qu'un administrateur ouvre le système en simple HTTP, un avertissement apparaît en haut de la page : « This connection is not encrypted. » Si le système est ouvert sur le serveur lui-même sous « localhost », l'avertissement n'apparaît pas. Les agents et les clients ne le voient jamais.

« How to switch on HTTPS » mène à cette carte. « Hide for 30 days » masque l'avertissement pour toi. Le réglage appartient à ton compte et vaut donc aussi dans un autre navigateur. Après 30 jours, l'avertissement revient tant que la connexion n'est toujours pas chiffrée.

Le programme d'installation de SMITEY met en place HTTPS de trois façons. Dans le programme d'installation Windows, tu choisis sur la page « Accessibilité », et sous Linux, install.sh pose la même question. Sur un système qui tourne déjà, ouvre « Modifier la manière dont SMITEY est joignable » sur le bureau Windows ou dans le menu Démarrer. Sous Linux, la commande ci-dessous fait la même chose. Tes données restent où elles sont.

L'option « Dans le réseau local avec HTTPS et votre propre certificat » utilise ton propre certificat, par exemple celui de l'autorité de certification de ton entreprise. Le programme d'installation demande le nom du système et le fichier du certificat avec sa clé. Un fichier PFX avec son mot de passe fonctionne aussi. Avant de modifier quoi que ce soit, il vérifie le certificat. La clé doit correspondre, le certificat doit être valide, et le nom doit figurer dans le certificat.

L'option « Dans le réseau local avec HTTPS, certificat créé par SMITEY » n'a pas besoin de ton propre certificat. SMITEY en crée un lui-même et le renouvelle aussi lui-même. Le programme d'installation enregistre le certificat racine sous le nom SMITEY-root-ca.crt dans le dossier d'installation. Installe ce fichier sur chaque ordinateur comme certificat racine de confiance, par exemple par une stratégie de groupe. Jusque-là, les navigateurs affichent un avertissement.

L'option « Via un domaine public avec HTTPS (automatique, avec Let's Encrypt) » obtient son certificat de Let’s Encrypt. Elle a besoin d'un domaine public qui pointe vers le serveur. Pour cela, le serveur doit être joignable depuis Internet.

Pour les deux options sur le réseau local, le nom peut être un nom comme ticket.company.local, un seul mot comme helpdesk ou une adresse IPv4. Les trois chemins ont besoin des ports 80 et 443 sur le serveur. Si un autre programme les utilise, le programme d'installation s'arrête et ne modifie rien. Le système est ensuite joignable à https:// suivi du nom, sans port.

Ton propre certificat expire un jour. À partir de 30 jours avant, les administrateurs voient en haut de la page un avertissement avec la date. À partir de 7 jours avant, il est rouge. En Professional, tous les administrateurs qui ont une adresse e-mail reçoivent en plus un e-mail 30 et 7 jours avant. Pour le renouveler, ouvre de nouveau « Modifier la manière dont SMITEY est joignable », choisis l'option avec ton propre certificat et indique les nouveaux fichiers.

Le fichier HTTPS-GUIDE.txt fourni avec l'installation décrit chaque étape. Cela comprend la diffusion du certificat racine et les étapes à la main.