ap2i/doc/internal_requests.md

Internal Requests

Principe général

Les requêtes internes sont des requêtes échangées entre les services internes à l'entreprise (maestro, ap2i, opentalent-platform...), par exemple pour demander un fichier.

Ces requêtes ne sont pas systématiquement 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 soit à la présence d'un token, soit à une authentification en tant que super-admin.
• on limite les routes concernées

Ainsi, si l'on prend l'exemple d'une requête /internal/download/123 envoyée à ap2i :

• Un utilisateur dans le VPN sans le token qui ferait un CURL à cette adresse recevra une erreur 403
• Un utilisateur hors VPN, même s'il connaissait le token, recevra une erreur 403, car n'ayant pas une ip autorisée
• Une requête issue de la V1 avec le bon token et provenant d'une ip interne sera autorisée sans authentification

• Une requête d'un utilisateur connecté en tant que super admin et à l'intérieur du VPN pourra aussi aboutir.

  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 services opentalent.

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 OU que l'utilisateur est connecté en tant que super-admin.

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

Exemple avec la route dédié au téléchargement des fichiers, $id étant 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	super-admin	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	NON	OUI	OUI	200 OK
/api/internal/download/$id	OUI	OUI	NON	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.