Bonnes ID ~ Clément Oudot

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - apache

Fil des billets

mardi, février 19 2013

LemonLDAP::NG 1.2.3 : Soleil !

Le 8 février dernier est sortie la version 1.2.3 de LemonLDAP::NG. Prévue à l'origine pour n'être qu'une version corrective de la branche 1.2, de nombreux bugs et améliorations ont été inclus dans cette version, ce qui explique sa sortie tardive (6 mois après la version 1.2.2). Panorama de ces changements.

logo_lemonldap-ng.png

Les signatures SAML au cœur du cyclone

En décembre, une alerte de sécurité a été diffusée concernant le traitement des signatures SAML dans LemonLDAP::NG (CVE-2012-6426), problème corrigé dès le 18 décembre sur le SVN du projet.

Concrètement, la vérification des signatures était désactivée par défaut lors de la réception des messages et la fonction chargée de vérifier ensuite la signature n'était pas effective (mauvais appel de fonction de la librairie Lasso).

Si vous travaillez donc avec le protocole SAML dans une version inférieur à 1.2.3, la mise à jour est chaleureusement conseillée pour revenir à une situation au beau fixe.

Cette version apporte de plus certaines améliorations sur SAML, comme le support des NameID transient, un meilleur log des échanges SAML et la compatibilité de l'IDP SAML avec une authentification CAS.

Soleil Orage Averse Pluie

Le support de SOAP a été amélioré :

Le ciel est tombé sur l'en-tête X-Forwarded-For

Jusqu'ici, la gestion de l'en-tête X-Forwarded-For n'était pas évident. Cette en-tête est gérée par les proxys et permet de connaître l'adresse IP d'origine d'une requête HTTP, donc l'IP du client.

Avant la version 1.2.1, l'activation de la gestion de cette en-tête inscrivait l'IP dans une variable spécifique de la session ($xForwardedForIpAddr), laissant l'IP standard dans la variable $ipAddr. Hors, même s'il est possible d'utiliser la variable $xForwardedForIpAddr dans des règles, dans d'autres endroits du code, $ipAddr est forcément utilisé (par exemple dans les logs, ou dans les modèles HTML des mails envoyés).

Cette gestion a été revue, désormais si l'option X-Forwarded-For est activée dans LemonLDAP::NG, alors la variable de session $ipAddr prendra cette valeur, ce qui s'appliquera donc à toutes les fonctions utilisant cette variable.

De plus, depuis la version 1.2.3, pour éviter que la valeur de cette en-tête soit modifiée manuellement par les utilisateurs, une règle de sécurité est apparue pour n'accepter cette en-tête que depuis certaines IP (en l'occurrence les adresses IP des proxys s'ils existent).

Accalmie sur les rejeux de formulaire

Les rejeux de formulaire sont une fonctionnalité assez marginale, permettant de transformer des requêtes GET en POST, utilisant comme données POST des informations de la session de l'utilisateur. En utilisant la fonction de sauvegarde du mot de passe en session, cela permet donc de faire du SSO sur des applications mal écrites propriétaires.

Plusieurs bugs ont été corrigés pour rendre cette fonction plus opérationnelle :

Toutefois, cette fonctionnalité reste assez peu avancée, et il est préférable d'utiliser les modes standards de SSO (en-tête HTTP, CAS, SAML, ...).

Séance d'UV pour le portail

Le portail est la partie visible de LemonLDAP::NG, là où les utilisateurs s'authentifient, changent leur mot de passe et voient les applications auxquelles ils sont accès.

Comme le physique c'est important, la version 1.2.3 apporte deux nouveautés dans ce domaine :

D'hiver

D'autres améliorations diverses ont été faites :

Après la pluie

À présent que vous êtes convaincus qu'il faut absolument installer cette nouvelle version, courrez la télécharger, ou mettez à jour via vos distributions préférées !

L'équipe du projet LemonLDAP::NG travaille déjà sur la version 1.3. N'hésitez pas à venir nous prêter main forte !

vendredi, mars 16 2012

Configuration Apache : du bon usage de RedirectMatch et de mod_proxy

La configuration d'un serveur HTTP d'Apache est une source d'occupation sans limite tellement les possibilités d'utilisation sont nombreuses. Ma casquette de développeur et intégrateur LemonLDAP::NG m'amène souvent à les explorer.

Dernière découverte en date, l'utilisation conjointe de RedirectMatch et mod_proxy.

RedirectMatch

La clause RedirectMatch permet de faire des redirections basées sur une expression régulière. Le cas d'utilisation le plus classique quand on fait un proxy vers une application hébergée dans un serveur JEE est de rediriger la racine / vers le répertoire de l'application /appli/ :

RedirectMatch ^/$ /appli/

mod_proxy

Le module mod_proxy permet de passer les requêtes à un autre serveur, au hasard un serveur JEE :

ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/

Cohabitation

Si vous mettez les deux configurations présentées ci-dessus ensemble, la redirection vers /appli/ ne fonctionnera plus. Alors qu'elle fonctionne sans mod_proxy.

Et c'est parti pour quelques heures de doute sur la condition humaine, jusqu'à ce qu'une recherche sur internet vous amène sur cet article.

La clé du mystère est que quand ProxyPass est configuré sur "/", cette clause prévaut sur les autres, et donc la requête est transmise avant que la redirection ne soit effectuée.

La solution est donc de limiter le champ d'action du proxy :

RedirectMatch ^/$ /appli/
ProxyPass /appli/ http://localhost:8080/appli/
ProxyPassReverse /appli/ http://localhost:8080/appli/

En espérant que cela vous fera gagner du temps ;)