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.

[TuThoThai]

Décision du groupe en date du 27/03/2025 :

• accord général du groupe pour adopter l'idée
• besoin de reformuler pour être moins spécifique à une implémentation donnée
• retravailler la partie 5.5.9 Réseau et sécurité du profil pour la prendre en compte

[Henault]

15/05/25 :
1- Le requestorref dans le header permet de ne pas avoir à parser le xml pour connaitre l'émetteur.

2- OAuth permet de faire une authentification forte par utilisateur. Peut être lourd à mettre en œuvre.
=> Serveur 1/3 OAuth pour la gestion des clefs
=> Sera détaillé dans la PR.
3- Sur le PAN il y a des limites d'accès. RateLimit
Action Création d'une PR (THT)