SSO et un vrai journal d'audit, sans appel commercial entreprise
L’authentification unique est habituellement traitée comme une fonctionnalité de palier entreprise sur la plupart des plateformes, verrouillée derrière une conversation commerciale et un prix qui suppose quelques centaines de sièges. La plupart des équipes qui la veulent vraiment sont petites — une poignée d’ingénieurs qui préféreraient ne pas maintenir un mot de passe séparé pour le seul outil capable de redémarrer la production.
La configurer
Settings → Single sign-on, admins seulement. Les deux cas courants sont supportés directement, pas juste un avec l’autre ajouté après coup :
OpenID Connect — Google Workspace, Okta, Microsoft Entra, Authentik, Keycloak, ou n’importe quel autre fournisseur OIDC :
- Créez une application web OpenID Connect dans votre fournisseur d’identité, en utilisant l’URI de redirection que la page vous montre.
- Remplissez l’Issuer URL, le Client ID, le Client secret, et le domaine de messagerie auquel ça s’applique.
- Choisissez le rôle avec lequel les nouvelles personnes rejoignent — viewer, deployer, ou admin.
- Exigez optionnellement le SSO pour ce domaine, ce qui désactive entièrement la connexion par mot de passe pour celui-ci.
SAML 2.0 — choisissez-le sur la même page, collez l’URL de connexion et le certificat du fournisseur d’identité, et Railyard affiche l’URL ACS, l’entity ID et les métadonnées SP à remettre à Okta, Entra, OneLogin, JumpCloud ou ADFS. Les réponses sont vérifiées pour la signature, l’audience, l’heure et l’identifiant de requête — pas juste acceptées parce qu’elles se sont parsées.
Avant que quiconque ne puisse vraiment se connecter par l’une ou l’autre méthode, le domaine doit être vérifié avec un enregistrement TXT (_railyard-sso.<domain>) — le SSO ne se connecte jamais à un compte d’opérateur du site ni à un compte en dehors de l’équipe, et la double authentification reste exigée même pour les personnes passant par le SSO.
SCIM, une fois le SSO enregistré
Pointez l’application SCIM 2.0 de votre fournisseur d’identité vers https://app.railyard.run/scim/v2 avec un jeton porteur généré, et l’appartenance à l’équipe cesse d’être une étape manuelle : assigner quelqu’un dans le fournisseur d’identité l’ajoute à l’équipe, le désactiver le retire. Les owners ne sont jamais retirés de cette façon — ce rôle-là reste une action humaine délibérée.
Le journal d’audit, et ce qu’il couvre vraiment
Activity dans la barre latérale enregistre les déploiements, les changements de variables, les changements de membres, les approbations et les tâches sur les données — filtrable par membre, application, type et plage de dates, exportable en CSV. Les changements de variables montrent qui a changé quel nom et quand, jamais la valeur elle-même, pour que le journal soit utile sans devenir un second endroit d’où des secrets peuvent fuiter.
La partie qui mérite d’être connue : les actions qu’un opérateur Railyard prend sur votre propre équipe — changer des limites, suspendre, réactiver — atterrissent dans ce même journal, pas un séparé que seuls nous pouvons voir. Si quelque chose a été fait à votre équipe, vous pouvez le voir de la même façon que vous verriez ce que vos propres membres ont fait.
Le score qui vous dit si tout ça est vraiment activé
Settings → Security vérifie dix choses et note l’équipe de 0 à 100 : double authentification sur chaque membre, admins qui ne se sont pas connectés depuis 90 jours, serveurs avec des mises à jour de sécurité en attente, systèmes d’exploitation en fin de vie, ports ouverts supplémentaires, expiration de certificats, vérification de sauvegarde, stagings publics sans protection, et jetons API sans expiration. Chaque vérification échouée renvoie directement à sa correction, pour que « nous avons un score de sécurité » ne reste pas juste en bas d’une page de réglages sans être lu.
Référence complète : Équipes, SSO et accès.