Précédent   Forum du club des développeurs et IT Pro > Java > Développement Web en Java > Servlets/JSP
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse
 
Outils de la discussion
Publicité
'
Vieux 02/08/2012, 14h26   #1
cameraman
Futur Membre du Club
 
Homme
Architecte de système d'information
Inscription : 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 : 18
Points : 18
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.
cameraman est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 06/08/2012, 09h12   #2
DevServlet
Modérateur
 
Homme
Ingénieur développement logiciels
Inscription : juin 2007
Messages : 2 738
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 738
Points : 3 500
Points : 3 500
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?
DevServlet est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 29/08/2012, 10h57   #3
cameraman
Futur Membre du Club
 
Homme
Architecte de système d'information
Inscription : 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 : 18
Points : 18
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
cameraman est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 29/08/2012, 13h23   #4
DevServlet
Modérateur
 
Homme
Ingénieur développement logiciels
Inscription : juin 2007
Messages : 2 738
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 738
Points : 3 500
Points : 3 500
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...
DevServlet est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 29/08/2012, 15h06   #5
cameraman
Futur Membre du Club
 
Homme
Architecte de système d'information
Inscription : 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 : 18
Points : 18
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 :
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 :
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.
cameraman est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 29/08/2012, 15h29   #6
DevServlet
Modérateur
 
Homme
Ingénieur développement logiciels
Inscription : juin 2007
Messages : 2 738
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 738
Points : 3 500
Points : 3 500
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.
DevServlet est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 30/08/2012, 15h07   #7
cameraman
Futur Membre du Club
 
Homme
Architecte de système d'information
Inscription : 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 : 18
Points : 18
Bonjour et merci pour ta réponse, je vais explorer ces pistes.
cameraman est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 02/01/2013, 14h55   #8
cameraman
Futur Membre du Club
 
Homme
Architecte de système d'information
Inscription : 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 : 18
Points : 18
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 :
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
cameraman est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse
Outils de la discussion

Navigation rapide


Fuseau horaire GMT +2. Il est actuellement 13h17.


 
 
 
 
Partenaires

Hébergement Web