Quand passer de la sécurité gérée par conteneurs à des alternatives comme Apache Shiro, sécurité de printemps?
j'essaie de sécuriser mon application qui est construite en utilisant JSF2.0.
je suis confus au sujet de quand les gens choisissent d'aller avec des alternatives de sécurité comme Shiro, Spring Security ou l'ESAPI d'owasp laissant derrière la sécurité gérée de conteneur. Après avoir vu certains de questions connexes sur Stack Overflow, où j'ai réalisé que la sécurité basée sur les conteneurs était plus préférée par les développeurs JSF dans le passé. Mais il m'a également été fortement recommandé D'utiliser Apache Shiro. Je suis novice en ce qui concerne les questions de sécurité et n'ont aucune idée de ce qui pourrait être les questions pertinentes et comment les traiter. Par conséquent, je suis à la recherche de quelque chose qui gère la plupart des problèmes de sécurité à travers ses paramètres par défaut/ sur son propre.
en ce qui concerne mes exigences d'application, j'ai une application sociale où les utilisateurs avec des rôles différents ont accès à différents ensembles de pages et peuvent utiliser différents niveaux de fonctionnalité sur ces pages en fonction de leurs rôles.
Dans ce cas que pensez-vous pourrait être une bonne option pour moi pour aller avec ?
personnellement, j'ai été convaincu d'opter Shiro, car il est facile à utiliser et prend en charge la plupart des choses pour les débutants.
3 réponses
Je ne sais exactement rien d'Apache Shiro excepté comme suit, mais ce que vous avez cité vient pratiquement mot à mot de leur page Web, qui contient plusieurs déclarations erronées telles que "[JAAS] required static definitions that only programmers could change", et "JAAS is tied too heavily tied to virtual machine-level concerns", et l'implication que JAAS ne concerne pas les utilisateurs et les rôles, ce qui est tout simplement faux. Je voudrais beaucoup de convaincre de s'éloigner du container de sécurité gérés. Il fait partie de la spécification Servlet, donc il doit être supporté par n'importe quel conteneur; il est bien compris; il est supporté par les classes JDK sans aucune tierce partie; ... et ça marche pour moi ;-)
ce que J'aime à propos de Shiro c'est qu'il est vraiment facile de configurer la sécurité basée sur la permission. JAAS est fortement basé sur les rôles, ce qui est une granularité qui ironiquement est plus utile pour les applications Web grand public que pour les applications d'entreprise (comme nous pouvons le remarquer à partir de vos exigences).
il est courant pour un serveur d'application de fournir certains services en plus de JAAS, comme une seule connexion, construit en loginmodules, etc, donc parfois quand la granularité de permission n'est pas une exigence, vous devriez aller pour JAAS.
la dernière fois que J'ai vérifié Shiro ne supportait pas non plus l'authentification mutuelle ssl (en utilisant des certificats numériques), mais vous ne l'utiliseriez probablement pas...
si vous utilisez Shiro votre application sera probablement plus portable entre les serveurs d'application / Conteneurs servlet (oh, l'ironie!), comme la configuration de sécurité JavaEE tend à être spécifique au fournisseur pour la plupart des configurations non triviales.
dans l'Ensemble, basé sur la exigences que vous avez spécifiées:
- utilisant un Applserver (GlassFish, JBoss): JAAS (ootb authc/ authz, built-in loginmodules)
- utilisation D'un conteneur Servlet (Jetty / Tomcat): Shiro (plus facile à configurer et à utiliser)
Espérons que cela aide :)
J'ai décidé que SpringSecurity (SS) sera notre cadre D'authentification et D'autorisation. Principalement parce que SS Fait OpenID et OAuth. Je vais devoir le personnaliser pour le système permissions/group/user / entity un peu. Je prévois de faire l'autorisation au niveau 'EntityManager / Entity', au niveau du Service, et au niveau du Web/API. "Verrouillez la porte, mais ayez vos bijoux dans un coffre de 3 tonnes dans la salle de derrière" beaucoup de la dernière moitié des poignées Shiro beaucoup mieux. Mais je ne suis pas tombé comme essayer d'intégrer openid4j/openauth4j dans Shiro est confortable.
il serait vraiment agréable de choisir et de choisir les caractéristiques des deux, sans aucune interférence ou code bloat. C'est le meilleur choix.
PS, le Printemps apporte beaucoup d'autres choses, à la plaque, aussi, comme l'intégration avec JSF, donc il a beaucoup de recours.