Authentification
L’authentification s’administre dans Paramètres → Serveur → Authentification. Seul le super administrateur peut modifier les méthodes de connexion du serveur.
Premier compte et inscriptions
Le premier démarrage crée le compte super-admin et le secret de signature du serveur. Ensuite, les utilisateurs rejoignent via la politique d’inscription autorisée, une invitation ou OIDC. Fermer les inscriptions ne supprime pas les comptes existants.
Utilisateurs serveur, sièges de licence, rôles et invitations se gèrent séparément. Un compte valide peut manquer de siège ou de rôle projet et ne pas accéder au travail protégé.
Connexion gérée par Stib
Les comptes Stib utilisent le flux normal de connexion et refresh token du serveur. Les mots de passe sont conservés sous forme de hash irréversible ; les tokens de session restent des secrets à protéger.
Utilisez HTTPS dès que le serveur est accessible au-delà de localhost. N’exposez pas une origine HTTP avec mot de passe à un réseau non fiable.
SSO OIDC
OIDC exige :
- une URL d’issuer avec document de découverte joignable ;
- un client ID et, selon le fournisseur, un client secret ;
- des scopes, normalement
openid email profile; - l’URL de callback exacte affichée par Stib, enregistrée chez le fournisseur ;
- une origine publique correcte du serveur.
Définissez STIB_SERVER_ORIGIN=https://stib.example.com avant la configuration si Stib est derrière un reverse proxy. Le callback est construit depuis cette origine ; ne le faites pas pointer vers un nom interne de conteneur.
Stib utilise le code d’autorisation avec PKCE et valide issuer, audience, expiration et state. Les secrets client sont chiffrés au repos. Utilisez Tester avant d’activer la méthode pour les utilisateurs.
Provisionnement et accès
OIDC peut créer ou rapprocher un utilisateur Stib depuis les claims validés, sous réserve de la politique serveur et des protections de conflit d’e-mail. Les groupes du fournisseur d’identité ne remplacent pas automatiquement les rôles d’organisation/projet sans fonction de mapping configurée.
Après connexion, l’accès dépend encore de :
- rôle serveur et siège de licence ;
- adhésion à l’organisation ou administration héritée ;
- rôle projet direct ou hérité ;
- restrictions d’accès de la colonne.
Bureau et mobile
Le client web utilise popup ou redirection. Le bureau redirige via le serveur puis revient dans l’application. Le mobile utilise le callback stib:// enregistré. Testez chaque type de client : proxy et deep links diffèrent.
Checklist de récupération
Avant tout changement, conservez un accès super-admin testé et une sauvegarde. En cas d’échec, vérifiez heure serveur, origine publique, certificats HTTPS, découverte, URI de callback, identifiants client, scopes, politique inscription/invitation et sièges disponibles.
Suite : Configuration du serveur et Audit et collaboration.