Sécurisation des échanges par entête HTTP X-SIRI-RequestorRef

[albanpeignier]

L'authentification par une information dans le contenu de la requête (aka RequestorRef, ProducerRef, etc.) n'est plus "dans les règles de l'art" en 2025.

En l'absence de solutions techniques (dans la norme SIRI ou dans le profil France), chaque acteur de la communauté peut mettre en place sa solution maison. Cela nuit clairement à la compatibilité entre les systèmes (sans améliorer parfois la sécurité ...).

Entête HTTP X-SIRI-RequestorRef

Le profil devrait recommander l'utilisation d'un entête HTTP "standard" (par exemple : X-SIRI-RequestorRef) qui reprenne la valeur du RequestorRef (ou celle du ProducerRef dans les notifications). qui se trouve dans le contenu XML.

Techniquement, cela permet une identification avant lecture du XML. Ce "détail" change tout en matière de sécurité. Il permet notamment de prendre des mesures de protection en amont du serveur SIRI lui-même

C'est simple à mettre en place. Et cela a l'avantage de ne pas inventer une nouvelle valeur dans le paramétrage des applications.

curl --header 'X-SIRI-RequestorRef: opendata' --header 'Content-Type: application/xml' -d@- https://ara-api.enroute.mobi/irigo/siri <<XML
<?xml version='1.0' encoding='utf-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <sw:CheckStatus xmlns:siri="http://www.siri.org.uk/siri" xmlns:sw="http://wsdl.siri.org.uk">
      <Request>
        <siri:RequestTimestamp>2025-01-27T16:32:13.860+01:00</siri:RequestTimestamp>
        <siri:RequestorRef>opendata</siri:RequestorRef>
        <siri:MessageIdentifier>Test</siri:MessageIdentifier>
      </Request>
      <RequestExtension/>
    </sw:CheckStatus>
  </S:Body>
</S:Envelope>
XML

Sécuriser les informations d'identification

Le profil devrait rappeler que les valeurs utilisées (en RequestorRef, ProducerRef, ...) doivent être vu par les utilisateurs, les applications, etc. comme des clés d'accès. Donc être créées, stockées, diffusées avec les règles de sécurité qui s'imposent.

Notamment que ses valeurs doivent inclure une grande part "d'aléatoire". Donc plutôt être de la forme "monsae-Yu9kaosh2thu3pohs4chaeph" que "monsae".

Le filtage par IP est trop souvent vu comme la solution unique pour sécuriser les échanges, au mépris des autres règles de sécurité standards.

OAuth 2.0

Si des acteurs veulent se tourner vers des mécanismes plus robustes, le profil devrait recommander l'OAuth 2.0 et son "Client Credentials Grant Type" qui est standard et pris en charge par la plupart des outils HTTP classiques.

C'est utilisé par exemple par les serveurs SIRI DDIP Suisse (cf https://www.oev-info.ch/sites/default/files/2023-04/siri_realisation-guide_pt_ch_v0.9.0.pdf).

Néanmoins, ce type d'authentification ne doit être utilisé pour limiter l'accès à l'open data.

Généralisation ?

Ces recommandations devraient être portées par la norme SIRI elle-même pour rendre plus robuste le standard et ses déploiements.