Maintenir chaque utilisateur dans sa frontière documentaire

Introduction

L’assistant est déjà limité à documents.read, mais un outil autorisé peut toujours demander un document interdit. Vous maintenez une nouvelle instance dont la politique d’objet permet toutes les lectures.

Ajoutez une petite règle Python en deux temps : protégez d’abord la propriété, puis préservez le partage explicite. Le serveur obtient l’identité des sessions authentifiées, pas des arguments proposés. Les documents sont synthétiques et les propositions explicitement rejouées ; lectures et autorisation sont réelles. Les compétences terminal du laboratoire précédent suffisent ; la syntaxe Python est expliquée ici.

Lier les lectures au propriétaire authentifié

Dans cette étape, empêchez un outil autorisé de franchir la frontière du document privé d’un autre utilisateur.

Sélectionnez l’onglet Test Client dans l’interface du laboratoire pour commencer cette étape.

Utilisez cette table. owner et shared_with sont des champs documentaires enregistrés, pas des valeurs proposées.

Dans Test Client, --as bob choisit l’identifiant authentifié préparé de Bob. Sans option, Alice est choisie. Confirmez d’abord une lecture normale du propriétaire :

Passez à l’onglet Test Client avant d’exécuter la commande suivante.

assistant call documents.read alice-notes

Attendez HTTP 200 et le contenu d’Alice. Reproduisez maintenant l’absence de contrôle d’objet :

assistant call documents.read bob-notes

La réponse incorrecte est HTTP 200 et Synthetic Bob private budget. Aucune vraie information privée n’est utilisée. La liste des outils seule n’a pas protégé l’objet.

Passez à l’onglet Policy Editor et inspectez la petite politique :

Passez à l’onglet Policy Editor avant d’exécuter la commande suivante.

cat /home/labex/project/policy.py

def can_read(principal, doc): définit une fonction à deux entrées. Le return True indenté autorise actuellement tout le monde. Un dictionnaire Python conserve des champs nommés : principal["id"] lit l’identité authentifiée et doc["owner"] la propriété enregistrée. == compare les valeurs et renvoie un booléen vrai ou faux. Quatre espaces initiaux gardent return dans la fonction.

Remplacez la fonction par une comparaison du propriétaire. La même méthode de texte littéral que précédemment écrit le fichier entier :

cat > /home/labex/project/policy.py <<'EOF'
def can_read(principal, doc):
    return doc["owner"] == principal["id"]
EOF

Passez à l’onglet Test Client et répétez la requête privée d’un autre utilisateur :

Passez à l’onglet Test Client avant d’exécuter la commande suivante.

assistant call documents.read bob-notes

Attendez HTTP 403 et document_denied. Cela diffère de tool_denied : la lecture est autorisée comme opération, mais cet objet est interdit à Alice. Testez le sens inverse :

assistant --as bob call documents.read alice-notes

Il doit aussi être refusé. Le document appartenant à Bob doit rester lisible :

assistant --as bob call documents.read bob-notes

Attendez HTTP 200. Si toutes les lectures échouent avec policy_error, passez à l’onglet Policy Editor et recommencez l’édition en conservant indentation et guillemets ; revenez à l’onglet Test Client avant de réessayer les lectures. Le serveur recharge la fonction à chaque requête. Cette règle intermédiaire de propriété ne rétablit volontairement pas encore le partage ; l’étape suivante le fera.

Rétablir le partage sans croire une identité déclarée

Dans cette étape, autorisez le partage enregistré tout en refusant une identité falsifiée dans une proposition.

Sélectionnez l’onglet Policy Editor dans l’interface du laboratoire pour commencer cette étape.

La règle du propriétaire bloque Alice sur team-plan, bien que Bob lui ait explicitement donné accès. En Python, in teste l’appartenance à une liste et or accepte l’une ou l’autre condition. Combinez propriété et appartenance à la liste enregistrée de partage. Dans Policy Editor :

Passez à l’onglet Policy Editor avant d’exécuter la commande suivante.

cat > /home/labex/project/policy.py <<'EOF'
def can_read(principal, doc):
    return doc["owner"] == principal["id"] or principal["id"] in doc["shared_with"]
EOF

Passez à l’onglet Test Client et testez le partage légitime :

Passez à l’onglet Test Client avant d’exécuter la commande suivante.

assistant call documents.read team-plan

Attendez HTTP 200 et Synthetic shared project plan. Soumettez ensuite une identité falsifiée. --claim bob ajoute user_id: bob aux arguments non fiables ; il ne choisit pas l’identifiant authentifié de Bob :

assistant replay documents.read bob-notes --claim bob

Attendez HTTP 403, le principal alice et document_denied. Avant d’appeler la politique, le serveur associe l’identifiant réel à Alice et ignore l’identité déclarée dans les arguments. Essayez aussi le gestionnaire direct :

assistant call documents.read bob-notes --claim bob

Il doit refuser de même. --as bob et --claim bob ont volontairement des sens différents : le premier utilise un identifiant préparé de Bob ; le second est seulement du texte dans une proposition.

Passez à l’onglet Assistant Tool Lab, connectez-vous comme alice avec training-alice, choisissez documents.read, saisissez bob-notes, mettez bob dans Untrusted user_id (optional), puis cliquez sur Replay proposal. Vérifiez que le résultat identifie toujours alice et refuse le document privé. Remplacez le document par team-plan, effacez l’identité déclarée et rejouez : la lecture partagée utile doit réussir.

Conservez la politique de lecture seule de tools.json. Le contrôle teste les deux comptes, les deux routes, les cas propriétaire/partage/privé et des documents jetables inconnus. Des IDs codés en dur, tout autoriser, croire l’utilisateur proposé ou tout refuser ne satisfont pas cette matrice. Une faute se corrige en réécrivant toute la petite fonction puis en réessayant une lecture.

Résumé

Vous avez appliqué l’accès documentaire avec l’identité authentifiée et la propriété ou le partage enregistrés. Un champ falsifié de proposition ne devient pas une autorité. Le serveur préserve les lectures utiles du propriétaire et des destinataires du partage, tout en refusant objets privés et opérations inutiles. Cela démontre l’autorisation déterministe des outils, pas la fiabilité d’un modèle en direct.