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é.
- Gestion des alias de mots de passe
- La gestion du mapping des rôles
- La gestion de l’authentification
- La gestion des autorisations
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.
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.
É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 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.
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.) 
Envoyé par yann2
