Documentation sur la remontée d'informations vers le portail

~~

Première considération : identifier l'usager concerné.

Un attribut partagé existant désormais entre le portail et l'application métier, on peut avoir un webservice qui sur cette info crée un nouvel attribut, une clé de fédération, qui permettra au reste de changer sans que ça n'ait d'incidence sur la liaison.

(par la suite j'utilise "clé de fédération", ça peut être cette clé dédiée mais ça peut aussi être l'attribut commun préexistant)

~~

Noter une préférence au stateless; c'est-à-dire surtout qu'on préfère passer le paramètre "clé de fédération" à chaque requête plutôt qu'avoir un premier appel établissant une session.

(ou ne pas noter de préférence et dire que les deux sont possibles ?)

~~

Peut-être à ce moment-ci amener des considérations de format.

~~

Considérations de sécurité

~~

À propos d'oauth : on pourrait imaginer quelque chose qui marche très bien mais ça me semble demander plus de boulot du côté de l'application métier, écran de validation de partage d'attribut ("acceptez-vous de fournir la liste des livres en attente à l'application 'GRU' ?") et cie. (ça demande sans doute trop aux applis métiers, passons).

~~

Par série d'application, détailler les webservices attendus.