Sécurisation de l’accès à ChattyWS

, par Bertrand Degoy

Il n’est évidemment pas possible d’exposer un service sur le réseau et sur le Web sans en contrôler l’accès.
Nous décrivons ici différentes configurations d’accès au service et les méthodes de sécurisation correspondantes.

Différents modes d’accès et de sécurisation

Accès par le réseau

Le service répond au protocole WSGI par l’intermédiaire du port TCP 5000 [1].
Cela permet d’appliquer toutes les bonnes pratiques de sécurité au niveau réseau, et notamment des règles de routage et de filtrage TCP/IP au niveau des pare-feu ou des règles Kerberos.

De telles dispositions peuvent suffire pour assurer la sécurité de l’accès au service dans une configuration de réseau local ou privé.

Dans ce qui suit, nous allons considérer la sécurité au niveau applicatif. Il est important de noter que la meilleure pratique consiste à ne pas négliger pour autant la sécurité du niveau réseau.

Accès par le Web

Accéder à ChattyWS par l’intermédiaire d’Apache [2] en proxy inverse permet d’exposer le service sur le Web. Du point de vue de la sécurité, cela permet également de :
 imposer le protocole HTTP sécurisé par TLS (https://),
 permettre la mention de règles Require dans la configuration VirtualHost,
 gérer (éventuellement) l’authentification au niveau d’Apache.

Les aspects techniques sont développés sous les titres :
 Configuration du VirtualHost pour exposer le service sur le Web
 Configuration du VirtualHost pour l’authentification OIDC

Authentification OIDC

S’agissant de l’authentification par OpenID Connect, deux configurations sont possibles :

1. comme mentionné ci-dessus, l’authentification OIDC peut être gérée par Apache ; le serveur Apache se comporte alors comme un client du serveur OIDC.

2. le service peut être programmé pour gérer à son niveau l’authentification OIDC ; il est alors une ressource protégée, alors que l’application à l’origine de la requête est le client.

Pour faire le choix entre ces deux configurations, il faut considérer les points suivants :

 Dans le premier cas, ni le service, ni l’application à l’origine de la requête n’ont besoin d’être modifiés pour gérer le protocole OIDC. Dans le deuxième cas, l’application et le service doivent être modifiés.

 Une simple configuration du VirtualHost pour l’authentification OIDC (cas 1) se réduit à une autorisation d’accès.
Pour exploiter pleinement les informations du jeton d’identité (identité de l’utilisateur, de l’application, autorisations accordées (Granted Scopes), validité, etc.), il faut adopter la deuxième solution (cas2). Cela permet de programmer le service pour répondre aux requêtes qui lui sont adressées en fonction des données de l’authentification, et notamment de la portée de l’autorisation accordée à l’utilisateur et/ou à l’application à l’origine de la requête.

 Dans le cas 1, l’application cliente enregistrée sur le serveur OIDC est l’hôte virtuel. C’est Apache qui gérera le dialogue d’authentification avec l’utilisateur, ainsi le service ne connaîtra rien de l’application à l’origine de la requête ni de ses droits.

 Dans le cas 2, l’application enregistrée sur le serveur OIDC est bien celle qui est à l’origine de la requête et qui gérera le dialogue d’authentification avec l’utilisateur. Le jeton d’identité transmettra des informations d’identité et d’autorisation concernant non seulement l’application, mais aussi les portées d’autorisation de l’utilisateur et toutes sortes de données complémentaires définies dans le cadre de cette application.

 La technique des Thèmes permet de partager un service d’IA entre différents utilisateurs (multi-tenant) par exemple sur une plateformeSaaS. Le jeton JWT est le moyen idéal de transmettre au service quels thèmes et quels modes seront accessibles pour une application et un utilisateur donnés.

Sans rentrer dans plus de détails, la deuxième configuration présente une infinité d’avantages pour assurer pleinement la sécurité au niveau applicatif en modulant l’accès aux données en fonction des identités et des portées d’autorisation.

Les aspects techniques sont développés dans la suite :
 Configuration du VirtualHost pour exposer le service sur le Web,
 Limitation du risque de DDOS,
 Exploitation des paramètres d’authentification passés par le Header.
 Gestion du dialogue OIDC au niveau du service.
 Tenir compte des paramètres d’authentification pour accorder l’accès aux Thèmes
 Tenir compte des paramètres d’authentification dans la réponse des Modes.

Accès réservé : connectez vous pour en savoir plus.

Notes

[1Le numéro du port peut être modifié

[2Les possibilités d’autres serveurs HTTPD n’ont pas été explorées.