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

Servlets/JSP Java Discussion :

Servlet authentifié qui appelle d'autres servlets


Sujet :

Servlets/JSP Java

  1. #1
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2012
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2012
    Messages : 12
    Points : 19
    Points
    19
    Par défaut Servlet authentifié qui appelle d'autres servlets
    Bonjour à tous,

    je rencontre un problème avec un de mes servlets. En effet, celui ci est juste un point d'entrée. Son retour déclaré est en HTML, mais la génération se fait via l'appel en URL de 2 autres servlets: l'un renvoie un XML, l'autre une feuille de style XSL. La fusion XSLT de ces éléments donne le résultat du servlet principal.

    Ce système fonctionne très bien sans authentification. Mais pour des raisons internes on m'a demandé de rajouter une authentification forte via un LDAP.

    J'ai donc mis en place la sécurité JAAS de J2EE et là ça ne marche plus du tout. L'authentification pour accéder au servlet principal fonctionne parfaitement, mais lorsque celui ci tente d'accéder aux URLS des 2 sous-servlet, il reçoit évidemment des HTTP401 UNAUTHORIZED.

    Je ne sais pas comment le contourner. Est-il possible de désactiver JAAS si l'émetteur de la requête est localhost, ou de retransmettre aux sous-URL l'authentification du servlet principal ?

    Merci d'avance pour vos contributions.

  2. #2
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 938
    Points : 3 938
    Points
    3 938
    Par défaut
    Citation Envoyé par cameraman Voir le message
    Bonjour à tous,

    je rencontre un problème avec un de mes servlets. En effet, celui ci est juste un point d'entrée. Son retour déclaré est en HTML, mais la génération se fait via l'appel en URL de 2 autres servlets: l'un renvoie un XML, l'autre une feuille de style XSL. La fusion XSLT de ces éléments donne le résultat du servlet principal.

    Ce système fonctionne très bien sans authentification. Mais pour des raisons internes on m'a demandé de rajouter une authentification forte via un LDAP.

    J'ai donc mis en place la sécurité JAAS de J2EE et là ça ne marche plus du tout. L'authentification pour accéder au servlet principal fonctionne parfaitement, mais lorsque celui ci tente d'accéder aux URLS des 2 sous-servlet, il reçoit évidemment des HTTP401 UNAUTHORIZED.

    Je ne sais pas comment le contourner. Est-il possible de désactiver JAAS si l'émetteur de la requête est localhost, ou de retransmettre aux sous-URL l'authentification du servlet principal ?

    Merci d'avance pour vos contributions.
    Bonjour, moi je vois un pb de conception dans tes echanges, une servlet n'est normalement pas censée en appeler une autre, mais répondre à une requête HTTP. et pour ce faire elle peut très bien s'appuyer sur des classes métier ou classe controleur pour exécuter ces tâches. Alors dans ton cas, à moins que je n'aie pas tout saisi, pourquoi les classes générant du XML et du XSL sont des servlets? ces classes peuvent faire le même boulot pour lequel tu les sollicites sans être des servlets non?
    Vous avez peut être hâte de réussir et il n'y a rien de mal à cela...
    mais la patience est aussi une vertu; l'échec vous l'enseignera certainement..."

  3. #3
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2012
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2012
    Messages : 12
    Points : 19
    Points
    19
    Par défaut
    Bonjour DevServlet,

    merci pour ta réponse. Désolé de ne pas avoir répondu plus tôt mais je suis rentré de congés hier.

    Concernant l'architecture de ce projet, je l'ai retenu initialement car j'ai des servlets qui génèrent des XML, et ces XML peuvent être exploités sous différentes formes.

    Lorsque ce sont des autres logiciels qui appellent en HTTP, ils reçoivent le résultat sous forme de XML. Mais on peut également consulter certaines informations via un navigateur. Dans ce cas, la même URL est appelée, mais plusieurs feuilles de style XSL peuvent être appliquées pour donner plusieurs zooms différents sur les infos.
    Maintenant tu n'as pas tort, ce sont des classes métiers qui sont derrière cette génération XML, donc je pourrais les appeler directement, mais en faisant comme ça je suis sur que tous les appels génèrent le même résultat, quelle que soit la mise en forme finale.

    L'autre raison qui m'a fait retenir cette architecture est que mes XSL contiennent des directives include avec des références relatives au chemin courant. Hors la fusion XSLT ne fonctionne qu'en mode URL dans ce cas. Mais sur ce point là, je peux éventuellement me débrouiller avec une petite bidouille.

    Je me demande si on ne peut pas implémenter une authentification via un filtre. Dans ce cas, je désactiverais la sécurité si l'URL est demandée depuis le localhost ? Est-ce possible ?
    Si non, alors il faudra effectivement que je casse la structure de l'application, mais ce sera la dernière option

  4. #4
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 938
    Points : 3 938
    Points
    3 938
    Par défaut
    Citation Envoyé par cameraman Voir le message
    Je me demande si on ne peut pas implémenter une authentification via un filtre. Dans ce cas, je désactiverais la sécurité si l'URL est demandée depuis le localhost ? Est-ce possible ?
    Bonjour, puis je savoir ce que tu entends par une auth. par filtre?
    Mais c'est très facile de connaitre l'ip appelante d'une servlet, si c'est ta question...
    Vous avez peut être hâte de réussir et il n'y a rien de mal à cela...
    mais la patience est aussi une vertu; l'échec vous l'enseignera certainement..."

  5. #5
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2012
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2012
    Messages : 12
    Points : 19
    Points
    19
    Par défaut
    Pour ce qui est de la récupération d'IP, l'applicatif dont il est question peut justement formater les informations différemment selon un paramétrage qui prend en compte entre autres des plages d'IP des appelants, donc pas de souci de ce coté là. J'ai ce qu'il faut pour récupérer l'IP autant dans les filtres que les servlets.

    Ce qui me mène à ma question sur les filtres. Je sais que l’authentification sur CAS Server peut se faire via des filtres inclus dans l'appli J2EE. Mais nous ne souhaitons pas utiliser CAS, qui n'est pas vraiment adapté à ce que nous utilisons.
    Je préférerais utiliser une authentification JAAS, mais pas en la déclarant dans le web.xml comme c'est le cas actuellement:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
     
     <security-constraint>
      <web-resource-collection>
       <web-resource-name>all</web-resource-name>
       <url-pattern>/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
       <role-name>administrator</role-name>
       <role-name>companion</role-name>
      </auth-constraint>
     </security-constraint>
     <login-config>
      <auth-method>DIGEST</auth-method>
      <realm-name>monrealmamoi</realm-name>
     </login-config>
    L'idée serait de mettre en place un filtre applicatif, affectant /*, mais avec un débrayage en cas d'appel localhost. La déclaration donnerait un truc du genre:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    <filter>
      <filter-name>JAASAuthFilter</filter-name>
      <display-name>JAAS authentication filter</display-name>
      <filter-class>xxx.yyy.JAASAuthFilter</filter-class>
      <init-param>
       <param-name>localhostexcluded</param-name>
       <param-value>true</param-value>
       <description>Si true, les requêtes émanant du localhost ne seront pas authentifiées</description>
      </init-param>
     </filter>
    Je ne sais pas si un tel filtre existe, ou si on peut l'écrire soi-même.

  6. #6
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 938
    Points : 3 938
    Points
    3 938
    Par défaut
    Ah ok, j'ai mieux compris ta demande. En fait tu peux très bien coder une servletFilter par laquelle par laquelle passeront toutes tes requêtes. Et dans cette classe Filter tu testes l'ip et authentifies avant de répondre à la requête. Un exemple ici. Après y'a aussi Spring-security que tu peux paramétrer pour le faire automatiquement.
    Vous avez peut être hâte de réussir et il n'y a rien de mal à cela...
    mais la patience est aussi une vertu; l'échec vous l'enseignera certainement..."

  7. #7
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2012
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2012
    Messages : 12
    Points : 19
    Points
    19
    Par défaut
    Bonjour et merci pour ta réponse, je vais explorer ces pistes.

  8. #8
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2012
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2012
    Messages : 12
    Points : 19
    Points
    19
    Par défaut Problème résolu
    bonjour à tous,

    finalement après bien des galères j'ai fini par trouver une solution. Il faut en fait récupérer la liste des cookies du premier servlet, retrouver celui qui contient le jsessionid, et le repasser dans la requête d'appel du second servlet. Ce qui nous donne un truc du genre

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
     
    URL myAccess = new URL(url);
    HttpURLConnection connection = (HttpURLConnection)myAccess.openConnection();
    String cookie = req.getHeader("Cookie");
    if ((cookie == null) ||cookie.equals(""))
    {
    	System.out.println("@@@ Manually built cookie @@@");
    	cookie = "JSESSIONID=" + req.getSession().getId();
    }
     
    connection.setRequestProperty("Cookie", cookie);
     
    if (connection.getResponseCode() == 200) // 200 = OK, 401 = unauthorized
    {
    	InputStream is = connection.getInputStream();
    	// use inputstream here
    }
    Sur mon serveur (Weblogic) j'ai du également mettre certaines informations dans le weblogic.xml pour que ça fonctionne au déploiement. Je ne sais pas s'il faut également faire des trucs spécifiques pour les autres serveurs d'appli.

    Merci encore à ceux qui ont consacré un peu de temps à cette file.

    Et bonne année 2013 à tous

Discussions similaires

  1. Servlet appelant une autre servlet
    Par nix01 dans le forum Servlets/JSP
    Réponses: 1
    Dernier message: 04/07/2009, 08h48
  2. servlet qui appelle un autre
    Par pazaroti dans le forum Servlets/JSP
    Réponses: 5
    Dernier message: 29/05/2007, 16h01
  3. servlet qui appelle une autre
    Par kam81 dans le forum Servlets/JSP
    Réponses: 7
    Dernier message: 06/11/2006, 16h14
  4. [Debutant] Formulaire qui appel un autre formulaire
    Par anassyto dans le forum Access
    Réponses: 6
    Dernier message: 31/07/2006, 12h10
  5. Procedures stockées qui appellent un autre ?
    Par Tchinkatchuk dans le forum PostgreSQL
    Réponses: 4
    Dernier message: 09/05/2005, 09h30

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