TP 5. Les tokens et leur cycle de vie
Énoncé de travail pratique
Les commandes ne figurent pas dans les énoncés : elles se construisent à partir du chapitre déclencheur indiqué ci-dessous. Le laboratoire et le livret de corrections ne sont pas encore publiés. Voir les limites du livrable
Chapitre déclencheur : 12. Durée : 1 h 30.
Objectifs¶
Manipuler les durées, la hiérarchie et la révocation des tokens, distinguer les tokens de service des tokens de traitement par lot, employer les accessors pour révoquer sans détenir le secret, et éprouver le response wrapping, sa consommation unique et sa propriété d'alarme.
Prérequis¶
TP 4 terminé. Chapitre 12 lu.
Étapes¶
1. Durées. Créez un token portant billing-kv avec une durée courte. Consultez ses caractéristiques, renouvelez-le, puis laissez-le expirer et constatez le refus.
2. Plafond. Créez un token dont la durée maximale est inférieure à ce que le renouvellement voudrait accorder, et constatez l'écrêtage lors du renouvellement.
3. Cascade. Depuis un token parent, créez un token enfant. Révoquez le parent et constatez ce qu'il advient de l'enfant. Recommencez avec un token créé orphelin.
4. Accessors. Listez les accessors des tokens en cours. Depuis un compte administrateur, révoquez un token par son accessor, sans jamais manipuler sa valeur. Retrouvez ensuite dans le journal d'audit les opérations effectuées par ce token, en vous appuyant sur son accessor.
5. Traitement par lot. Créez un token de type lot et comparez-le à un token de service sur quatre points : présence dans la liste des accessors, possibilité de renouvellement, révocabilité, disponibilité d'un espace privé. Consignez le tableau.
6. Response wrapping. Emballez la création d'un secret sous enveloppe avec une durée de deux minutes. Consommez-la et constatez que la seconde tentative échoue. Recommencez, mais faites consommer l'enveloppe par un second terminal jouant l'intercepteur, puis tentez de la consommer légitimement : constatez l'échec et expliquez ce qu'il démontre.
7. Bornes d'origine. Créez un token restreint à une adresse réseau qui n'est pas la vôtre et constatez le refus. Expliquez pourquoi cette restriction est une profondeur et non une preuve.
Résultats attendus¶
Une expiration constatée, un écrêtage constaté, une cascade démontrée et son contournement par l'orphelinat. Une révocation par accessor réussie sans manipuler le token. Un tableau comparatif service et lot renseigné par l'expérience. Une enveloppe consommée deux fois avec échec de la seconde, et une interception détectée. Un refus lié à l'origine.
Erreurs possibles et diagnostic¶
Le renouvellement semble sans effet : la durée maximale plafonne, ce qui est l'objet de l'étape 2. Le token enfant survit à son parent : il a été créé orphelin, volontairement ou par une option héritée. La révocation par accessor échoue avec un refus de droits : les chemins d'accessor relèvent de l'administration, pas du porteur. La consommation de l'enveloppe échoue immédiatement : la durée de deux minutes est écoulée, ou vous consommez avec le mauvais type de commande.
Questions¶
- Vous trouvez un token dans un fichier de journal applicatif. Sans le consommer, comment déterminez-vous ce qu'il a fait et comment le neutralisez-vous ?
- Dans quel cas choisiriez-vous un token de traitement par lot, et à quoi renoncez-vous en le faisant ?
- Un collègue affirme que le response wrapping protège le secret pendant son transport. Nuancez sa formulation en une phrase précise.