Protocoles de négociation

Nous avons vu, au précédent chapitre, le protocole de négociation entre deux agents au travers de l'algorithme de négociation automatisé ETTG. Les échanges de l'arbre de né-gociation peuvent être retranscrits en messages protocolaires d'échanges des règlements. Lorsque la négociation aboutit, un consensus est atteint et les messages contenant les infor-mations sont échangés. À ce protocole basique de négociation, il faut ajouter les messages d'initiation. Cette initiation peut être faite par l'initiateur dans un message indiquant la requête d'un objet, ou par le fournisseur dans un message contenant un règlement en indi-quant éventuellement le sujet de la négociation. Notons que l'initiation par le fournisseur est consécutive à un accès applicatif, elle est donc indiquée dans un message dont l'agent de négociation initiateur pourrait s'attendre à ce que ce soit un message applicatif. Enn, il doit exister un message du protocole de négociation qui soit un message d'encapsulation et qui serve au transport des ux applicatifs. Au chapitre suivant, nous revenons sur la sérialisation de ce protocole de négociation.

Il est également nécessaire de préciser les protocoles de communication entre les agents et les applications qu'ils régissent. Nous considérons que chaque application a la charge soit de déterminer les rôles requis pour chacun de ses objets (un service, une tâche, une méthode d'une classe, etc.), soit que l'agent de négociation est capable de déduire les rôles requis en fonction de l'objet indiqué par l'application. Dans le cas où l'agent de négocia-tion fournisseur déduit les rôles en foncnégocia-tion d'un objet, ce qu'il délivre à l'applicanégocia-tion est bien une autorisation que l'application met en ÷uvre. Les applications ont alors la charge de vérier que les ux sont porteurs des autorisations. Notons qu'au chapitre précédent nous avons fait le choix de déclarer au sein du règlement de l'agent fournisseur des règles précisant les rôles nécessaires pour certains objets de l'application (un devis par exemple) an d'illustrer ce besoin. Dans le cas où l'application indique les rôles dont elle a besoin, le terme autorisation est abusif, il s'agit plus précisément de l'armation des rôles de l'usa-ger par l'agent de négociation. Cela suppose que les applications et l'agent de négociation partage un espace de noms commun pour décrire les rôles. Les applications ont alors la charge de vérier que les ux sont porteurs des rôles requis.

Quel que soit ce choix, l'agent de négociation fournisseur a la charge d'interagir avec l'initiateur pour qu'il puisse apporter les preuves qu'il possède les rôles requis. Il est pos-sible que des rôles ou des autorisations obtenus pour un accès auprès d'une application soient utilisables pour d'autres applications, et cela sans que l'utilisateur n'ait à fournir à nouveau les preuves correspondant à ces rôles. Notons que lorsque ces applications sont

VII.1. Intégration 191 hébergées par une organisation, il s'agit de certier les rôles ou les autorisations, ce qui est une solution de délégation d'autorisations entre organisations liées de conance. La délégation par les applications nécessite une conception applicative  saine  où, dès la conception, les objets et les règles de contrôle d'accès sont déterminés. Ensuite, l'as-sociation entre objets et rôles peut être faite au niveau de l'application ou de l'agent de négociation. L'application met en ÷uvre le contrôle d'accès, ce qui pour certains la légi-time pour cette tâche. Pour d'autres, l'agent de négociation est l'opportunité de centraliser le contrôle d'accès. Notons alors que, dans ce cas, le besoin d'expressivité est fort envers le langage de contrôle d'accès qui doit permettre d'exprimer les contraintes de toutes les applications. Au chapitre précédent, nous avons donné un exemple avec le langage ATNL dont l'instruction disclose permet d'indiquer les règles de libération d'un objet. Cette instruction peut donc servir à indiquer que le fournisseur accepte de diuser une information en fonction de l'application qui est sollicitée, mais également pour exprimer les conditions d'accès sur des objets de l'application. Il faut pour cela que le module de l'agent de négociation en charge d'interpréter le règlement puisse faire la distinction entre ces deux utilisations de l'instruction disclose.

Que l'agent de négociation ait la charge ou non d'associer les rôles nécessaires aux objets requis, c'est au niveau de l'application qu'est déterminé le fait qu'un objet soit sujet à un contrôle d'accès. Il pourrait sembler plus simple que l'agent de négociation détermine de lui-même, à la vue des ux applicatifs, les objets des requêtes applicatives, et par conséquent s'ils sont sujets à négociation. Cependant, cela supposerait que l'agent de né-gociation fournisseur soit à même d'interpréter les ux applicatifs, ce qui n'est pas son rôle. La délégation de la gestion des identités implique que les applications puissent traduire le fait qu'elles requièrent des informations d'identité, par exemple un pseudonyme ou d'autres attributs d'identité, donc qu'elles soient capables de formuler cela auprès de leur agent de négociation. Elles peuvent également avoir à disposition leur propre base de données d'identités, leur servant par exemple à personnaliser un service ou à auditer les activités. Elles peuvent donc ne requérir qu'un identiant connu, ce qui se traduirait par la requête de l'objet établissement d'identité et de l'information pseudonyme à leur agent de négociation.

En résumé, entre le client applicatif et l'agent de négociation initiateur, le protocole, que nous appelons  protocole de négociation inter-couches , doit permettre d'indiquer, du client vers l'agent :

 un ux applicatif destiné à un fournisseur (en indiquant un point d'entrée applicatif, une URL par exemple),

 une initiation en indiquant son objet.

De l'agent de négociation initiateur vers le client applicatif, il doit permettre de signaliser :  les ux applicatifs,

 les résultats des négociations si l'application en était à l'origine, et notamment des informations sur le fournisseur.

Entre l'agent de négociation fournisseur et le serveur applicatif, le protocole de négociation inter-couches doit permettre d'indiquer, du serveur vers l'agent :

 un ux applicatif destiné à l'initiateur,

 une initiation en indiquant des rôles ou un objet.

De l'agent de négociation fournisseur vers le serveur applicatif, il doit permettre de signa-liser :

 les ux applicatifs,

 une initiation en indiquant l'objet.

 des rôles obtenus par l'initiateur pour l'autoriser ou une autorisation pour un objet.  des informations d'identité sur l'initiateur de manière à personnaliser la ressource. À titre d'exemple, supposons un client Web qui redirige son ux vers son agent. Ce der-nier établit un tunnel SSL avec le pseudonyme délivré par l'agent fournisseur. L'agent fournisseur redirige ensuite le ux à l'application. L'encapsulation du ux applicatif, le protocole HTTP dans cet exemple, est représentée à la gure VII.4 .

Trame HTTP Protocole de négociation Protocole de Transport SSL Client applicatif Agent de négociation INITIATEUR Trame HTTP Protocole de négociation "inter−couches" Serveur applicatif Agent de négociation FOURNISSEUR Encapsulation couche de négociation Légende: Trame HTTP Protocole de négociation "inter−couches"

Fig. VII.4  Encapsulation du ux applicatif HTTP.

Supposons que le ux applicatif soit sujet à un accès contrôlé, ce que le serveur Web détecte. Il indique à son agent qu'une négociation doit être conduite en indiquant son objet. L'agent de négociation fournisseur retourne à l'agent de négociation initiateur un

VII.1. Intégration 193 règlement (le fournisseur a déduit les rôles nécessaire de l'objet). Cela est illustré à la gure VII.5.