Project

General

Profile

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

  • Donner moins d'importance aux questions de protocoles et formats. (on se débrouille toujours)
  • Donner plus d'importance au fonctionnel. (si le nécessaire n'est pas exposé, on ne peut rien faire)

~~

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

  • attribut commun à la GRU et à l'application tierce, par exemple l'adresse électronique de l'usager
    • avantage : donnée existante, sans manipulation aucune l'usager voit apparaitre sur le portail ses données de l'application métier
    • inconvénient : l'usager peut utiliser des adresses mail différentes, peut en changer en cours de route d'un côté ou de l'autre et soudain ça ne marche plus, etc.
  • attribut commun parce que référentiel commun (ex: on est branché sur un LDAP et l'application métier est branché sur le même)
    • avantage : comme précédent
    • inconvénient : la situation peut se rencontrer pour les agents, pas trop pour les usagers, il me semble.
  • sans attribut commun préexistant, un mécanisme d'apparaige est nécessaire
    • si l'application est par ailleurs utilisée directement par les usagers, ceux-ci auront identifiant/mot de passe, ça peut être la donnée d'apparaige.
    • si c'est une application "backend", elle doit produire et communiquer des identifiants, par exemple en mentionnant un numéro et un code de liaison sur une facture.
  • dans les deux situations c'est vraiment utile d'avoir un webservice de validation du couple (identifiant/mot de passe ou numéro/code de liaison)

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.

  • SOAP, recommandations particulières ?
    • pas de MTOM (passage des pièces jointes en pièces détachés du POST)
    • authentification HTTP Basic ou TLS, pas de signature XMLSEC, WS-Security, etc..
    • ne pas utiliser d'autre format dans le XML (JSON in XML, ou TSV/CSV in XML) uniquement du XML
    • ne pas transformer un autre format vers XML (JSON to XML) via une moulinette, il faut un vrai schéma XML qu'on puisse valider; sinon impossible d'attribuer des responsabilités
    • chaque élément/attribut/type du schéma doit contenir une balise description avec la sémantique de la donnée portée
    • fournir WSDL et XSD à jour en ligne, le service doit être utilisable depuis le WSDL seul
    • faire du versionning (si l'interface change on maintient l'ancienne, on ajoute juste les nouvelles interfaces sur de nouvelles URLs)
  • REST/JSON, recommandations particulières ?

~~

Considérations de sécurité

  • transport, https
  • authentification de l'appelant, certificat client (?), mécanisme de signature d'URL ?
  • restriction d'IP
  • VPN : plutôt non

~~

À 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.

Also available in: PDF HTML TXT