Discussion :

[AlienQueen]

Bonjour à tous,

Sur mon projet Tomcat / Spring / Spring MVC, on m'a demandé d'implémenter le besoin suivant :

***
Quand l'utilisateur arrive sur la page de garde, il faut contrôler qu'il est bien authentifié et si ce n'est pas le cas lui renvoyer la page que l'on renverrait normalement sauf que tous ses liens pointent vers une page d'erreur.

S'il est authentifié, on lui renvoie une page normale avec des liens lui permettant de naviguer dans notre webapp.

La page de garde est le seul endroit où nous avons besoin de faire cette vérification d'identité, pour diverses raisons. Nous employons une annotation marqueur afin de dire à l'intercepteur que le contrôleur de la page de garde doit faire l'objet de cette vérification.
***

J'ai codé tout cela avec un intercepteur Tomcat en mode "quick & clean" (si si !) mais nous voudrions comparer avec l'AOP puisque nous avons une classe unique (celle du contrôleur de la page de garde) pour laquelle nous voudrions injecter du code de vérification avant son exécution. Voici les avantages et inconvénients que nous voyons aux deux solutions (avant codage de la solution avec AOP) :

- un intercepteur est quelque chose d'assez standard, alors que l'AOP n'est actuellement pas utilisée dans le projet.

- Il est un peu dommage d'avoir un test à chaque requête disant si la vérification d'identité doit être faite ou non (solution de l'intercepteur) alors que nous n'avons qu'une classe pour laquelle elle est pertinente.

- Pour ce que je comprends de l'AOP, le seul moment où notre code de vérification sera appelé sera celui que nous définissons, il n'y aura donc pas de test à chaque requête définissant si nous avons besoin de procéder à la vérification.

Qu'en pensez-vous ? Quelqu'un a-t-il des choses à rajouter ou enlever ? En particulier, ma perception de l'implémentation Spring de l'AOP est-elle juste ?

Merci de vos lumières !

[bugsan]

L'aop n'est pas fait à proprement parlé pour gérer la sécurité d'une application.

Tu devrais t'orienter d'avantage vers Spring Security. Son principe est d'identifier/authentifier un utilisateur, de récupérer ses autorisations, et d'en construire un context de sécurité (stocké dans un ThreadLocale).

La façon d'identifier, authentifier, autoriser... tu es libre d'implémenter tout ca. Mais bien sûr il offre les mécanismes répendus : un javax.servlet.Filter pour les identifications par le Web (http BASIC, cookie de session...), des DAO pour la gestion des roles, des encrypteurs de mot de passe, etc...

Ensuite, pour sécuriser les appels métier, on peut effectivement utiliser des intercepteurs AOP (SecurityInterceptor). Qui vont vérifier la présence du SecurityContext et des autorisations ...
Tu peux par exemple n'autoriser que les méthodes de lecture d'un service.

[AlienQueen]

Je pense que mon besoin est différent. Notre webapp fonctionne entièrement en HTTPS avec authentification mutuelle. L'identification dont je parle consiste juste, pour un utilisateur déjà authentifié, à vérifier qu'il a bien droit à accéder à une certaine partie de l'appli. Et comme cette vérification doit avoir lieu à un seul endroit, nous cherchions une solution légère.

De plus, au niveau "politique", je ne pense pas qu'on m'autorisera à introduire Acegi juste pour cela.

[OButterlin]

Je ne vois pas trop le lien entre l'AOP et ton problème qui semble être plus lié à l'IHM qu'autre chose...
J'ai peut-être raté quelque chose, mais s'il s'agit de tester l'autorisation pour une fonctionnalité présente dans l'IHM, je pense qu'un TagLib serait plus adapté.

A+