IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

La JSR 375, pour venir à bout des problèmes de sécurité dans Java EE


Sujet :

Java

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2013
    Messages
    320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2013
    Messages : 320
    Points : 27 370
    Points
    27 370
    Billets dans le blog
    1
    Par défaut La JSR 375, pour venir à bout des problèmes de sécurité dans Java EE
    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.

    Nom : Capture.PNG
Affichages : 2293
Taille : 90,2 Ko

    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.)

  2. #2
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 741
    Points
    3 741
    Billets dans le blog
    12
    Par défaut
    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é.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  3. #3
    Membre expérimenté Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2004
    Messages
    897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 897
    Points : 1 635
    Points
    1 635
    Par défaut
    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é

  4. #4
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 551
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 551
    Points : 21 607
    Points
    21 607
    Par défaut
    Citation Envoyé par yann2 Voir le message
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2012
    Messages
    3 020
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2012
    Messages : 3 020
    Points : 16 093
    Points
    16 093
    Par défaut
    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.

  6. #6
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    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

Discussions similaires

  1. Réponses: 12
    Dernier message: 06/08/2015, 16h11
  2. Réponses: 4
    Dernier message: 17/04/2015, 22h14
  3. Réponses: 0
    Dernier message: 05/02/2014, 18h10
  4. Réponses: 1
    Dernier message: 29/04/2010, 14h36
  5. Réponses: 14
    Dernier message: 12/04/2007, 20h09

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo