Discussion :

[Victor Vincent]

La JSR 375, pour venir à bout des problèmes de sécurité dans Java EE,
c'est l'objectif que s'est fixé la Java Community Process (JCP)

La communauté Java, consciente des problèmes de sécurité de Java EE, cherche à régler ces dernières dans la nouvelle JSR 375. Cette JSR a pour but d'améliorer la plateforme Java EE en veillant à ce que l'aspect sécurité soit pleinement pris en compte dans un contexte où les applications sont de plus en plus orientées vers le cloud. La communauté Java EE a beaucoup contribué à cette prise de conscience notamment en postant des feedbacks qui mettent en avant la nécessité d'améliorer les aspects sécurité de la plateforme comme indiqué sur la figure qui suit.

La JSR 375, qui cible la plateforme Java EE 8 et les versions plus récentes, va aussi favoriser la portabilité des applications autonomes sur tous les serveurs Java EE, mais aussi va faire la promotion de l'utilisation des concepts modernes de programmation tels que l'injection de dépendance ou les Expressions Languages (ref devp). D'après la JCP, l'API de sécurité de Java EE va être simplifiée au maximum, standardisée, et modernisée à travers la plateforme notamment pour les aspects identifiés par la communauté. En effet, plusieurs aspects ont été relevés par la communauté comme devant être amélioré sur le plan de la sécurité.

• La gestion des utilisateurs
  
  
  Actuellement il n'existe pas de support standardisé pour la gestion des utilisateurs dans Java EE. Les développeurs utilisent donc des méthodes différentes pour créer, supprimer des utilisateurs ou mettre à jour leurs informations dans la plateforme Java EE. Typiquement, ils vont trouver des astuces en utilisant des librairies tierces ou en développant leurs propres solutions pour gérer les utilisateurs, ce qui peut donner un résultat vulnérable et peu sécurisé. La JCP est en train de mettre donc en oeuvre un service de gestion des utilisateurs standardisé qui permettrait aux développeurs d’effectuer les opérations de gestion des utilisateurs. Le service va être en mesure de manipuler des données utilisateurs provenant de sources de données comme LDAP, de simples fichiers, des données embarquées dans des applications. La source de données pourra changer d'un déploiement sur un environnement à un autre ce qui permet d'avoir des sources de données différentes pour le développement, les tests et la production.
  
  
• Gestion des alias de mots de passe
  
  
  Le JCP a fait remarquer également qu'il n'existe pas de support standardisé constituant une référence pour gérer les alias de mots passes sécurisés et pouvant gérer leur stockage dans la plateforme Java EE. Les développeurs auront la possibilité avec la JSR 375 d'exiger un mot de passe à plusieurs endroits du code tels que dans les annotations, les descripteurs de déploiement, les URL ou de simples fichiers. Le JCP est en train de proposer une syntaxe standard pour indiquer des alias de mot de passe ainsi que des moyens pour faire la correspondance entre l'alias et la valeur du mot de passe. Le dépôt de mot de passe peut être une archive sécurisée d'identifiants ou être déployé avec l'application de manière indépendante.
  
  
  
• La gestion du mapping des rôles
  
  Étant donné qu'il n'existe pas de support standardisé pour le mapping des rôles dans la plateforme Java EE, les développeurs n'ont pas de moyens à leur disposition leur permettant de faire le maping entre les rôles, les utilisateurs et les groupes d’utilisateurs. Les participants à la JCP proposent un service standard de gestion des rôles permettant aux développeurs d’effectuer les opérations de mapping entre utilisateurs et rôles telles que l’octroi et la révocation de rôle, mais aussi des opérations sur les utilisateurs et les groupes. Les sources de données pour le mapping des rôles sont les mêmes que pour la gestion des utilisateurs et peuvent être changées d’un environnement de déploiement à un autre permettant ainsi d’avoir des mapping différents pour le développement, les tests et la production.
  
  
  
• La gestion de l’authentification
  
  la JCP propose pour ce point des mécanismes permettant à l’application d’informer la plateforme d’exécution sur le service de gestion des utilisateurs et le service de gestion des rôles à utiliser. Il s’agira d’une configuration de portée application qui va faire le lien entre une référence vers un service de gestion des utilisateurs et une référence vers un service de gestion des rôles définit dans l’application et qui va être utilisé par la plateforme d’exécution à chaque fois qu’une authentification est effectuée via la plateforme. Tout comme le mapping, la configuration peut être changée d’un environnement de déploiement à un autre permettant d’avoir une configuration différente pour le développement, les tests et la production.
  
  
• La gestion des autorisations
  
  Actuellement, Java EE ne supporte qu’une gestion des autorisations par vérification du rôle de l’utilisateur authentifié. Il n’existe pas de support pour gérer de manière standardisée les autorisations à travers des règles incorporées dans le domaine de l’application. La JCP propose à cet effet de définir des intercepteurs standardisés capables d’incorporer des règles basées sur l’application dans les autorisations d’accès. Ces intercepteurs définis sous forme d’annotations pourront être invoqués comme un intercepteur CDI en utilisant @AroundInvoke. Les intercepteurs auront accès au contexte d’invocation courant ainsi qu’aux attributs de l’utilisateur authentifié. Ils seront définis sous forme de simple texte comme les Java Expression Language (EL) et donneront la possibilité d’accéder aux Managed Beans. Le code des intercepteurs peut être défini dans la classe Java elle-même ou bien être référencé à partir d’une autre source de données telle que LDAP ou un fichier externe.

Source : Java Community Process

Et vous ?

Que pensez vous de la JSR 375 ?

Voir aussi

la rubrique Java (Cours, Tutoriels, FAQ, etc.)

[Gugelhupf]

Bonjour,

Ça fait plaisir de voir qu'ils prennent en compte ces composants dans le standard, tous les autres framework le font déjà. J'espère juste que les API proposés seront instinctifs pour les utilisateurs. Il manque tout de même une API Form à mon goût, j'ai commencé à développer le mien.

PS: Plusieurs fautes dans cette phrase :

Typiquement, ils vont trouver des astuces en utilisant des librairies tierces ou en développement leurs propres solutions pour gérer les utilisateurs, ce qui peut donner une résultat vulnérable et peu sécurisé.

[yann2]

Bonjour

Sinon, il est aussi possible d'utiliser Spring Security qui intègre beaucoup plus de fonctionnalités. Mais, c'est pas plus mal si c'est certains points sont directement intégrés dans la spec.

Sinon, c'est quoi un alias de mot de passe ? C'est la première fois que j'entends parler de ça et google ne m'a pas beaucoup aidé

[thelvin]

Sinon, c'est quoi un alias de mot de passe ? C'est la première fois que j'entends parler de ça et google ne m'a pas beaucoup aidé

Je connaissais pas le terme, mais la notion devrait être familière :

Quand tu déploies une appli web, tu as besoin qu'elle se connecte à diverses choses : des BDD, un SMTP, des FTP, des services web, peut-être un peu de SSH, disque dur monté, divers trucs chiffrés qui ont besoin d'une clé de déchiffrage.
Et donc, chacun de ces trucs-là va demander un identifiant avec mot de passe ou similaire.
La question est : où vas-tu renseigner ces mots de passe pour que l'appli les trouve et puisse les envoyer, et est-ce que ça ne te semble pas un chtit peu vulnérable comme façon de faire ?

La plupart d'entre nous se résignent à voir des tonnes de mots de passe en clair, ou chiffrés mais faciles à déchiffrer, dans des fichiers de conf'.

D'autres ont réussi à pousser leur stockage dans un portefeuille chiffré de mots de passes, à l'accès nécessitant des certificats. L'application communique avec ce portefeuille lorsqu'elle a besoin de connaître un mot de passe.
Ce qui veut dire que du coup, il est nécessaire d'identifier quel est le mot de passe dont on a besoin pour quelle occasion. Autrement dit, les mots de passe pour chaque chose ont besoin d'un nom, et quand on sait qu'on va devoir le transmettre, on va indiquer ce nom à la place. D'où alias de mot de passe à la place d'un mot de passe directement.

[Carhiboux]

Pour moi, un gestionnaire d'alias de mot de passe, c'est déplacer le problème. Et potentiellement l'aggraver, parce qu'au lieu d'avoir juste les mots de passe nécessaire pour l'appli, tu auras potentiellement accès à plein d'autres mots de passe que tu n'avais même pas pensé à chercher...

Et je ne suis pas convaincu que ce soit à Java, nativement, de gérer la sécurité... le risque étant bien entendu que si il devait exister une faille (et il en existera), tout le monde soit impacté. Utiliser les librairies tierces n'est pas une solution parfaite, mais me semble presque plus sur.

[sekaijin]

non tu n'as pas déplacé le problème

imagine un coffre qui contient pour chaque utilisateur
nom :
ssh :
database :
ftp:
...

ou nom est le nom du user et ssh sont passe pour ssh databse son passe pour la base ftp son passe pour ftp etc.

lorsque ton utilisateur est authentifié si le code doit faire un accès à la base au nom de l'utilisateur tu demande l'alias 'database' au coffre.

l'appli ne connait que 'database' le mot 'database' là ou normalement il fallait connaitre le mot de passe de la base pour cet utilisateur.

et gros là ou tu lisait dans un fichiers ou dans une base le mot de passe pour la database et que tu faisait un connect(myUser, myPassword);.
tu fait un truc équivalent à connect(myUser, forteresse.get(myUser, 'database');. le tout en gérant la sécurité des appels.

A+JYT