access denied aux applications apres connexion a un compte utilisateur

[Alexandre GALIBERT]

Bonjour,

Je suis actuellement en phase de déploiement de ma plate-forme geOrchestra sur un serveur web public depuis hier. En voulant tester le fonctionnement des applications, je tombe sur l'erreur suivante après m'être connecté à un compte utilisateur avec la connexion du CAS :

HTTP Status 403 - Access is denied
type Status report
message Access is denied
description Access to the specified resource (Access is denied) has been forbidden.

Cela me le fait après avoir cliqué sur le bouton pour soumettre ma connexion. Il me redirige vers l'URL suivante : http://archiseine.sisyphe.jussieu.fr:8080/mapfishapp/?login, où j'ai l'erreur 403.

J'ai regardé au niveau des logs, et j'ai relevé l'erreur suivante dans le log journalier de localhost dans le dossier logs de tomcat6 :

SEVERE: Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
    at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
    at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
    at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:316)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:149)
    at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:386)
    at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:450)
    at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1397)
    at org.apache.jasper.compiler.Parser.parse(Parser.java:130)
    at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255)
    at org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
    at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:185)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
    at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:438)
    at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
    at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
    at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:421)
    at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:342)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Thread.java:679)
Mar 7, 2014 11:17:34 AM org.apache.catalina.core.StandardHostValve custom
SEVERE: Exception Processing ErrorPage[errorCode=403, location=/403.jsp]
org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
    at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
    at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
    at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:316)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:149)
    at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:386)
    at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:450)
    at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1397)
    at org.apache.jasper.compiler.Parser.parse(Parser.java:130)
    at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255)
    at org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
    at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:185)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
    at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:438)
    at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
    at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
    at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:421)
    at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:342)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Thread.java:679)

La version de geOrchestra que j'utilise est la 13.09. Pour l'instant je cherche mais je n'ai pas encore trouvé de solution. Je ne pense pas que cela vienne d'une application puisque j'ai appliqué la même configuration par rapport à la version que j'avais mise en place pendant la phase de développement.

Cordialement

Alexandre GALIBERT

[Pierre Mauduit]

Bonjour,

> HTTP Status 403 - Access is denied
> type Status report
> message Access is denied
> description Access to the specified resource (Access is denied) has been
> forbidden.

Vous confirmez que vous êtes bien connecté au CAS malgré tout ? (i.e. lorsque
vous allez sur https://.../cas/login, vous avez bien un "connexion réussie").

Si c'est le cas, je verrais plutot un problème coté ldap, ou configuration du
security-proxy, où les groupes ne sont pas résolus correctement / ajoutés aux
en-têtes http vers les applications protégées au niveau du proxy.

> J'ai regardé au niveau des logs, et j'ai relevé l'erreur suivante dans le log
> journalier de localhost dans le dossier logs de tomcat6 :
>
> SEVERE: Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/
> jstl/core cannot be resolved in either web.xml or the jar files deployed with
> this application
> at org.apache.jasper.compiler.DefaultErrorHandler.jspError

[...]

> La version de geOrchestra que j'utilise est la 13.09. Pour l'instant je cherche
> mais je n'ai pas encore trouvé de solution. Je ne pense pas que cela vienne
> d'une application puisque j'ai appliqué la même configuration par rapport à la
> version que j'avais mise en place pendant la phase de développement.

Je ne pense pas que l'erreur que vous avez jointe soit liée à votre problème,
mais difficile à dire sans avoir une meilleure connaissance de votre
déploiement. Par ailleurs, je ne me rappelle pas avoir eu une erreur de ce type
de mon coté.

Cordialement,

--
Pierre

[Florent Gravin]

Bonjour,

Avec quel user vous connectez vous ?

Si votre user ne fait pas parti de groupes LDAP, au moins SV_USER, alors vous aurez un 403.

--
--
projet: http://www.georchestra.org/

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes georchestra-dev.

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra-d...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/d/optout .

--
Florent Gravin
Camptocamp - Chambéry
0479444492

[Alexandre GALIBERT]

Bonjour,

J'ai revérifié au niveau de l'URL cas/login, mais je me suis trompé dans mon premier message en allant un peu trop vite, car il me redemande d'entrer les identifiants de connexion. Ce qui veut dire que l'authentification ne  fonctionne pas correctement

J'ai le message suivant dans les logs dans /tmp/cas-web-server.log :
AuthenticationManagerImpl [INFO] AuthenticationHandler: org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler successfully authenticated the user which provided the following credentials: [username: agalibert]

qui montre qu'il arrive bien à interroger le LDAP. J'ai regardé aussi au niveau des utilisateurs, mais il n'y a pas de problème particulier. J'avais déjà testé de me logger avec un autre compte utilisateur, mais j'avais aussi rencontré le même problème d'erreur 403.

Cordialement.

[Pierre Mauduit]

Bonjour,

> La question que je pose avant de procéder à une modification au niveau du
> système est la suivante :
> Est-ce que la version de Java utilisée (Oracle JAVA vs OpenJDK) peut avoir une
> importance sur les fonctionnement des applications dans deux environnements
> Tomcat différents ?

Je pense que oui: la différence notable que j'ai pu observer, c'était de tenter
d'ouvrir des keystores / truststores avec des versions de keytool provenant de
jdk différentes, la compatibilité n'était pas assurée entre openjdk et oracle.

--
Pierre

[Alexandre GALIBERT]

Bonsoir,

Le problème a finalement été résolu dans la journée. Il y avait deux erreurs qui étaient à l'origine du problème :

• Le site est sur un serveur virtuel, ce qui veut dire que toutes les connexions entrantes passent obligatoirement par la machine physique. Et l'adresse IP de cette machine ne figurait pas sur la liste des hôtes dits de confiance dans la configuration du proxy-servlet
• Certaines informations erronées dans l'annuaire LDAP posait des problèmes au proxy. Dans les groupes traînaient des entrées avec fakeuser comme valeur de membre. Ce qui faisait qu'au moment de la vérification des droits il trouvait un utilisateur connecté qui n'avait aucun rôle.

Ces erreurs sont dues à mon inexpérience en matière d'administration système/réseau et à des fausses manipulation de ma part.

[François Van Der Biest]

2014-03-13 17:10 GMT+01:00 Alexandre GALIBERT <galibert....@gmail.com>:

Bonsoir,

Le problème a finalement été résolu dans la journée. Il y avait deux erreurs qui étaient à l'origine du problème :

• Le site est sur un serveur virtuel, ce qui veut dire que toutes les connexions entrantes passent obligatoirement par la machine physique. Et l'adresse IP de cette machine ne figurait pas sur la liste des hôtes dits de confiance dans la configuration du proxy-servlet

 Est-ce que tu parles de ça ?

https://github.com/georchestra/georchestra/commit/5e86ee4a939ff16a4fc9a8b93ecb9286c772286c#diff-fa9eb6ecbe3dd5245985d4eaa1dab3e8L337

• Certaines informations erronées dans l'annuaire LDAP posait des problèmes au proxy. Dans les groupes traînaient des entrées avec fakeuser comme valeur de membre. Ce qui faisait qu'au moment de la vérification des droits il trouvait un utilisateur connecté qui n'avait aucun rôle.

Compris: vous avez dû récupérer la version du LDAP qui correspond à la version 14.01 de georchestra (qui contient effectivement des fakeuser pour une bonne raison), alors que votre georchestra est en 13.09.

Notre faute: il n'y a pas de branche 13.09 ni de tag adapté dans le dépôt LDAP.

 

Ces erreurs sont dues à mon inexpérience en matière d'administration système/réseau et à des fausses manipulation de ma part

On est fautifs aussi !

On va améliorer ça: https://github.com/georchestra/georchestra/issues/615

F. 

[Alexandre GALIBERT]

Bonjour,

Mon problème n'est pas entièrement résolu, car je n'arrive pas à accéder aux modules d'administration dans GeoServer et GeoNetwork lorsque je suis connecté. Dans GeoNetwork, il me renvoie vers la page de login interne à l'application, ce qui signifie qu'il y a eu redirection depuis la page accessDenied.jsp. Ce qui se confirme car dans les logs l'utilisateur qu'il retrouve est l'utilisateur anonyme alors que je me suis pourtant bien connecté avec le CAS !


Le problème est similaire dans GeoServer, puisqu'il m'affiche par exemple lorsque je veux créer un nouvel entrepôt le texte suivant :
"Désolé, votre session a expiré ... Il semble que vous avez été inactif depuis trop longtemps par rapport à votre dernière action. Si cela n'est pas le cas, contacter votre administrateur."

Pour l'instant je cherche depuis vendredi mais je n'ai pas trouvé de solution résolvant ces deux problèmes. Je vous envoie les logs que j'ai obtenu.

Cordialement

Alexandre GALIBERT

[philippe marty]

Bonjour,

J'essaye de reprendre là où Alexandre s'est arrêté (fin de contrat ...).

Sa dernière question n'a pas eu de réponse ; le problème est toujours là et nous n'en trouvons pas la raison ... Toute aide serait bienvenue ;-)

Merci par avance

Bien cordialement,

Philippe Marty

[François Van Der Biest]

Bonjour,

Les logs fournis n'étant pas très parlants, nous n'avons pas été en
mesure d'aider Alexandre ...
Il semblerait qu'il y ait un pb de communication entre cas et proxy
car, si vous êtes connectés sur le cas, le proxy n'a pas l'air de le
savoir ...

Idée: passez les logs du proxy et du cas en mode DEBUG et nous les envoyer.
Préciser également le setup choisi (nb de tomcats, config du proxy ->
fichier tomcat/webapps/ROOT/WEB-INF/proxy-servlet.xml), configuration
des connecteurs tomcat etc

A+
F.

> --
> --
> projet: http://www.georchestra.org/
>
> ---
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> "georchestra-dev".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> georchestra-d...@googlegroups.com.
>

> Pour obtenir davantage d'options, consultez la page
> https://groups.google.com/d/optout.

[philippe marty]

Bonjour François,

merci de la réponse rapide.

On Monday, November 24, 2014 4:40:05 PM UTC+1, François Van Der Biest wrote:

Il semblerait qu'il y ait un pb de communication entre cas et proxy
car, si vous êtes connectés sur le cas, le proxy n'a pas l'air de le
savoir ...

j'ajouterai que le résultat semble être une redirection brutale vers lap age d'accueil de "SERVICES" ; ce qui est curieux c'est le moment où cette redirection se fait : on a le temps de naviguer dans le menu (on va dans security/U,G,R puis on clique sur

XML User Group Service default) puis on choisit le mode "digest" pour password encryption (car un msg en accueil nous dit de le faire) et c'est au moment de ce choix dans la scrollbox que la redirection se fait ...

 

Idée: passez les logs du proxy et du cas en mode DEBUG et nous les envoyer.
Préciser également le setup choisi (nb de tomcats, config du proxy ->
fichier tomcat/webapps/ROOT/WEB-INF/proxy-servlet.xml), configuration
des connecteurs tomcat etc

arg, désolé, mais je suis vraiment perdu avec tomcat et je ne sais même pas répondre à ces demandes là ... si vous avez le temps, serait-il possible d'avoir des commandlines en shell (ou au moins le path approximatif de chaque fichier concerné) à exécuter pour que je puisse vous envoyer ces infos ?

et que conclure du ticket 615 dont vous parliez plus haut ? savez vous si Alexandre a implémenté ce qu'il faut depuis ? si non, que dois-je faire ? vos derniers échanges ne sont pas clairs à ce sujet : est-ce que le pb actuel pourrait s'expliquer par le pb de ldap résolu dans ce ticket ?

grand grand merci,

@+

Philippe

[François Van Der Biest]

Bonsoir,

2014-11-25 17:10 GMT+01:00 philippe marty <pb.m...@gmail.com>:
> arg, désolé, mais je suis vraiment perdu avec tomcat et je ne sais même pas
> répondre à ces demandes là ... si vous avez le temps, serait-il possible
> d'avoir des commandlines en shell (ou au moins le path approximatif de
> chaque fichier concerné) à exécuter pour que je puisse vous envoyer ces
> infos ?

Je crains que dans ce cas, nous ne puissions pas beaucoup vous aider.
Il faudrait tenter de ré-embaucher Alexandre ;-)

> et que conclure du ticket 615 dont vous parliez plus haut ?

https://github.com/georchestra/georchestra/issues/615 a été clos :
plusieurs branches ont été créées pour le LDAP, une pour chaque
version de geOrchestra.

> savez vous si
> Alexandre a implémenté ce qu'il faut depuis ?

Je pense que vous êtes mieux placé que moi pour répondre à cette question ;-)

> vos derniers échanges ne sont pas clairs à ce sujet : est-ce que le pb
> actuel pourrait s'expliquer par le pb de ldap résolu dans ce ticket ?

Peu probable, mais il vaudrait mieux avoir la main complète sur le
système pour diagnostiquer ça.

Cordialement,
F.

[philippe marty]

On Tuesday, November 25, 2014 10:07:07 PM UTC+1, François Van Der Biest wrote:

Je crains que dans ce cas, nous ne puissions pas beaucoup vous aider.
Il faudrait tenter de ré-embaucher Alexandre ;-)

hélas ... no comment quant aux précaires ... moi je suis titulaire, tomcat c'est pas ma compétence mais j'essaye d'aider en best effort ... bientôt y aura plus de titulaire et donc que des boulots pas fini par les précaires ... voire plus de boulot du tout s'il y a pas de titulaire pour embaucher les précaires ;-)
 

> et que conclure du ticket 615 dont vous parliez plus haut ?

https://github.com/georchestra/georchestra/issues/615 a été clos :
plusieurs branches ont été créées pour le LDAP, une pour chaque
version de geOrchestra.

> savez vous si
> Alexandre a implémenté ce qu'il faut depuis ?

Je pense que vous êtes mieux placé que moi pour répondre à cette question ;-)

ben non ... je connais ldap, mais dans le projet archiseine, je ne sais pas à quoi doit ressembler le schéma ... y a-t-il un test simple que je puisse faire pour savoir si mes branches sont dans un état avant ou après résolution du ticket 615 ?
 

> vos derniers échanges ne sont pas clairs à ce sujet : est-ce que le pb
> actuel pourrait s'expliquer par le pb de ldap résolu dans ce ticket ?

Peu probable, mais il vaudrait mieux avoir la main complète sur le
système pour diagnostiquer ça.

ça peut peut être s'organiser en live ou à distance si vous avez un peu de temps ...

à part ça, j'ai trouvé 14 fichiers de logs différents qui ont l'air de concerner apache, tomcat, georchestra ...

et j'en ai identifiés 9 comme contenant de nouvelles entrées suite au clic sur le menu qui plante : dans "geoserver [services] > sidebar > security > U,G,R > default XML u/g s > passwords encryption > listbox" : n'importe quel choix dans la liste fait immédiatement revenir à la racine de "geoserver [services]" sans même laisser le temps de cliquer sur "save".

les 9 fichiers de logs qui enregistrent qqch au moment de ce clic (diff entre juste avant et juste après le clic) sont assez obscurs et disparates : on y trouve une erreur de "credential" (mais pourquoi cette erreur n'arrive pas plus tôt et laisse aller aussi loin dans les menus ?), une erreur de table postgres, de la logorhée java, etc.

je peux vous envoyer les 60Ko que cela représente sur votre mail perso (je préfère ne pas poster publiquement) ...

any help still greatly appreciated ;-)

merci !

Phil