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

Spring Web Java Discussion :

Spring security en phase de "production"


Sujet :

Spring Web Java

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    42
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2006
    Messages : 42
    Points : 30
    Points
    30
    Par défaut Spring security en phase de "production"
    Bonjour,

    Il y a quelques temps j'avais posé une question sur le forum pour savoir qu'elle pouvait être une orientation judicieuse pour mettre en oeuvre la sécurité d'un application web. Quelqu'un avait laissé sur le forum une mention de Spring Security et j'ai donc commencé a étudié les tutoriels.

    Aujourd'hui je suis à peu près capable d'utiliser le framework pour mon application Web et je pense parvenir à créer une base de données contenant les autorisations, les rôles, les logins, mots de passe... Le but étant de reproduire le comportement classique d'un site web (création d'un compte utilisateur automatiquement...).

    J'utilise le serveur Glassfish et ai pu constaté qu'une autre méthode pour la sécurité peut consister à configurer le serveur Glassfish directement en créant un realm (comme indiqué sur le site d'Oracle) ...

    Ma question est donc la suivante, le jour ou mon application web sera terminée (probablement sous forme d'un .war), pour passer à la phase de production je n'aurais sans doute aucun problème si j'utilise le framework spring mais si je décide d'utiliser la sécurité du serveur Glassfish aurais-je tous les privilèges nécessaires pour faire les configurations sur la machine commerciale qui héberge mon site?

    Le framework Spring est-il bien la solution pour faire ce que je souhaite?

    En termes de performance, quelle est la meilleure solution?

    Je vous remercie par avance,

    Bou

  2. #2
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    42
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2006
    Messages : 42
    Points : 30
    Points
    30
    Par défaut Une réponse...
    Bonjour,

    J'ai trouvé ceci dans le livre "Spring par la pratique".

    "En Java, nous disposons de JAAS (Java Authentication and Authorization Service) et de la spécification Java EE pour nous aider dans cette tâche. Il s’agit de standards largement utilisés, qu’il est important de connaître, puisqu’un grand nombre de solutions s’appuient sur eux. Nous verrons les limitations de ces deux spécifications et les raisons pour lesquelles elles ne sont pas suffisantes pour développer des applications d’entreprise un tant soit peu complexes.
    Spring Security est un projet du portfolio Spring qui propose une solution de sécurité complète intégrée aux systèmes utilisant Spring. Très largement utilisée au sein de la communauté Spring, elle peut de facto être considérée comme un standard."

    "Le premier avantage de Spring Security est sa portabilité. Ne dépendant pas d’un serveur d’applications particulier, son utilisation est identique quel que soit le serveur utilisé. C’est grâce à cela que Tudu Lists peut être utilisé sans reconfiguration sur Tomcat, JBoss, Geronimo ou WebLogic.
    Cette portabilité est particulièrement importante si l’application développée doit pouvoir être vendue à un grand nombre de clients possédant des systèmes hétérogènes. Dans le cadre d’une application développée en interne, il n’en reste pas moins dommage de se trouver bloqué sur un serveur d’applications uniquement à cause d’une problématique de sécurité."


    J'imagine donc que Spring reste "la meilleure solution" (sans avis contraire) ou tout du moins "la meilleure solution portable".

    Je laisse le soin à quelqu'un au fait de ces considérations de clore la discussion.

    Bou

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