Ce guide aborde le périmètre Bastion 12. Les menus, options et compatibilités peuvent évoluer avec les correctifs et la version d’Access Manager : vérifiez la documentation correspondant à votre environnement avant une configuration.
Comprendre le fonctionnement
L’API expose des ressources de configuration, d’accès utilisateur et d’audit. La documentation disponible sur le Bastion à /api/doc correspond à sa version d’API. Une route et ses champs ne doivent pas être déduits d’un autre hotfix ou d’un simple exemple.
Une clé API ne doit pas être traitée comme un droit universel. Dans le modèle abordé ici, les droits de l’utilisateur associé encadrent les opérations. Pour les séries importantes, des sessions HTTP peuvent éviter une authentification complète par requête ; leur cycle de vie et leur fermeture restent à gérer.
Construire et vérifier la configuration
- Créer une identité d’automatisation avec des droits limités, protéger sa clé et vérifier le certificat serveur sans désactiver TLS.
- Lire /api/doc sur le Bastion concerné. Lister les devices avec GET et une limite explicite avant toute mutation.
- Parcourir les résultats paginés et utiliser les filtres supportés. Ne considérer la première page comme un inventaire complet que si cela est vérifié.
- Construire un ordre de provisioning respectant les dépendances : utilisateurs/groupes, devices/services, comptes, groupes cibles et autorisations.
- Pour POST, PUT ou DELETE, vérifier le schéma, le statut documenté et l’état après opération. Gérer les conflits, les reprises et les sessions HTTP sans journaliser les secrets.
# Renseigner ces variables dans un environnement de lab sécurisé.
# WALLIX_API_USER et WALLIX_API_KEY sont lus dans cet environnement.
WALLIX_URL="https://bastion.example.net"
curl --fail-with-body --silent --show-error \
--header "X-Auth-User: ${WALLIX_API_USER:?variable requise}" \
--header "X-Auth-Key: ${WALLIX_API_KEY:?variable requise}" \
"${WALLIX_URL}/api/devices?offset=0&limit=20"Les choix à retenir
Reliez chaque réglage à son effet sur l’accès et à la vérification associée.
| Élément | Rôle ou effet | Vérification |
|---|---|---|
| GET | Lit les ressources | Pagination, filtre et droits |
| POST / PUT | Crée ou modifie | Champs, dépendances et résultat |
| 401 / 403 | Authentification ou accès refusé | Identité, droits et contexte de licence |
| 409 | Conflit avec l’état actuel | Objet existant ou dépendance |
Diagnostiquer sans masquer le problème
Une réponse 204 n’a pas de corps à parser comme JSON. Un conflit 409 ne justifie pas une suppression aveugle : comparer l’objet existant avec l’état souhaité.
Les ressources utilisateur comme sessionrights, targetpasswords et approvals diffèrent de celles de configuration. L’audit utilise notamment sessions, metadata et traces ; une génération de vidéo n’est pas une simple lecture GET dans tous les cas.
Exercice de compréhension
Le script crée le device puis échoue ; au second lancement, la création retourne 409. Quelle logique ajoutez-vous ?
Voir le corrigé
Lire l’état existant, comparer ses paramètres et reprendre les dépendances manquantes sans dupliquer ni effacer l’objet arbitrairement. C’est une stratégie de convergence, pas une relance de toutes les créations.
Pour approfondir
- Documentation des produits WALLIX — choisir la version applicable
- Portail support WALLIX — guides et compatibilité par version
Continuer le parcours WCE 12
Retrouver les 14 guides du parcours WCE 12