ap2i/doc/internal_requests.md

Internal Requests

Principe général

Les requêtes internes sont des requêtes envoyées de ap2i vers opentalent-platform ou dans le sens inverse, par exemple pour demander un fichier.

Ces requêtes ne sont pas protégées par l'authentification Symfony standard, car elles doivent pouvoir être exécutées en dehors du cadre d'une requête utilisateur, par exemple lors d'une exécution en ligne de commande ou lors d'un processus asynchrone exécuté par messenger.

Pour éviter tout risque de sécurité lié à ces routes :

• on restreint leur accès aux ips internes
• on conditionne l'autorisation à la présence d'un token
• on limite les routes concernées

Ainsi, si l'on prend l'exemple d'une requête /internal/download/123 sur ap2i :

• Un utilisateur dans le VPN qui ferait un curl à cette adresse recevra une erreur 500 à cause du token manquant
• Un utilisateur hors VPN, même s'il connaissait le token, recevra une erreur 500, car n'ayant pas une ip autorisée
• Une requête issue de la V1 sera autorisée sans authentification

Ip internes

Les ips considérées comme interne sont :

• Le localhost (127.0.0.[0-1])
• Les adresses venant de l'intérieur du VPN (10.8.0.[0-255])
• Les adresses publiques des serveurs Opentalent (141.94.117.[33-61])
• Les adresses privées des serveurs Opentalent (172.16.0.[0-255])
• Les adresses des autres containers docker (172.20.[0-255].[0-255])

Plus d'infos ici : https://ressources.opentalent.fr/display/SI/Infrastructure+et+reseau

Mise en oeuvre

On met en place un pattern de routes de la forme /api/internal/* qui sera uniquement dédié aux requêtes internes entre les deux API ou à d'autres éventuels échanges entre systèmes.

Les appels à cette route ne sont autorisés que si :

1. Que l'ip du client dont émet la requête fait partie d'un pool autorisé d'ips internes
2. Qu'un header 'internal-requests-token' est défini et que sa valeur correspond à la valeur attendue.

Si ces deux conditions ne sont pas remplies, la requête est rejetée, et ce même si l'utilisateur est authentifié.

Les routes internal sont configurées ici : config/packages/security.yaml

Valider le fonctionnement

Soit $id l'id d'un fichier stocké sur l'environnement V2 On part du principe que l'utilisateur authentifié a des droits suffisants pour voir ce fichier.

Côté ap2i, les requêtes suivantes doivent donner les résultats correspondants :

query	header défini	authentifié	VPN activé	Résultat attendu
/api/internal/download/$id	NON	NON	NON	401 Unauthorized
/api/internal/download/$id	OUI	NON	NON	401 Unauthorized
/api/internal/download/$id	OUI	NON	OUI	200 OK
/api/internal/download/$id	OUI	OUI	OUI	200 OK
/api/internal/download/$id	OUI	OUI	NON	403 Forbidden
/api/internal/download/$id	NON	OUI	OUI	403 Forbidden
/api/download/$id	*	NON	*	401 Unauthorized
/api/download/$id	*	OUI	*	200 OK

Les mêmes tests s'appliquent côté V1, appliqués à un fichier stocké sur l'environnement de la V1.