Authentification Sécurité avec GWT : Sécuriser les servlets

Bonjour,

je suis actuellement à la recherche d'une solution de sécurisation d'un appli GWT.
CE qui est sur, c'est que je veux utiliser seulement GWT (pas d'ACEGI / Spring Security, etc...)

Comme base j'ai cet article de Google (un tantinet laconique) :
http://code.google.com/p/google-web-...ginSecurityFAQ

En premier, est ce que quel qu'un peut m'indiquer comment se traduit en code cette phrase :

Citation:

---

Your server will then validate this login, and return a sessionID to your GWT app. The GWT app will store this sessionID in a static field. For every further request your GWT app makes to your server, include this sessionID in the payload of the request. (Either in the JSON data or the object you are transferring using GWT-RPC).

---

Je suppose que je mets l'Id de session dans l'appController au lancement et ensuite je fais quoi? Je le mets en paramètre de chaque appel GWTrpc?

Sinon je pensais faire une "SecurityServlet" côté serveur qui vérifie si il y a le paramètre "sessionId" dans la session et qui le compare avec le sessionId actuel.

Vous avez des idées?

Si tu n'as rien d'autre que GWT je ferais.

1 - l'utilisateur se connecte à l'appli, il récupère donc le html qui n'a pas de sessionId et qui va donc afficher l'écran de login.
2 - il se log, côté serveur tu vérifie que son login / MDP sont correcte, tu génère un sessionId et tu le renvois en réponse et que tu garde côté serveur.
3 - Côté client tu stocke le sessionId en cookie. le cookie est transmis à chaque requete. Côté serveur tu dois pouvoir le récupérer pour vérifier à chaque appel si ton user est bien connecté.

Cas d'exception :
Si l'appel Rpc à un sessionId incorrect, tu renvoie une exception. Côté GWt si tu récupère l'exception tu affiche la page de login.

J'ai un souci du coup, je ne peux pas partager de données dans la session avec GWT.

Je me suis inspiré de cet article :
http://developerlife.com/tutorials/?p=230

dont la méthode :

Code:

---

1 2 3 4 5 6 7 8 9 10

/**          * Returns the current session          * @return The current Session          */ private HttpSession getSession() { // Get the current request and then return its session HttpServletRequest httpServletRequest = getThreadLocalRequest(); HttpSession session = httpServletRequest.getSession(); return session; }

---

mais le httpServletRequest.getSession(); me renvoie un null pointer exception la deuxième fois que je l'utilise.

Avec une servlet classique ça devrait être facile mais avec les remoteServiceSevlet de Google, impossible de trouver un moyen correct de procéder.

Tu peux créer un filtre Http sur tes appels Rpc.

Il sera appelé avant la méthode Gwt.

Un exemple ici : http://www.berthou.com/fr/2009/01/11...tion-dune-jsp/

Le mécanisme est le même avec des services Rpc.

oui mais je ne vois pas trop l'intérêt dans mon cas.
Idéalement, j'aimerais ne pas avoir à stocker les infos dans une variables statique mais bien dans la session.
Si je fais un filtre je suis obligé de passer par un tableau d'info statique.

Au contraire, je pense que c'est la seule manière de réaliser une authentification.

Avec ton filtre tu auras accès à la session Http. Il faut stocker les variables d'authentification dans la session Http. Ensuite, tu peux utiliser un ThreadLocal pour "envoyer" un identifiant vers le service Rpc.

J'ai déjà pensé aux filtres, le problème que j'ai rencontré c'est que les filtres ne fonctionnent pas avec les tags (page.html#toto) et ne permet pas d'exclure certaines urls. Du coup je vais me retrouver à faire une page login.jsp à part. Je pourrais le faire mais pour l'instant je cherche une alternative qui soit dans la même sorte que GWT.

Citation:

---

Envoyé par kenji_getpowered

les filtres ne fonctionnent pas avec les tags (page.html#toto).

---

C'est une ancre (ou anchor en anglais)

--

Si tu veux pas te prendre la tête avec des filtre Http (qui reste pour moi la meilleur soltution car non intrusive à l'appli) tu peux mettre en place un système intrusif qui va demander sur chaque appel Rpc une variable qui contiendra le sessionId. C'est pas tres propre mais ca marchera. C'est d'ailleur l'exemple de Google sur le premier lien que tu donnes ("Creating a 'login' page")

Justement ils ne donnent pas d'exemple. Ils mentionnent une méthode mais ça en reste la. Chez moi j'ai un Null Pointer Exception sur ce que renvoie le getThreadLocalRequest. Si tu as un exemple, je suis preneur car j'ai vraiment cherché un peu partout.
Je me demande si les sessions sont actives avec le plugin GWT for eclipse. Je ne vois plus ou chercher...:cry::cry:

Les filtres HTTP sont simples mais j'ai pas trouvé comment m'en servir avec GWT sans faire du bricolage (jsp externe, double filtre, etc...)

J'ai déjà donné cet exemple sur le forum, si tu ne l'as pas vu il y a une partie de l'explication dans cet article : http://ultrafil.tuxfamily.org/index....te-applicative

Tu peux voir que j'ai utiliser un filtre http sur l'url pattern /*.

Dans mon exemple j'utilise un WebSSO que tu dois remplacer par un écran de login.

Tu peux donc faire ton url-mapping uniquement sur tes services Rpc.

--

Disons que tu souhaite utiliser la méthode intrusive (sans filtre http)

Dans ce cas c'est très simple. Tu fais un écran de login. Le serveur valide et renvoie un sessionId que tu stock en cache côté client avec un champ static.
Ensuite toutes tes autres requetes Rpc vont prendre en argument ce sessionId que tu vérifie côté serveur.

C'est pas très élégant mais tu peux commencer comme ca si vraiment tu es perdu.

T'as besoin d'un exemple pour faire ca ?

J'ai vu ton article la dessus. Cela me semblait plus simple de partir avec le partage de donnée par session. mais je vais peut être y revenir :)

Code:

---

Ensuite toutes tes autres requetes Rpc vont prendre en argument ce sessionId que tu vérifie côté serveur.

---

Coté serveur, il va se baser sur quoi? Je pensais passer par une variable de session mais j'ai un null pointer exception dès que j'essaie de la récupérer

méthode commune aux 2 servlets :

Code:

---

1 2 3 4 5 6 7 8 9

/**          * Returns the current session          * @return The current Session          */   private HttpSession getSession() { // Get the current request and then return its session return this.getThreadLocalRequest().getSession(true); }

---

Dans la permière servlet, pas de souci tout est bien enregistré. Dans la 2ème j'ai un null pointer exception getThreadLocalRequest()

Tu utilise quoi pour dispatcher tes requetes ?

perso j'utilisais http://code.google.com/p/gwtrpc-spring/ et j'ai remarqué que la session n'est pas utilisable dans le service Rpc. je pense que c'est un bug.

Je n'ai jamais essayé directement avec GWT mais je ne serais pas étonné que ca fonctionne.

Sinon en attendant de trouver comment utiliser la session tu peux toujours utiliser une variable static côté serveur. C'est pas génial mais ca marche.

Tu te fais une HashMap que tu rempli au fur et a mesure et que tu n'oublie pas de vider de temps en temps. C'est ce que fais le serveur avec la session en fait mais là tu dois te retaper le mécanisme à la main.

Je vais essayer ce soir et je te dirais demain si j'ai trouvé une solution élégante à ton prob.

Je n'utilise pas de point d'entrée coté serveur. On y a pensé mais on a peu de servlet GWT donc on a pas senti le besoin d'en mettre un.

On attaque les servlet directement comme indiqué dans l'exemple.

J'ai pensé à la variable statique et j'ai testé. je vais peut t être m'orienter vers cela en attendant mais je préfèrerais utiliser une autre technique. Je vais tester le filtre mais sans AOP. En plus on a des servlet classiques donc ce serait éventuellement une bonne solution. Je fais ça demain... la je craque :aie::aie:

pour passer le sessionId dans un requete vers le service GWT j'ai trouvé ce code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

// start with a custom RpcRequestBuilder RpcRequestBuilder reqBuilder = new RpcRequestBuilder() { @Override protected RequestBuilder doCreate(String serviceEntryPoint) { RequestBuilder rb = super.doCreate(serviceEntryPoint); rb.setHeader("username", "sookie_stackhouse"); return rb; } };   // as with any other RPC, use GWT.create(...) to generate the client proxy MyServiceAsync service = (MyServiceAsync) GWT.create(MyService.class);   // all client proxies also implement ServiceDefTarget ((ServiceDefTarget) service).setRpcRequestBuilder(reqBuilder);   // make calls as normal service.doFunAndInterestingThings();

---

http://stuffthathappens.com/blog/200...-with-gwt-rpc/

J'ai installé un filtre qui parse tous les appels vers les servlet sauf pour celle du login et du logon

Code:

---

1 2 3 4 5 6 7 8 9 10

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // place your code here HttpSession session = ((HttpServletRequest) request).getSession();   String login = (String) session.getAttribute("login"); logger.debug("doFilter - Login=" + login);   chain.doFilter(request, response); }

---

avec 2 pages jsp (login + logon) et la page gwt appli.html

Je filtre en utilisant ce filtre

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

<filter> <filter-name>SecurityFilter</filter-name> <filter-class>com.package.filters.SecurityFilter</filter-class> </filter> <filter-mapping> <filter-name>SecurityFilter</filter-name> <url-pattern>/appli*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>SecurityFilter</filter-name> <url-pattern>/appli.html</url-pattern> </filter-mapping>

---

les servlets ont un point d'accès genre /appli/service sauf les login et logon qui sont en /acces/login et /access/logon. La page gwt est soumise au filtre de sécurité aussi mais pas les pages login.jsp et logon.jsp

J'ai quand même le souci du partage de données en session car je n'arrive pas à accéder à la session en cours dans un RemoteServiceServlet.
Comme j'ai sorti la page de login de GWT je ne peux pas mettre d'id coté client.

Je me répons à moi même:

Lorsque l'on veut accéder à la session en cours avec un RemoteServiceServlet il y a un petit point à prendre en compte :

Il faut attendre que le 1er objet RemoteServiceServlet soir constuit avant de pouvoir accéder au getThreadLocalRequest() sinon vous obtiendrez un Null Pointer Exception.

Ce qui pourrait vous induire en erreur :
- SI vous avez déjà fait un appel à un RemoteServiceServlet alors vous pourrez faire appel au getThreadLocalRequest() dans le constructeur d'une 2ème servlet.
- Même si vous avez déjà initialisé une session à l'aide par exemple (dans mon cas) d'une servlet classique (donc vous avez un sessionId et x paramètre(s)) vous obtiendrez un Null Pointer Exception si vous tentez d'accéder au getThreadLocalRequest() dans le constructeur du 1er appel d'une RemoteServiceServlet.

En espérant que cela aide d'autres personnes.

Du coup, maintenant j'ai ma solution de sécurité pour GWT. Toute remarque est bienvenue.

Salut kenji,

désolé je n'ai pas eu le temps de regarder chez moi ton prob.

Je suis content que tu ai trouvé une solution.

Avec ta solution tu es obligé d'utiliser ton requestBuilder à chaque appel Rpc ?

Merci pour ton aide tout de même. Ca fait plaisir de pas se sentir tout seul ;)

J'utilise pas le RequestBuilder. Je mettais ça car je n'avais aucune idée de comment envoyer des infos dans le payload de la requête et la j'ai trouvé.

Peux-tu donner le mécanisme de sécurité que tu as choisi et qui fonctionne maintenant ?

Ca en aidera d'autres comme ca.

C'est ce que j'ai décrit plus haut (avec 2 jsp et la page gwt etc..)

J'aimerai bien voir le code de ta servlet si c'est possible car jamais eu de problème de session chez moi avec GWT et le mode RPC. Cela marche plutôt bien.

Bien entendu, il faut bien comprendre comment marchent les servlets pour éviter le genre de problèmes que tu évoques.
En résumé, dans les servlets :
Eviter les variables d'instances (pb de synchro en env. multithread) et les constructeurs (c'est ton conteneur qui gère et pas toi)

C'est simple, je reprend le code du projet Contact disponible sur l'aide de GWT (Building Large Application)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public ContactsServiceImpl() { getThreadLocalRequest().getSession().getAttribute("toto"); initContacts(); } private void initContacts() { // TODO: Create a real UID for each contact // for (int i = 0; i < contactsFirstNameData.length && i < contactsLastNameData.length && i < contactsEmailData.length; ++i) { Contact contact = new Contact(String.valueOf(i), contactsFirstNameData[i], contactsLastNameData[i], contactsEmailData[i]); contacts.put(contact.getId(), contact); } }

---

Cela va planter si c'est le premier appel à une RemoteServiceServlet.

Quand je regarde ce code, je comprend le null pointer exception.

Résumons le pourquoi :

• Google nous impose d'hériter d'une servlet technique pour implémenter un service RPC. On utilise donc les signatures de méthodes de notre service et non les classiques doGet/doPost.
• On perd donc l'accès à HttpServletRequest et HttpServletResponse or ceci est embétant car on peut en avoir besoin pour faire plein de chose, accéder à la session en autre (même si c'est à éviter pour du stateless), ...
• Il fallait qu'ils trouvent un moyen pour nous filer une référence dessus. Ils ont éviter d'utiliser la première idée qui vient au débutant : les variables d'instances car si la servlet est utilisée par plusieurs threads simultanément, ça ne vas pas le faire. Ils stockent donc ces objets dans un espace mémoire du thread courant pour qu'on puisse y accéder par la suite.
• Il est fort possible que le constructeur soit appelé la 1° fois avant que la 1° requête n'ait été mise dans cet espace mémoire d'où le null pointer.

Intriqué par la source de ton exemple (la ligne en rouge ne sert à rien), j'ai télécharger le code source à
http://code.google.com/webtoolkit/do.../Contacts2.zip
et cette ligne n'y est pas !

L'essentiel de cette histoire, c'est de retenir :
On ne gère pas le cycle de vie des servlets, c'est le conteneur qui s'en occupe. Est-ce que le conteneur crée la servlet au démarrage ou à la première requête ? et que se passe t'il s'il la partage entre plusieurs thread ?

Dans les servlets, mon conseil : ne pas toucher au constructeurs, ni utiliser de variable d'instance sauf si on sait ce qu'on fait.

C'est normal que tu ne la trouve pas, c'est moi qui l'ai ajoutée pour te montrer le cas.
J'ai pris comme exemple leur code car je me suis basé dessus pour l'architecture du projet (MVP, rpc etc..). Ils traitent du code dans le constructeur, je me suis donc basé su ce qu'ils font sauf que j'avais besoin d'une info en plus.

Pour ce qui est du stateless. Tellement pratique, perso, je n'ai mis que le login. :D

Ce qui est étonnant, c'est que quand on appelle une servlet classique en premier. la deuxième partage le même id de session donc instinctivement je me suis dit qu'ils partageaient le même thread. Et bien ça plante quand même.

A+

En tout cas sinon, comment gères tu l'affichage en fonction de l'utilisateur connecté?

Par exemple le projet exemple de Google "Contact" propose un service avec une liste de Contact mais comment faire si cette liste est personnalisé en fonction de l'utilisateur connecté?

En effet, le service créé une hashmap de tout les utilisateurs du coup comment faire pour la limiter? revenir vers la BDD à chaque fois et recharger la liste?
Parceque la variable est d'instance :/

Code:

---

private final HashMap<String, Contact> contacts = new HashMap<String, Contact>();

---

Une application se résume en gros à faire transiter des flux de données entre le repository choisi (base de données, fichiers, ... sur le serveur) et l'interface graphique (ihm cliente).

Si pour des raisons de performance, on souhaite les mettre en "cache", on peut intervenir à différents niveaux avec des avantages/inconvénients.
côté client : cookies, cache du navigateur, modèle objet javascript
côté serveur : modèle objet java, session, fichiers/bdd

Sans entrer dans le détail de chacune de ces solutions, disons que :
soit on utilise une session (côté serveur ou côté client) : état à gérer avec le problème de l'expiration, actualisation des données
soit on échange les données à chaque fois (pas de session) : pas d'état à gérer mais trafic supplémentaire.
Il n'y a pas de secret : ce qu'on gagne en temps (avec des caches), on le perd en espace et vice versa ... Il faut trouver le bon compromis pour une situation donnée.

Pour des données communes à plusieurs utilisateurs, tu peux les stocker dans le modèle objet de ton application.
Si c'est des données propres à chaque utilisateur, soit tu vas les rechercher en bdd à chaque fois, soit tu essayes d'en stocker côté client (dans le modèle objet javascript), soit tu en stockes dans la session http côté serveur.

Et si je préfère une application stateless pour une application à millions d'utilisateurs, pour une application à seulement quelques dizaines d'utilisateur (< 100), je pense que la session http côté serveur répond à ce besoin.

L'intégration d'un conteneur EJB avec une gestion stateful peut aussi permettre de gérer les sessions pour les users. A savoir que le stateful renverra des infos sur la partie cliente en cas d'une demande d'une ressource ou alors enregistrera une session lors de la première connections.

Le souci est comme tu le définis de savoir ce que l'on veut faire. De la performance pure ou alors une gestions précise de la gestion des sessions (Stateful).

Qu'en pensez vous ?

Bonjour,

Je développe actuellement une application GWT (client GWT + RPC et servlet TOMCAT)

Je souhaite avoir une architecture stateless, c'est à dire :
1) l'utilisateur se connecte à l'application => je vérifie son pasword dans la servlet
2) ensuite je stocke des informations contextuelles dans un objet javascript (mais je n'utilise pas de numéro de session) que je passe à chaque appel de mes servlet en utilisant le mécanisme RPC. Je ne fais donc ensuite aucun contrôle de connection dans mes servlet.

Je voudrais savoir si il existe une faille de sécurité dans ce type d'architecture ?

Merci

Les deux limites que j'imagine :

1) Si un "pirate" arrive à deviner ou à capturer le code qui transite à chaque fois pourrait se faire passer pour ton utilisateur.
Cela est très proche du vol d'identifiant de session bien que peut être moins devinable, moins formalisé. Et s'il ne faut pas compter sur l'obfuscation comme élément de sécurité, le vol d'identifiant de session n'est pas le plus répandu et utilise pas mal l'ignorance des utilisateurs.

2) L'autre risque (mais c'est également un avantage suivant le point de vue) c'est que tant qu'il n'y a pas de mécanisme d'expiration de session et tant que le navigateur est ouvert, on peut exécuter des actions personnelles. Ceci n'est pas bien gênant tant que l'utilisateur ne surfe pas dans un cybercafé en laissant le navigateur ouvert.

Whaou !

ça c de la réactivité !

Merci pour ces explications très claire !

Bonjour,

Pour moi c'est un risque de sécurité. La Servlet doit impérativement vérifier l'utilisateur à chaque appel.

Mes applications sont en state-less, j'utilise le websso pour l'authentification. L'id que le sso envoie à ma servlet me permet de vérifier l'authentification avec l'utilisateur qui se trouve dans ma base de donnée. pour améliorer les performance j'utilise la session uniquement pour éviter de faire une requete en BDD à chaque appel rpc en y stockant les info de l'utilisateur.

J'ai donc une session utilisé uniquement pour des raisons de perf. Mais tous le fonctionnel de l'appli reste en state-less.

pvoncken, tu vérifies avec ta session.
Pour retrouver ta session, un identifiant de session est échangé entre client et serveur .

Si son objet qu'il transmet joue le même rôle (avec plus d'information cependant), s'il n'est pas devinable/modifiable bien entendu, je ne vois pas en quoi ça serait plus risqué ?

Cela dépend plus de ce que représente son objet javascript et si les données qu'il véhicule sont compréhensible.


Pour en revenir à ton histoire de session, as tu des mesures de différences de performance (par curiosité) car tu perds un avantage du staleless selon moi. L'intérêt du stateless, c'est de pouvoir être load balancé sur n'importe quel serveur mais si ta session ne s'y trouve pas, cela va lui redemander de s'authentifier, n'est ce pas.
Je peux comprendre l'utilisation de session (toutes les appli n'ont pas une charge énorme), je peux imaginer que la différence de performances soit significative. En revanche, je ne comprends pas bien l'intérêt d'un "tout stateless" sauf pour l'authentification. Quelque chose à du m'échapper ... Peux tu m'éclairer ?

Avec la couche websso, je ne pense pas que cela revienne au meme avec un objet géré à la main. Le WebSSO garantie l'authentification avec des mécanismes de sécurisation du token de session.

Au niveau du tout stateless sauf l'authent, c'est par rapport à mon contexte. Je reste au maximum stateless pour pouvoir me soumettre facilement à du load balancing. Il n'y a que l'authent avec lequel j'utilise la session car on a une api déjà toute faite qui récupère les infos du websso et qui les stocks en session.

Par contre le jour où j'ai besoin de faire du load-balancing, je n'aurais que la couche d'authent à modifier.

Pour le load-balancing on peut également choisir la stratégie du sticky qui permet de balancer les requetes sur un serveur en fonction du token de session. Cette stratégie me permettrait de ne même pas modifier mon authent. Stratégie que tu ne pourra pas mettre en place si tu utilise autre chose que le token standard de session.

De plus, Le state-less permet également de sécuriser la persistance en évitant de perdre des infos qui serait en session.

Merci pour tes précisions. Ton point de vue se défend.

Pour ma part, si ton approche est plus "standard", "éprouvé", ... je pense néanmoins que l'échange d'un objet identifiant l'utilisateur (pour peu qu'il soit bien fait) n'est pas un risque énorme et apporte l'avantage qui est une application full stateless qui n'expire pas tant que le navigateur n'est pas fermé.

Je concède néanmoins que cela peut être un inconvénient pour d'autres points de vues.