Sécurisation des entrées
Contrôle de la validité des valeurs en entrée
Par défaut, une valeur en entrée non valide au regard du type java sous-jacent est systématiquement rejetée.
En revanche, une valeur peut être valide au regard du type java sous-jacent, mais invalide vis-à-vis de sa définition Adélia. Pour refuser systématiquement ces entrées, il faut déclarer, dans le fichier CfgConfiguration.properties de l'application web, les clés suivantes :
REST_CHECK_INPUT_STRING_ADELIA_LENGTH_VIOLATION=true
Cette clé, de valeur true, permet de refuser une chaîne dont la longueur est supérieure à sa définition Adélia.
Remarque : Par défaut, la chaîne est automatiquement tronquée afin de respecter la longueur Adélia.
REST_CHECK_INPUT_NUMBER_ADELIA_LENGTH_VIOLATION=true
Cette clé, de valeur true, permet de refuser systématiquement une valeur numérique dont la longueur est supérieure à sa définition Adélia (types NUM_E et NUM_P).
REST_CHECK_INPUT_DATE_TIME_VIOLATION=true
Cette clé, de valeur true, permet de refuser systématiquement une valeur numérique ou une chaîne formatée non valide pour les types DATE, TIME et TIMESTAMP.
Par ailleurs, des clés spécifiques permettent de tracer, au niveau ERREUR, la détection des violations citées ci-dessus (indépendamment du mode choisi pour traiter ces violations) :
REST_CHECK_INPUT_STRING_ADELIA_LENGTH_VIOLATION_LOG_MESSAGE= true
Cette clé, de valeur true, permet de tracer une chaîne dont la longueur est supérieure à sa définition Adélia.
REST_CHECK_INPUT_NUMBER_ADELIA_LENGTH_VIOLATION_LOG_MESSAGE=true
Cette clé, de valeur true, permet de tracer une valeur numérique dont la longueur est supérieure à sa définition Adélia (types NUM_E et NUM_P).
REST_CHECK_INPUT_DATE_TIME_VIOLATION_LOG_MESSAGE=true
Cette clé, de valeur true, permet de tracer une valeur numérique ou une chaîne formatée non valide pour les types DATE, TIME et TIMESTAMP.
Remarque : Par défaut, toutes ces clés ont la valeur false.
Sécurisation des accès
La nécessité de mettre en place des éléments de sécurité fait suite à une réflexion sur :
- l'importance, la nature, la sensibilité des informations à exposer ;
- les catégories de public accédant aux informations ;
- les différentes interactions proposées avec les informations (lecture, création, modification, suppression).
S'il est établi que seuls certains utilisateurs ou groupes d'utilisateurs doivent accéder à certaines informations, ou que seuls certains utilisateurs ou groupes d'utilisateurs doivent créer ou modifier ou supprimer certaines informations, une stratégie de sécurisation des ressources doit alors être mise en œuvre.
Sécurisation via les mécanismes standards proposés par le container Java EE
Le container Java EE hébergeant les services Web REST Adélia Studio propose nativement des solutions pour sécuriser les ressources, à l'aide de la gestion de l'authentification d'une part et à l'aide de la gestion des autorisations d'autre part.
Néanmoins la gestion de la sécurité des ressources par le biais des mécanismes propres au container Java EE ne répond pas correctement aux besoins imposés par le paradigme REST de communication sans état.
En effet, l'authentification Java EE repose sur un mécanisme qui stocke des informations sur le serveur de ressources (gestion d'un contexte par client authentifié).
Ce mécanisme a également l'inconvénient d'instaurer un couplage fort entre l'authentification et l'accès aux ressources ; il interdit par conséquent la possibilité de déléguer la phase d'authentification à un tiers.
La sécurisation via le container Java EE reste cependant possible et peut être couplée avec la gestion des autorisations via des annotations dans les programmes de services Adélia.
Sécurisation via un jeton (JWT)
Pour pallier les inconvénients soulevés par les mécanismes natifs de sécurité des containers Java EE, Adélia Studio propose une gestion de sécurisation des ressources à l'aide de jetons JWT (Json Web Token).
Le mécanisme de sécurisation s'effectue en deux étapes :
- La première étape consiste à authentifier le client demandeur de ressources.
Ce dernier accède à un service d'authentification qui délivre un jeton JWT contre des credentials (identifiants de connexion) valides.
Le jeton contient différentes informations à travers des attributs nommés claims : notamment le nom de l'utilisateur authentifié, une liste de rôles, une limite dans le temps de la validité du jeton. Pour assurer sa confidentialité, le jeton est signé numériquement à l'aide d'une clé de chiffrement. - La seconde étape consiste à accéder à la ressource voulue en fournissant au serveur de ressources, via le header HTTP Authorization, le jeton précédemment obtenu.
L'accès à la ressource est alors conditionné, d'une part à la validité du jeton et d'autre part à la mise en regard des rôles du client authentifié avec les autorisations requises.