Bastillion

Un outil moderne de console SSH et de gestion de clés SSH basé sur le web.

Bastillion vous offre un moyen propre et basé sur le navigateur de gérer l'accès SSH à tous vos systèmes — comme un hôte bastion avec un tableau de bord convivial. Il fait deux choses :

Terminal SSH basé sur le web — une fois qu'un hôte est enregistré, les utilisateurs autorisés peuvent ouvrir une ou plusieurs sessions de terminal en direct vers celui-ci directement depuis le navigateur, avec des commandes éventuellement diffusées sur chaque session ouverte à la fois (pensez aux volets synchronisés de tmux, mais pour une flotte d'hôtes distants au lieu de volets locaux).
Gestion des clés SSH — Bastillion détient sa propre paire de clés SSH et pousse/alterne les clés publiques sur les hôtes que vous enregistrez, de sorte que les utilisateurs individuels n'aient jamais besoin de détenir ou de gérer eux-mêmes des clés à longue durée de vie vers ces systèmes.

Connectez-vous avec une authentification à deux facteurs (Authy ou Google Authenticator)
Gérez et distribuez les clés publiques SSH, et désactivez/alternez-les de manière centralisée
Lancez des shells web multi-sessions sécurisés et partagez des commandes entre les sessions
Enregistrez chaque session et rejouez-la à la demande — des preuves prêtes pour l'audit pour tout cadre de conformité
Regroupez les systèmes en Profils et contrôlez exactement qui peut accéder à quoi
Enregistrez et réexécutez des Scripts composites sur toute une flotte à la fois
Superposez TLS/SSL sur SSH pour une protection supplémentaire

Plusieurs terminaux diffusant la même commande à trois hôtes à la fois

_{Trois sessions SSH réelles et indépendantes — une commande, tapée une fois, exécutée partout.}

Comment ça fonctionne

Bastillion se place entre vos utilisateurs et les systèmes auxquels ils doivent accéder, agissant comme un tiers de confiance plutôt qu'un simple coffre-fort de mots de passe. Voici l'ensemble du cycle de vie, de bout en bout.

1. Bastillion génère sa propre paire de clés SSH

Au premier démarrage, avant toute autre chose, Bastillion génère une paire de clés Ed25519 pour lui-même — c'est la seule clé qui est jamais poussée vers vos hôtes. Elle est affichée dans la sortie de la console et toujours visible sous Paramètres.

2. Enregistrez un système

Un administrateur ajoute un hôte sous Gérer → Systèmes (utilisateur, hôte, port et le chemin vers le fichier authorized_keys de cet hôte). Bastillion s'authentifie une fois avec un mot de passe ou une phrase de passe que vous fournissez, puis pousse sa propre clé publique dans le fichier authorized_keys de cet hôte. À partir de là, il se connecte en utilisant cette clé — aucun mot de passe stocké, jamais. Le statut passe à Succès dès que la clé est en place.

Gérer les systèmes — trois hôtes enregistrés, tous affichant un statut Succès

3. Regroupez les systèmes en Profils, assignez les Utilisateurs

Les systèmes sont regroupés en Profils nommés — pensez à « Production », « Préproduction », « Niveau Base de données ». Les utilisateurs sont ensuite liés aux profils sous Gérer → Utilisateurs, ce qui est la seule chose qui contrôle qui peut accéder à quoi. Révoquez une affectation de profil et cet accès disparaît immédiatement, sans rotation de clé nécessaire.

Affectation de trois systèmes à un profil Production

4. Ouvrez des terminaux — et diffusez vers tous à la fois

Les utilisateurs assignés ouvrent Shell sécurisé → Terminaux, sélectionnent un ou plusieurs systèmes, et obtiennent des terminaux en direct, redimensionnables et basés sur xterm dans le navigateur, côte à côte. Tapez une fois, et cela va vers chaque terminal marqué comme actif — la même frappe, la même commande, la même forme de sortie, sur autant d'hôtes que vous avez sélectionnés.

Une commande de vérification d'état diffusée vers trois terminaux simultanément, même forme de sortie sur les trois

5. Alternez ou révoquez les clés de manière centralisée

Parce que chaque hôte fait confiance à la même clé d'application (pas une clé par utilisateur), la désactiver une fois sous Gérer les clés SSH révoque l'accès partout immédiatement — pas besoin de toucher aux systèmes cibles à la main, pas besoin de chercher quel serveur possède quelle clé obsolète.

Gérer les clés SSH avec profil, empreinte, date de création et actions de suppression

6. Chaque session est enregistrée — audit et relecture

Tout ce qui est tapé et chaque octet renvoyé dans ces terminaux est enregistré automatiquement. Les gestionnaires ouvrent Sessions d'audit, filtrent par utilisateur ou système, et rejouent n'importe quelle session — côte à côte pour les sessions qui couvraient plusieurs hôtes, avec un filtre de texte pour sauter directement aux lignes qui comptent. La sortie défile dans la page au fur et à mesure qu'elle se charge, donc même une session qui a déversé des centaines de mégaoctets de journaux se rejoue sans effort.

Si vous devez montrer à un auditeur qui a exécuté quoi, où et quand — c'est cette preuve, capturée dès la sortie de la boîte. Pratiquement chaque cadre de conformité a une exigence de piste d'audit d'accès privilégié quelque part (PCI DSS, HIPAA, SOC 2, ISO 27001 — choisissez le vôtre), et cela coche cette case sans produit PAM commercial. Les sessions sont conservées pendant 90 jours par défaut (deleteAuditLogAfter), et l'enregistrement peut être désactivé avec ENABLE_INTERNAL_AUDIT=false — voir Audit.

Sessions d'audit listées avec filtres par utilisateur et système

🚀 Nouveautés

SSO SAML 2.0 — connectez-vous via un IdP d'entreprise (Entra ID, Okta, ADFS, et autres) — voir Configuration
Licences — gratuit jusqu'à 8 systèmes, des paliers payants disponibles sur loophole.company/pricing.html (voir Licences ci-dessous)
Audit et relecture de session, activés par défaut — chaque session de terminal est enregistrée et peut être rejouée sous Sessions d'audit, diffusée vers le navigateur afin que même les sessions énormes se chargent instantanément
Fonctionne comme un jar autonome (java -jar) avec HTTPS dès la sortie de la boîte — voir Téléchargement et exécution
Mis à niveau vers Java 21, Jetty 12 et Jakarta EE 10
Prise en charge complète des clés SSH Ed25519 (par défaut) et Ed448
Outil de migration v4 → v5 pour transférer les utilisateurs, systèmes, clés et journaux d'audit d'une instance existante — voir tools/migrate
Renforcé avec un filtre CSRF et des en-têtes de sécurité à l'échelle de l'application

Licences

Bastillion fonctionne sans licence jusqu'à 8 systèmes enregistrés — assez pour l'essayer pour de vrai avant d'acheter. Une licence relève ce plafond.

Achetez une licence sur loophole.company/pricing.html (Starter/Team/Business — tarifé selon le nombre de systèmes). Le paiement redirige et télécharge un fichier .lic automatiquement.
Ouvrez le fichier .lic et copiez son contenu (une ligne).
Définissez-le via la variable d'environnement LICENSE_KEY : ```bash export LICENSE_KEY=

ou collez-la dans licenseKey dans BastillionConfig.properties à la place — la variable d'environnement a priorité si les deux sont définies. 4. Redémarrez Bastillion. Settings affiche le licencié, la limite système et la date d'expiration, avec un avertissement commençant 90 jours avant l'expiration.

Les licences sont annuelles et ne se renouvellent pas automatiquement — aucune carte n'est conservée enregistrée. Rachetez depuis la même page de tarification lorsque vous recevez l'avertissement d'expiration.

Options d'installation

Gratuit : https://github.com/bastillion-io/Bastillion/releases

Prérequis

Java 21 (OpenJDK)```bash

apt-get install openjdk-21-jdk

### Authenticator (pour 2FA)

| Application | Android | iOS |
|--------------|----------|-----|
| **Authy** | [Google Play](https://play.google.com/store/apps/details?id=com.authy.authy) | [iTunes](https://itunes.apple.com/us/app/authy/id494168017) |
| **Google Authenticator** | [Google Play](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2) | [iTunes](https://itunes.apple.com/us/app/google-authenticator/id388497605) |

---

## Téléchargement et exécution

Téléchargez le dernier jar depuis [Releases](https://github.com/bastillion-io/Bastillion/releases) :```bash
java -jar bastillion-<version>.jar

Accès dans le navigateur : https://<server-ip>:8443 — voir TLS / HTTPS ci-dessous pour le certificat auto-signé que Bastillion génère lors de la première exécution.

Identifiants par défaut :``` username: admin password: changeme

Exécution au premier plan ; arrêt avec Ctrl+C. Pour un fonctionnement en arrière-plan ou en démon, utilisez ce que votre
plateforme utilise normalement pour un processus Java de longue durée — `nohup java -jar ... &`, une unité
systemd, un conteneur, etc.

---

## Compilation à partir des sources

Installez Maven 3+ :```bash
apt-get install maven

Build and run (packages a self-contained jar with an embedded Jetty server — see io.bastillion.Main — and runs it):```bash mvn package java -jar target/bastillion-5.0.0-SNAPSHOT.jar

Ou pour le développement local sans reconditionner à chaque modification :```bash
mvn compile exec:java

Listens sur https://localhost:8443 par défaut, comme pour la version téléchargée ci-dessus — voir TLS / HTTPS ci-dessous pour savoir comment ce certificat est configuré et comment utiliser le vôtre à la place.

TLS / HTTPS

Bastillion génère son propre certificat auto-signé au premier démarrage et sert en HTTPS — rien à configurer. Les navigateurs afficheront un avertissement une fois (il est auto-signé, non délivré par une autorité de certification) ; cliquez dessus pour passer, comme vous le feriez pour tout autre appareil auto-hébergé. Le certificat et son mot de passe persistent entre les redémarrages (keystore/bastillion.p12 sous CONFIG_DIR, le mot de passe étant stocké de la même manière chiffrée que le mot de passe de la base de données).

Utilisez votre propre certificat signé par une autorité de certification à la place du certificat auto-signé par défaut — par exemple un certificat gratuit de Let's Encrypt :

Émettez le certificat avec certbot (nécessite un vrai nom DNS pointant vers cet hôte, et le port 80 accessible pour le défi HTTP-01) : ```bash sudo certbot certonly --standalone -d bastillion.example.com

This writes fullchain.pem and privkey.pem to /etc/letsencrypt/live/bastillion.example.com/.

Convertissez la paire certificat/clé au format PKCS12, le format de keystore attendu par Bastillion : ```bash openssl pkcs12 -export
-in /etc/letsencrypt/live/bastillion.example.com/fullchain.pem
-inkey /etc/letsencrypt/live/bastillion.example.com/privkey.pem
-out bastillion.p12 -name bastillion -passout pass:changeit
Pointez Bastillion dessus et redémarrez : ```bash export KEYSTORE_PATH=/path/to/bastillion.p12 export KEYSTORE_PASSWORD=changeit

Les navigateurs feront désormais confiance à la connexion sans avertissement. Les certificats Let's Encrypt expirent tous les 90 jours — certbot renew suivi de la ré-exécution des étapes 2–3 (et d'un redémarrage) le maintient à jour ; certbot renew --deploy-hook peut automatiser cela.

Derrière un reverse proxy ou un équilibreur de charge qui termine déjà le TLS (nginx, Cloud Run, etc.) — désactivez le HTTPS propre à Bastillion et laissez-le servir du HTTP simple à la place :```bash export TLS_ENABLED=false

Par défaut, ce mode utilise le port 8080 ; définissez `PORT` pour le modifier.

---

## Configuration

Chaque paramètre ci-dessous peut être défini comme **variable d’environnement** — prenez le nom de la propriété, insérez un underscore avant chaque lettre majuscule, puis mettez-le en majuscules : `licenseKey` → `LICENSE_KEY`, `dbUser` → `DB_USER`, `sshKeyType` → `SSH_KEY_TYPE`. C’est la méthode recommandée pour configurer Bastillion, en particulier dans les conteneurs — aucun fichier à monter ou à intégrer.

`BastillionConfig.properties` fonctionne toujours comme solution de repli (les variables d’environnement priment si les deux sont définies), et c’est là que toute valeur que Bastillion génère pour vous au premier démarrage — comme un mot de passe de base de données aléatoire — est conservée. Consultez `src/main/resources/BastillionConfig.properties` pour la liste complète des paramètres et de leurs valeurs par défaut.

**Regrouper tout sous un seul répertoire** (par exemple, un unique volume Docker) : `CONFIG_DIR` est le paramètre à utiliser. Tout ce que Bastillion conserve — `BastillionConfig.properties`, le magasin de clés TLS auto-signé (`keystore/bastillion.p12`), la base de données H2 et la paire de clés hôte SSH (toutes deux sous `keydb/`), ainsi que `bastillion.jceks` — se trouve par défaut sous ce répertoire ; pointer `CONFIG_DIR` vers un seul emplacement déplace donc l’ensemble :```bash
export CONFIG_DIR=/data/bastillion/

KEYSTORE_PATH et DB_CONNECTION_URL existent toujours pour pointer uniquement l’un d’eux vers un emplacement différent (un vrai certificat, une base de données distante) — voir TLS / HTTPS et la section « Database Settings » ci-dessous — mais aucun n’est nécessaire juste pour tout regrouper dans CONFIG_DIR.

CONFIG_DIR lui-même est défini par défaut sur ./config par rapport au répertoire de travail. Vous mettez à niveau une instance existante qui ne l’a jamais défini ? Les anciennes versions stockaient l’état directement dans le répertoire de travail au lieu de ./config — Bastillion le détecte au premier démarrage avec cette version et le déplace automatiquement dans ./config (ou dans CONFIG_DIR, si vous en avez maintenant défini un).

Gestion des clés SSH

```bash # Disable key management (append instead of overwrite) export KEY_MANAGEMENT_ENABLED=false

authorized_keys refresh interval in minutes (no refresh for <=0)

export AUTH_KEYS_REFRESH_INTERVAL=120

Force user key generation and strong passphrases

export FORCE_USER_KEY_GENERATION=false

</details>

<details>
<summary><strong>Paire de clés SSH personnalisée</strong></summary>

Par défaut, Bastillion génère sa propre paire de clés Ed25519 au premier démarrage. Pour utiliser la vôtre
à la place, le moyen le plus simple passe par l'interface : **Paramètres → Remplacer la clé SSH de l'application**
(comptes administrateurs uniquement) — collez une clé privée, une clé publique et une phrase de passe si elle en a une,
et cela prend effet immédiatement, sans redémarrage nécessaire.

⚠️ Cela remplace l'unique clé que chaque système enregistré approuve. C'est prévu comme une étape ponctuelle
lors de la première configuration de Bastillion, **avant** d'avoir enregistré des systèmes — si vous avez déjà
des systèmes enregistrés, Bastillion perd l'accès SSH à tous dès que vous remplacez
la clé, à moins que cette clé exacte ne soit déjà présente dans `authorized_keys` sur chacun d'entre eux
au préalable. La page Paramètres exige une case de confirmation supplémentaire dès que des systèmes sont
enregistrés, précisément pour cette raison.

**Des systèmes déjà enregistrés et besoin de faire pivoter la clé quand même ?** Pré-approvisionnez la nouvelle clé
via Bastillion lui-même plutôt que de modifier `authorized_keys` manuellement partout :

1. Définissez `FORCE_USER_KEY_GENERATION=false` afin que **Gérer les clés SSH → Ajouter une clé SSH** vous permette de coller
   une clé publique existante au lieu de seulement en générer une nouvelle.
2. Ajoutez-y la nouvelle clé sur un profil couvrant tous vos systèmes, et confirmez (sous
   Gérer les clés SSH, ou l'état de chaque système) qu'elle est bien déployée partout — gardez
   `AUTH_KEYS_REFRESH_INTERVAL` à l'esprit, car c'est ce qui la propage.
3. Ce n'est qu'une fois que vous êtes sûr qu'elle est sur chaque système, remplacez la clé de l'application dans Paramètres.
4. Redéfinissez `FORCE_USER_KEY_GENERATION` à sa valeur précédente, puis une fois que vous avez confirmé
   que la nouvelle clé de l'application s'est propagée à chaque système (encore une fois, pensez à
   `AUTH_KEYS_REFRESH_INTERVAL`), supprimez la clé ajoutée à l'étape 2 depuis Gérer les clés SSH —
   elle n'y était que provisoirement pour pré-remplir `authorized_keys` et n'est plus nécessaire à l'avenir.

Pour les configurations scriptées/sans interface, la même opération peut être effectuée via des variables d'environnement et un
redémarrage à la place :```bash
# Regenerate and import SSH keys
export RESET_APPLICATION_SSH_KEY=true

# Private key
export PRIVATE_KEY=/Users/you/.ssh/id_rsa

# Public key
export PUBLIC_KEY=/Users/you/.ssh/id_rsa.pub

# Passphrase (leave blank if none)
export DEFAULT_SSH_PASSPHRASE=myPa$$w0rd

Une fois enregistrées, vous pouvez les supprimer — la paire de clés est déjà stockée dans la base de données.

SSH_KEY_TYPE (rsa, ecdsa, ed25519 ou ed448) n'a d'importance que lorsque Bastillion génère une nouvelle clé, pas lors de l'importation d'une clé existante — le type d'une clé importée est lu directement depuis la clé elle-même :```bash

SSH key type ('rsa', 'ecdsa', 'ed25519', or 'ed448')

Supported options:

rsa - Classic, widely compatible (configurable length, default 4096)

ecdsa - Faster, smaller keys (P-256/384/521 curves)

ed25519 - Default and recommended (≈ RSA-4096, secure and fast)

ed448 - Extra-strong (≈ RSA-8192, slower and less supported)

export SSH_KEY_TYPE=ed25519

</details>

<details>
<summary><strong>Paramètres de la base de données</strong></summary>

Exemple avec H2 intégré :```bash
export DB_USER=bastillion
export DB_PASSWORD=p@$$w0rd!!
export DB_DRIVER=org.h2.Driver
export DB_CONNECTION_URL=jdbc:h2:file:keydb/bastillion;CIPHER=AES;

Remote H2 example :```bash export DB_CONNECTION_URL=jdbc:h2:tcp://:/~/bastillion;CIPHER=AES;

</details>

<details>
<summary><strong>Authentification externe (LDAP / JAAS)</strong></summary>

Authentifiez-vous auprès d'un serveur LDAP/Active Directory existant au lieu des mots de passe
locaux (ou en complément de ceux-ci). Activez-la :```bash
export JAAS_MODULE=ldap-ol

Configurez jaas.conf :``` ldap-ol { com.sun.security.auth.module.LdapLoginModule SUFFICIENT userProvider="ldap://hostname:389/ou=example,dc=bastillion,dc=com" userFilter="(&(uid={USERNAME})(objectClass=inetOrgPerson))" authzIdentity="{cn}" useSSL=false debug=false; };

Pour mapper les rôles LDAP aux profils Bastillion :```
ldap-ol-with-roles {
    org.eclipse.jetty.security.jaas.spi.LdapLoginModule required
    debug="false"
    useLdaps="false"
    contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
    hostname="<SERVER>"
    port="389"
    bindDn="<BIND-DN>"
    bindPassword="<BIND-DN PASSWORD>"
    authenticationMethod="simple"
    forceBindingLogin="true"
    userBaseDn="ou=users,dc=bastillion,dc=com"
    userRdnAttribute="uid"
    userIdAttribute="uid"
    userPasswordAttribute="userPassword"
    userObjectClass="inetOrgPerson"
    roleBaseDn="ou=groups,dc=bastillion,dc=com"
    roleNameAttribute="cn"
    roleMemberAttribute="member"
    roleObjectClass="groupOfNames";
};

Les administrateurs sont ajoutés lors de la première connexion et peuvent se voir attribuer des profils système.

Comment fonctionne réellement le mappage des rôles : chaque groupe LDAP auquel un utilisateur appartient (selon roleBaseDn/ roleMemberAttribute ci-dessus) devient un « nom de rôle » - la valeur de l'attribut roleNameAttribute de ce groupe (cn dans l'exemple ci-dessus). À chaque connexion, Bastillion compare chacun de ces noms de rôles, par correspondance textuelle exacte, avec les noms des Profils que vous avez créés sous Gérer → Profils. Une correspondance attribue l'utilisateur à ce profil ; aucune correspondance, aucun accès à ce profil. Ainsi, si un utilisateur est membre du groupe LDAP cn=admins,ou=groups,..., vous avez besoin d'un profil Bastillion littéralement nommé admins (sans tenir compte de la casse - la comparaison est insensible à la casse, mais pas l'orthographe) pour que cette appartenance signifie quoi que ce soit dans Bastillion. Il n'existe aucune étape de mappage séparée ni interface pour cela - les noms doivent simplement correspondre.

Un utilisateur dont les rôles ne correspondent à aucun profil Bastillion est rejeté à la connexion (les comptes Manager sont la seule exception ; ils ne sont pas limités aux profils). Définissez defaultProfileForLdap sur un nom de profil pour attribuer automatiquement chaque utilisateur LDAP à celui-ci, garantissant que tout le monde peut se connecter, indépendamment de la correspondance des rôles - utile comme filet de sécurité pendant que vous alignez encore les noms de profils avec les noms de groupes de votre annuaire :```bash export DEFAULT_PROFILE_FOR_LDAP=everyone

</details>

<details>
<summary><strong>Authentification unique (SAML 2.0)</strong></summary>

Authentifiez-vous auprès d’un fournisseur d’identité d’entreprise — Microsoft Entra ID, Okta, ADFS ou tout
fournisseur d’identité SAML 2.0 — au lieu de (ou en plus des) mots de passe locaux ou de LDAP. Un bouton **Se connecter avec SSO**
apparaît sur la page de connexion une fois configuré. Activez-le :```bash
export SAML_BASE_URL=https://bastillion.example.com
export SAML_IDP_METADATA_URL=https://login.microsoftonline.com/<tenant-id>/federationmetadata/2007-06/federationmetadata.xml?appid=<app-id>

Dans Entra ID (ou votre IdP de votre choix), enregistrez Bastillion en tant qu'application d'entreprise / fournisseur de services avec :

Identifiant (ID d'entité) : https://bastillion.example.com (ou SAML_SP_ENTITY_ID s'il est défini - voir ci-dessous)
URL de réponse (URL du service consommateur d'assertions) : https://bastillion.example.com/saml/acs

Pas d'URL de métadonnées IdP sous la main ? Configurez plutôt l'IdP manuellement - les trois sont requis ensemble dans ce cas :```bash export SAML_IDP_ENTITY_ID=https://sts.windows.net// export SAML_IDP_SSO_URL=https://login.microsoftonline.com//saml2 export SAML_IDP_CERT=

Uniquement nécessaire si l'ID d'entité enregistré côté IdP ne peut pas correspondre exactement à `SAML_BASE_URL` :```bash
export SAML_SP_ENTITY_ID=https://bastillion.example.com

Pour mapper les revendications de groupe/rôle Entra vers les profils Bastillion (voir « Comment fonctionne réellement le mappage des rôles » ci-dessous avant de modifier SAML_ROLE_ATTRIBUTE par rapport à sa valeur par défaut) :```bash export SAML_ROLE_ATTRIBUTE=http://schemas.microsoft.com/ws/2008/06/identity/claims/groups export DEFAULT_PROFILE_FOR_SAML=everyone

Les administrateurs sont ajoutés lors de la première connexion SSO et peuvent se voir attribuer des profils système.

**Nom d'utilisateur affiché dans Bastillion :** le NameID SAML devient le nom d'utilisateur. Entra envoie
`user.userprincipalname` par défaut, ce qui convient aux membres réguliers du locataire mais produit un
UPN invité peu élégant comme `alice_gmail.com#EXT#@yourtenant.onmicrosoft.com` pour les invités B2B (toute personne
connectée avec un e-mail personnel ou externe ajouté comme invité). Pour un nom d'utilisateur plus propre, allez dans
*Single sign-on* de l'Application d'entreprise → SAML → *Attributes & Claims*, modifiez **Unique
User Identifier (Name ID)**, et changez son *Source attribute* de `user.userprincipalname`
à `user.mail`.

**Comment fonctionne réellement le mappage des rôles - même mécanisme que pour LDAP ci-dessus :** `SAML_ROLE_ATTRIBUTE`
désigne *quel* attribut d'assertion transporte les groupes/rôles de l'utilisateur ; quelles que soient les *valeurs* que cet
attribut contient lors d'une connexion donnée, elles sont comparées, **par correspondance textuelle exacte**, aux noms des
Profils que vous avez créés sous **Manage → Profiles**. Une valeur qui correspond à un nom de profil
assigne l'utilisateur à ce profil ; rien d'autre concernant la revendication n'a d'importance. Ainsi, un profil Bastillion doit être
nommé exactement comme la chaîne que l'assertion envoie - il n'y a pas d'étape de mappage séparée
ni d'interface, les noms doivent simplement correspondre.

C'est la partie qui pose le plus souvent problème avec Entra ID en particulier : par défaut,
la revendication de groupe d'Entra peut émettre chaque groupe sous forme de son **Object ID** (un GUID) plutôt que son nom
d'affichage, à moins que la configuration de jeton de l'Application d'entreprise ne soit explicitement définie pour émettre les **noms**
de groupe. Si vos profils Bastillion sont nommés comme `admins`/`everyone` mais qu'Entra
envoie des GUID, rien ne correspondra jamais. Vérifiez la valeur réelle de la revendication dans une assertion réelle (ou
la configuration de jeton d'Entra pour l'application) avant de supposer que le mappage est cassé - c'est généralement
cela, pas un problème côté Bastillion. Trois façons de corriger, par ordre de ce que nous recommandons :

1. **Utilisez les App Roles d'Entra au lieu des revendications de groupe (le plus propre).** Sous l'enregistrement de l'application →
   App roles, définissez des rôles avec exactement les valeurs souhaitées (`admins`, `everyone`, ...), puis
   assignez des utilisateurs/groupes à ces rôles sous *Users and groups* de l'Application d'entreprise.
   Configurez le jeton SAML pour émettre la revendication `roles`, et pointez `SAML_ROLE_ATTRIBUTE` vers l'URI de cette
   revendication au lieu de la revendication de groupes. Vous choisissez la chaîne exacte qu'Entra envoie - aucun problème
   de GUID du tout, et c'est un modèle d'autorisation plus propre que de réutiliser les groupes AD de toute façon.
2. **Changez l'attribut source de la revendication de groupes.** Application d'entreprise → Single sign-on →
   SAML → *Attributes & Claims* → modifiez la revendication Groups → il y a une liste déroulante *Source attribute*,
   normalement définie par défaut sur Group ID. Selon votre locataire et selon que les groupes
   sont uniquement cloud ou synchronisés depuis l'AD sur site, vous pourrez peut-être la passer à `sAMAccountName`
   ou à une option de nom d'affichage - les choix exacts varient selon le locataire et la version du portail Entra, alors vérifiez
   ce qui est réellement proposé plutôt que de supposer une étiquette spécifique.
3. **Ou ne luttez pas - nommez le profil Bastillion d'après ce qu'Entra envoie réellement.** Si
   Entra insiste pour envoyer le GUID, créez un profil Bastillion littéralement nommé avec ce GUID.
   Moins élégant, mais ne nécessite aucune reconfiguration côté Entra.

Un utilisateur dont les revendications ne correspondent à aucun profil Bastillion est rejeté à la connexion (les comptes **Manager** sont
la seule exception ; ils ne sont pas limités aux profils) - exactement comme avec LDAP, donc
`DEFAULT_PROFILE_FOR_SAML` ci-dessus vaut la peine d'être défini pour la même raison que
`DEFAULT_PROFILE_FOR_LDAP` : un filet de sécurité pendant que vous alignez encore les noms de profils avec
les valeurs de revendication de votre IdP.

La vérification du mot de passe à usage unique propre à Bastillion est ignorée pour les connexions SSO - l'IdP est censé
appliquer sa propre politique MFA/Conditional Access à la place. L'inscription initiale à l'OTP est toujours
proposée afin que les utilisateurs SAML disposent d'une identifiant de secours local si le SSO est un jour désactivé.

**Requêtes signées et assertions chiffrées :** Bastillion génère automatiquement son propre certificat de signature SAML
(auto-signé, de la même manière qu'il génère son certificat TLS) la
première fois qu'il est nécessaire, et signe chaque AuthnRequest sortant avec celui-ci par la suite - aucune
configuration requise, et inoffensif même si votre IdP ne le vérifie pas. Récupérez
`https://bastillion.example.com/saml/metadata` pour obtenir ce certificat sous forme de métadonnées SP
standard et remettez-le à l'administrateur de votre IdP s'il doit vérifier les
requêtes signées de Bastillion, ou chiffrer les assertions pour Bastillion - la plupart des IdP peuvent importer une URL de métadonnées SP
directement au lieu de coller un certificat brut. Si vous préférez utiliser une vraie paire de clés (par ex. émise par une AC)
au lieu de celle générée automatiquement, pointez `SAML_SP_KEYSTORE_PATH`/
`SAML_SP_KEYSTORE_PASSWORD` vers un keystore PKCS12 la contenant. Pour *exiger* des assertions
chiffrées (désactivé par défaut - n'activez cela qu'une fois que votre IdP est réellement configuré pour
chiffrer avec le certificat de Bastillion, sinon chaque connexion commencera à échouer) :```bash
export SAML_WANT_ENCRYPTED_ASSERTIONS=true

Non pris en charge actuellement : déconnexion unique (SLO) - la déconnexion reste locale uniquement et n'informe pas l'IdP ni aucune autre application à laquelle vous étiez connecté via la même session SSO. Le SSO SAML peut être activé en parallèle de LDAP ; les deux sont évalués indépendamment et chacun peut provisionner de nouveaux utilisateurs lors de la première connexion.

Audit

L'audit de session est activé par défaut : la sortie du terminal est stockée dans la base de données de Bastillion et peut être consultée sous Audit Sessions (comptes gestionnaires uniquement). La sortie est diffusée en continu vers le navigateur, de sorte que même les sessions avec de très grandes quantités de sortie de terminal peuvent être rejouées. L'historique d'audit est conservé pendant deleteAuditLogAfter jours (90 par défaut). Désactivez-le avec :```bash export ENABLE_INTERNAL_AUDIT=false

Il existe également un journal d'audit basé sur des fichiers, désactivé par défaut. Activez-le dans **log4j2.xml** en
décommentant :
- `io.bastillion.manage.util.SystemAudit`
- `audit-appender`

> https://github.com/bastillion-io/Bastillion/blob/main/src/main/resources/log4j2.xml#L19-L22
</details>

<details>
<summary><strong>Migration depuis v4</strong></summary>

Vous mettez à niveau une ancienne installation Bastillion v4 et souhaitez conserver vos utilisateurs, systèmes, profils,
scripts et (surtout) la paire de clés SSH existante de l'application au lieu de repartir
de zéro ? `tools/migrate/` contient un outil de migration autonome conçu précisément pour cela — il exporte chaque
table de l'ancienne base de données H2 (en déchiffrant les colonnes chiffrées au niveau de l'application avec le
keystore de l'ANCIENNE instance) vers un fichier JSON, puis l'importe dans une nouvelle instance v5 (en rechiffrant
avec le keystore de la NOUVELLE instance). Les utilisateurs existants peuvent se connecter avec leurs mots de passe actuels
immédiatement après — sans réinitialisation forcée.```bash
cd tools/migrate

# 1. Export the old database
./migrate.sh export /opt/Bastillion-jetty/jetty/bastillion/WEB-INF/classes/ ~/bastillion-export.json

# 2. Start the new v5 instance once against the config dir you're migrating into, then
#    stop it (Ctrl+C) once it's finished booting - this creates the schema, jceks, and
#    default admin user.
cd ../..
java -DCONFIG_DIR=/data/bastillion/ -jar target/bastillion-5.0.0-SNAPSHOT.jar

# 3. Import into the new database (full replace of all 12 tables)
cd tools/migrate
./migrate.sh import /data/bastillion/ ~/bastillion-export.json --yes-replace-all-data

# 4. Delete the export file - it contains decrypted secrets
rm ~/bastillion-export.json

Voir tools/migrate/README.md pour tous les détails — trouver le répertoire de configuration de votre ancienne installation, ce qui est exactement migré, et les notes de sécurité sur le fichier d'export en texte brut.

Plus de captures d'écran

Le flux de travail principal est présenté dans Comment ça marche. Développez un groupe ci-dessous pour explorer le reste de l'interface.

Authentification — connexion et inscription à la double authentification

Connexion

Connectez-vous avec un nom d'utilisateur et un mot de passe, plus un code d'accès OTP facultatif.

Écran de connexion Bastillion

Configuration de la double authentification

Scannez le code QR avec Authy, Google Authenticator, ou une autre application compatible.

Écran de configuration de la double authentification Bastillion

Gestion des accès — navigation, profils et utilisateurs

Les outils disponibles sont limités aux permissions de l'utilisateur connecté.

Gérer les profils

Regroupez les systèmes dans des profils nommés qui contrôlent l'accès.

Écran de gestion des profils Bastillion

Gérer les utilisateurs

Créez des comptes, choisissez les rôles utilisateur et accordez l'accès aux systèmes via les profils.

Écran de gestion des utilisateurs Bastillion

Terminaux & Automatisation — lancez des sessions et exécutez des scripts enregistrés

Terminaux

Sélectionnez un ou plusieurs systèmes, éventuellement filtrés par profil, et ouvrez-les simultanément.

Écran de sélection des terminaux Bastillion

Scripts composites

Enregistrez un script une seule fois et exécutez-le sur chaque terminal sélectionné.

Écran de gestion des scripts composites Bastillion

Paramètres — apparence du compte et authentification de l'application

Paramètres utilisateur

Changez votre mot de passe, choisissez l'apparence de l'interface et du terminal, et gérez la clé publique que Bastillion utilise pour s'authentifier auprès des systèmes enregistrés.

Écran des paramètres utilisateur Bastillion

Licence

Bastillion est disponible sous la Prosperity Public License.

Liste complète des dépendances tierces et de leurs licences dans 3rdPartyLicenses.md.

Loophole, LLC — Sean Kavanagh

[email protected]

Lire plus

Bastillion v5.2.0

Catégories