Vulture on Zwindler's Reflection

Vulture 3 en bêta test

Mon, 07 Sep 2015 20:59:58 +0000

Rappel

Pour rappel pour ceux qui n’auraient pas suivis, Vulture WebSSO est un WAF (non pas pour Wife Acceptance Factor mais Web Application Firewall) que je suis avec intérêt depuis la version 1.98 car il m’a permis pendant un certain temps de gérer dans une même console web l’ensemble de mes applications auto-hébergées.

Il permet également de gérer l’authentification, le SSO, un portail, la réécriture d’URL et de contenu … le tout à l’aide d’Apache, de modules et de code Perl maison.

Vulture 2.0.X

Ce n’est pas très frais comme news, mais la version 2.0.8 de Vulture WebSSO marque la fin de la « branche » 2.Y.X.

On sait depuis le 30 septembre dernier que la V3 est en cours de développement.

Les prémisses de Vulture 3.0

Depuis, les choix techniques ont été présentés sur le blog du projet, avec depuis des mentions de support de SPDY et de HTTP/2. Entre ça et le portage de mod_spdy sous FreeBSD et Apache 2.4, autant dire qu’Advens laisse du temps libre aux développeurs de Vulture ;-).

Et depuis aout, vous avez la possibilité de vous manifester pour bêta-tester Vulture 3 en envoyant un mail à beta-test@vultureproject.org

Avis aux amateurs donc, si vous voulez gouter au futur du projet Vulture et donner un coup de main, c’est maintenant ou jamais !

Bonus track

Advens met gentiment sur son blog une explication de HTTP/2 (lien mort, Internet Archive ne l’a pas). Merci à eux

Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN

Tue, 30 Dec 2014 13:48:52 +0000

Erreur de génération de conf Apache (ProxyPass) dans Vulture 2.0.8

Depuis la version 2.0.4 de Vulture, il est possible de présenter plusieurs « applications » (comprenez application web) sur un même FQDN, en les différenciant via leur URL complète.

C’est notamment utile dans le cas de l’utilisation de PNP intégré à shinken. Vous présentez la webui sur le WAN via https://shinken.example.org/, et les graphiques PNP sur https://shinken.example.org/pnp4nagios. Vous avez ainsi tout qui fonctionne comme en local dans un seul et même FQDN. Cette mise en place a fait l’objet d’un précédent article

Cependant, en plus d’apporter des fonctionnalités très appréciables, la mise à jour en 2.0.8 a apporté son lots de petits tracas supplémentaires sur mon installation, notamment pour Shinken (voir ici)

Je n’avais pas encore remarqué immédiatement, mais il y a eu également une régression de Vulture au niveau de la fonctionnalité dont je parle au début. Je ne pouvais plus accéder à mes graphes PNP4nagios dans Shinken.
En fait, après avoir analysé les logs, je me suis rendu compte que toutes les requêtes, et en particulier celles pour PNP, était redirigées vers Shinken, provoquant inévitablement un code retour 404 ([Edit]403 en fait[/Edit]).

Après avoir cherché à différents endroits, j’ai fini par remarquer que le problème vient en fait de la génération de la configuration Apache par Vulture en version 2.0.8. Contrairement aux versions précédentes, les directives ProxyPass ne sont pas ordonnées correctement.

Voici à quoi ressemble la configuration dans l’exemple suivant :

<VirtualHost 0.0.0.0:443>
ServerName appli.example.org
[...]
<Location />
[...]
</Location>
ProxyPass / http://@IP_privee:port_appli1/
[...]
ProxyPass /appli2/ http://@IP_privee:port_appli2/appli2
<location /appli2/ >
ProxyPassReverse /
[...]
</location>

La documentation Apache indique qu’il faut placer la directive ProxyPass avec l’URL la plus stricte/longue en premier, ce qui n’est pas le cas ici (Section encadrée « Ordre de classement des directives ProxyPass » dans Doc Apache de mod_proxy).

Cela implique donc que toutes les requêtes sont redirigées sur Shinken. CQFD.

En attendant un patch, vous pouvez manuellement déplacer la seconde directive ProxyPass au dessus de la première et redémarrer Vulture.
Ca m’a permis de contourner le problème et de retrouver mes graphes dans Shinken. Cependant, ce contournement ne survivra pas à la prochaine génération de la configuration en cas de modification depuis l’interface web Vulture.

Vulture 2.0.8 : des nouveautés et des impacts sur la WEBUI de Shinken

Fri, 25 Jul 2014 14:14:08 +0000

Fin mai, la version 2.0.8 est sortie et a apporté un lot impressionnant de fonctionnalités supplémentaires (ainsi que quelques bugfixes d’usages)… ainsi que quelques petites surprises pour ma configuration, et notamment pour publier la WebUI de Shinken au travers de Vulture.

Mais le jeu en vaut largement la chandelle, regardez plutôt …

Réécriture de la documentation

OMG ! Vulture dispose ENFIN d’une documentation (relativement complète) pour CHAQUE page de l’interface d’administration. Cela permet de remettre au clair les passages qui n’avaient pas été bien compris lors de mes premières installs et corriger quelques erreurs dues au manque d’information sur les versions précédentes.

A noter, si vous commencez, il faut aller sur ces deux pages, avant de lire la doc en entier, pour ne pas être perdu :

Refonte intégrale du packaging

Refonte intégrale du packaging : Vulture s’installe désormais simplement avec 3 paquets

ENFIN bis ! Et ça fonctionne bien, fini les galères pour installer les dépendances. Par contre la liste des distribs gérées se limite à sont plus simple appareil : CentOS 6.5 et Debian 7.

Mise à jour automatique des configurations

Bon… ça, ça fait un moment qu’on nous le promet, et j’ai du faire une fausse manipulation certainement car comme d’habitude… j’ai tout perdu… Si vous avez des retours positifs, je suis preneur ;)

Support d’une URL par défaut dans les interfaces

En voilà une bonne idée ! Cependant, j’ai eu à l’inverse la mauvaise idée d’en indiquer une pour mon interface, alors que cette appli/URL n’existait pas, et je me suis retrouvé avec de gros soucis sur mon portail, qui ne marchait tout simplement plus.

J’avais des erreurs au niveau des logs des applications, avec des messages d’erreurs faisant état d’une application inconnue depuis le fichier Core::AuthzHandler.

Je le re-testerai une autre fois, pour voir, mais je me demande s’il ne manque peut être des contrôles vu que c’est une nouvelle fonctionnalité. Si vous n’en avez pas besoin, je vous conseille de ne pas l’utiliser.

Plugins – Transhandler

Suite à l’installation de la 2.0.8 de Vulture, je n’arrivais plus à faire fonctionner la WebUI de Shinken. J’arrivais à avoir la mire d’authentification, mais pas les images et le CSS.

Après dépilage des logs, j’ai fini par remarquer que les connexions faisant appels au CSS et aux images (de type static/*) se retrouvaient redirigés sur le serveur où est installé Vulture, et pas sur le serveur Shinken où elles sont situées.

Après vérification, j’ai trouvé avec étonnement que le plugin TransHandler STATIC static/* livré par défaut lors de l’install était appliqué à toute mes applis, alors que cette règle n’est normalement appliqué à AUCUNE application (paramètre positionné à None)**. [Edit] En fait selon l’équipe de Vulture, c’est normal, quand on a la colonne « Application » à « None », ça signifie que ça s’applique à toutes les applications [/Edit]
**

La documentation fait bien état de ce plugin, qui sert effectivement à mettre en local sur le serveur qui héberge Vulture toutes les ressources statiques (ici).

J’ai désactivé ce plugin, et tout est rentré dans l’ordre. [Edit] Il semblerait que cela soit plus compliqué que cela. Ce contournement provoque notamment des effets de bord sur le portail. J’ai ouvert un thread sur le google group de vulture à ce sujet.[/Edit]

Will not rewrite (Rewrite Content) this content-type: application/json

Une fois Shinken de nouveau disponible, ce n’était pas terminé pour autant. Visiblement, depuis la 2.0.8 (peut être avant mais je n’ai pas remarqué en 2.0.4), le plugin de réécriture de contenu de la page à la volée Rewrite Content ne prend plus en charge l’ensemble des contenus par défaut. Cela se traduit par une page web qui n’est simplement pas réécrite (on retrouve les URL privée de PNP dans la page Shinken) et par le message suivant dans le fichier de log

Le log est plutôt explicite, et la doc aussi (vultureproject.org/documentation/configuration/configuration-des-applications-web/composants-plugins/reecriture-de-contenu/) !

Vulture ne pourra altérer que les contenus dont le content-type est l’un des suivants (il est cependant trivial d’en ajouter d’autres, contacter l’équipe de développement pour signaler un type non géré)

Les types sont les suivants :

text/xml
text/html
application/vnd.ogc.wms_xml
text/css
application/x-javascript

J’ai donc signalé ce manque à l’équipe mais en attendant qu’ils publient un patch, vous pouvez simplement ajouter dans l’expression régulière application/json et text/javascript ligne 138 du fichier /opt/vulture/lib/Vulture/Plugin/Plugin_OutputFilterHandler.pm

diff /opt/vulture/lib/Vulture/Plugin/Plugin_OutputFilterHandler.pm*
138c138
< if ($r->content_type ne '' and $r->content_type !~ /(text/xml|text/html|application/vnd.ogc.wms_xml|text/css|application/x-javascript|text/plain|application/json|text/javascript)/){
---
> if ($r->content_type ne '' and $r->content_type !~ /(text/xml|text/html|application/vnd.ogc.wms_xml|text/css|application/x-javascript|text/plain)/){

[En bref] Sortie de Vulture 2.0.6

Thu, 22 Aug 2013 19:38:28 +0000

Sortie de Vulture 2.0.6

Dans le genre news pas très fraîche, je voudrais la sortie Vulture 2.0.6, vieille d’environ 2 mois… Sortie de Vulture 2.0.6

Le changelog fait état de la correction de 3 bugs et l’ajout de quelques petites features sympa. Je ne sais pas si c’est les mises à jours des dépendances (ou les modifications de celles ci?), mais j’avais plusieurs comportements étranges sur mes vulture (Debian et CentOS de test) qui semblent aujourd’hui être de l’histoire ancienne!

Comme d’habitude avec Vulture, mise à jour = suppression de la base de données. Vous aurez donc tous vos paramétrages à refaire, mais personnellement, je trouve que le jeu en vaut la chandelle dans ce cas précis.

Sachez aussi que normalement cela devrait être la dernière fois si l’on en croit la doc d’install de Vulture.

A tester la prochaine fois, j’ai hâte de ne plus avoir besoin de tout refaire à chaque fois !

Activation de django-evolution

Depuis la version 2.0.6, il est possible d’activer l’application django-evolution sur vulture, qui permettra une mise à jour de la base de données lors des mises à jour.

Afin de l’utiliser, il faut d’abord l’installer:

easy_install -U django_evolution

N’hésitez pas à remonter à la dev-list toutes les anomalies que vous pourriez rencontrer. Ils sont assez réactifs.

MàJ : Publier sur le WAN la WebUI de Shinken via Vulture (2.0.4+)

Sat, 17 Nov 2012 17:45:15 +0000

Vulture et Shinken, encore

Petit update de l’article Publier sur le WAN la WebUI de Shinken via Vulture

Depuis la mise à jour de vulture en 2.0.4, il est possible d’avoir des virtuals hosts, qui évitent ainsi le besoin d’avoir deux URLs distinctes du point de vue FQDN pour la WebUI et pour pnp4nagios.

On se retrouve donc avec deux applications comme suit :

Shinken - shinken.vulture.fr - http://@IP_shinken:7767
Shinken pnp4nagios - shinken.vulture.fr/pnp4nagios - http://@IP_shinken/pnp4nagios

ATTENTION : Le « / » à la fin de pnp4nagios dans l’URL privée est très important

Pensez à modifier vos filtres de réécriture d’URL à la volée pour qu’il pointe bien vers cette URL.

C’est beaucoup plus propre avec un FQDN unique

Petite note additionnelle : Attention pour ceux qui sont en 2.0.X avant 2.0.3, la mise à jour doit se faire par un réinstallation. Pour éviter de devoir tout refaire à la main, l’idéal est de désinstaller vulture en ayant préalablement copié la base de données, d’installer la nouvelle version, puis de mettre manuellement à jour la base de données.

La partie « export/import » de la configuration dans vulture fait planter vulture si la base a changé de version entre l’export et l’import (car la base de données n’est pas identiques). Tout sera planté ;-)

Publier sur le WAN la WebUI de Shinken via Vulture

Sun, 21 Oct 2012 19:13:14 +0000

Ceux d’entre vous qui me suivent savent déjà que je suis de manière avide tous les développements du projet Shinken, un outil de supervision compatible avec Nagios, mais qui apporte des fonctionnalités de haute dispo et de vue business bien supérieures à ce qu’on peut faire simplement avec Nagios. Depuis quelques temps, les développeurs de Shinken ont beaucoup bossé sur une interface plus épurée et pourtant plus puissante que celle de Nagios (voire même Centreon pour certaines idées) en HTML 5.

Dans les débuts de cette interface, j’ai eu le plus grand mal à la faire passer au travers de mon web proxy applicatif personnel (Vulture). Aujourd’hui, avec la stabilisation du code de la WebUI de Shinken et aussi une meilleure compréhension des mécaniques de vulture, j’ai réussi à la faire passer sur Internet et je peux donc consulter à tout instant l’état de mon infra perso, ce qui, vous en conviendrez, est une nécessité absolue.

Mais trêves de bavardages. La première chose que je tiens à dire, c’est que cet articule ne couvrira pas l’installation de Shinken, pour la bonne et simple raison que j’ai horreur d’écrire des articles quand des blogs/forum/wiki existent déjà pour dire la même chose. Pour rappel :

Si vous souhaitez installer Shinken, vous n’avez qu’à exécuter la commande suivante :

Page de download de Shinken (lien mort, remplacé par Internet Archive)

Pour configurer Shinken

10 Minute Shinken Installation Guide (lien mort, remplacé par Internet Archive)

Passons maintenant aux choses sérieuses. Dans un premier temps, vous avez installé et configuré Shinken, il fonctionne, et vous pouvez ouvrir votre WebUI en local

Le dashboard classique de l’outil de supervision de base. C’est la moins sexy des vues de Shinken mais je reste un peu vieux jeu

Maintenant, tout se passe côté Vulture. Je pars du principe que vous disposer d’un nom de domaine (on n’a qu’à prendre vulture.fr, au hasard), et que vous avez mappé les adresses suivantes sur l’IP depuis votre domaine vers votre serveur vulture

portal.vulture.fr
shinken.vulture.fr
pnp.vulture.fr

Vous l’aurez certainement deviné, la première sert au portail et est rattaché à la définition de l’interface vulture. Tout arrivera sur cette interface (pour ceux qui en ont plusieurs, pour les autres qui n’en ont qu’une, c’est évident). Cependant pour les deux autres, vous pouvez remarquer que j’ai été obligé d’utiliser deux noms différents pour ma WebUI (au moins dans un premier temps, en attendant de trouver une meilleure façon de faire). Et pour cause…
Malheureusement, la WebUI utilise un composant python qui génère du code HTML 5 à la volée, en écoute sur le port 7767. Cependant, pour compléter un peu la vue des services et notament pour ce qui est des perfdata, l’équipe de Shinken à pris le parti de réutiliser le travail de pnp4nagios, qui est intégré directement dans l’interface. Or, pnp4nagios est un composant web tout ce qu’il y a de plus basique, qui tourne dans un apache sur le pour 80 (ou n’importe quelle autre port, on s’en fiche, juste pas le 7767).

Du coup, vu de vulture, j’ai été contrains à créer deux applications, et donc à leur donner deux noms distincts. C’est là la partie qu’il reste à améliorer. Il est surement possible de faire mieux, pour l’instant je n’ai pas trouvé…

Une fois nos deux applications définies dans vulture, il reste encore un petite opération pour que le tout fonctionne. A l’heure actuelle, le code de Shinken à la facheuse tentance à générer des liens et à rediriger automatiquement vers des pages via des URLs absolues… du type http://@IP_locale/webui. En local, votre navigateur saura résoudre cette IP privée, mais pas sur Internet. C’est pourquoi nous allons demander à vulture de réécrire tous les contenus qui posent problèmes à la volée. Pour cela il faut aller dans le menu « Plugin de réécriture de contenu ». Il faudra transformer toutes les requêtes qui sont en HTTP en local en HTTPS derrière vulture, et transformer les URL pnp pour qu’elles pointent vers la bonne application.

Shinken crache des liens HTTP simple toutes les 30 secondes, ce qui est fâcheux quand votre vulture écoute sur du HTTPS

la webui génère de moches adresses IP locales que vulture n’ose pas modifier sans notre accord explicite

Une fois ces étapes réalisées, vous devriez pouvoir afficher la webui derrière votre vulture comme si vous étiez en local. Reste donc à accepter les certificats autosigner, à s’authentifier dans la WebUI PUIS dans pnp4nagios, et le tour est joué. Et comme vulture est un SSO en plus d’être un firewall applicatif, il sera aussi possible de bypasser ces deux authentifications, mais ceci fera l’objet d’un article ultérieur (quand j’aurai pris le temps de comprendre comment ça fonctionne)

Quand Vulture 2.0 planne au dessus de la carcasse d’un Lenny et de son fidèle Mediawiki

Tue, 01 Nov 2011 17:03:35 +0000

Peut être que vous connaissez Vulture, mais peut être pas. Pour ceux d’entre vous qui ne se sont jamais vraiment posé la question de la sécurité pour les contenus web que vous diffusez sur Internet, protéger un minimum ses applications web devient très rapidement vital si elles sont autohébergées, et encore plus (*shock*) si vous les avez développées vous même. On aimerait bien éviter de devenir la porte ouverte à toute les fenêtres…

De plus, une fois la peur des pirates informatique américo-chinois (ou autre gouvernement soutenant ouvertement les pirates informatiques : il n’y a bien que la France pour n’avoir que des équipes de « défense ») étant partiellement écartée, on peut aussi disposer de beaucoup de contenus publiés, disposant chacun de leur propre méthode d’authentification, et souhaiter pouvoir faire du Single Sign On pour éviter d’avoir 50 comptes différents et de taper ses logins/passwords toute la journée! Aaaaah le Single Sign On. Les SSII nous en auront vendu, des solutions clés en mains permettant de s’interfacer avec tout en un clic, ou presque! Toute la nuance étant dans le « ou presque ».

Aujourd’hui, je ne vais donc pas vous vendre la solution ultime à tous vos problématiques de sécurisation de vos applications web ni vous donner un portail SSO universel, mais tout de même…

Présentation

Vulture est un projet open source, permettant de faire la plupart des tâches qu’on attend d’un portail Web SSO. Depuis plusieurs mois, il n’y avait pas eu beaucoup d’activité sur le projet, qui est resté pendant un bon moment aux versions 1.98 et 1.99. Cependant il manquait à la version 1.XX certaines fonctionnalités utiles, notamment la propagation de l’authentification via cookies (utilisé par exemple pour mediawiki). Un peu dommage pour un SSO si on doit se ré-authentifier pour aller sur son Wiki pour aller chercher des infos techniques rapidement.

Cependant, cet été, une version 2.0 a vu le jour, même si le fait que cela soit une beta ou non n’est pas très clair je trouve ([EDIT] A priori on est toujours en béta, donc pas de prod je vous prie).

Vulture est un reverse-proxy offrant des fonctions Web-SSO et firewall applicatif.

Un des gros points noir du projet Vulture est le manque de clarté dans leur documentation, notamment pour les débutants dans les reverse-proxy. A mon avis, un petit tutoriel pas à pas s’impose pour pouvoir configurer « au minimum » l’accès à quelques applications.

Installation

La première chose que je dois vous dire, c’est que j’ai effectué l’installation sur une machine virtuelle vieillissante en Debian Lenny. Je vais donc tout de suite commencer par vous déconseiller de tester sur une Lenny, mais plutôt de le faire sur une Squeeze, pour des raisons de paquets non disponibles dans les dépôts…

La documentation relative à l’installation en elle même est disponible sur le site du projet

www.vultureproject.org/documentation/installation/

Une fois toutes les dépendances installées comme indiqué sur le site puis le paquet .deb installé, vérifiez que vous n’avez aucune erreur lors du lancement de l’application (automatique).

A priori vous devriez pouvoir vous connecter sur l’interface web de vulture en local sur le port 9090 (et local seulement). Pour ceux qui voudraient ne pas être obligés de faire ça en local justement (VM sans environnement graphique ou réseau local bien protégé), vous pouvez faire un tunnel SSH ou modifier les paramètres apache de Vulture, comme indiqué dans la doc d’installation.

Personnellement je suis sur un réseau NATé, donc le seul moyen d’accéder au port 9090 est d’être sur mon réseau local, et j’ai pu laisser des paramètres de sécurité apache très lights. Le plus propre serait évidemment d’interdire toutes les IP autres que votre poste d’administration.

Listen *:9090
[...]
<Virtualhost *:9090>

Pour ceux qui n’ont rien écouté et qui ont quand même voulu installer leur vulture sur un Lenny, si vous vous retrouvez avec l’erreur suivante, c’est parce que le paquet libdb4.8 n’est tout simplement pas installé pour une raison simple : elle n’est pas disponibles dans les dépôts standards.

Starting vulture: apache2: Syntax error on line 40 of /var/www/vulture/conf/1.conf: Cannot load /usr/lib/apache2/modules/mod_security2.so into server: libdb-4.8.so: cannot open shared object file: No such file or directory
apache2: Syntax error on line 40 of /var/www/vulture/conf/2.conf: Cannot load /usr/lib/apache2/modules/mod_security2.so into server: libdb-4.8.so: cannot open shared object file: No such file or directory

Une façon de s’en sortir est heureusement d’installer le fameux paquet depuis un site tiers

wget http://backports.debian.org/debian-backports/pool/main/d/db/libdb4.8_4.8.24-1~bpo50+1_i386.deb
dpkg -i libdb4.8_4.8.24-1~bpo50+1_i386.deb

Configuration

Maintenant on entre dans le vif du sujet. Nous sommes parvenus à installer Vulture, et il est maintenant accessible en local ou pas (c’est selon).

Pour se connecter, c’est facile, le mot de passe administrateur est parfaitement secure puisqu’il s’agit de admin/admin, donc vous pouvez le laisser tel quel :-p.

Ceux qui connaissent déjà la version précédente de Vulture ne seront pas trop surpris : elle est strictement identique. Bien que la documentation soit assez claire sur la fonction de chacun des champs dans chacun des menus (documentation de Vulture), il n’y a pour l’heure aucun tutoriel pour permettre à tout le monde d’installer Vulture.

Voici donc, une liste d’étapes commentées pour vous permettre de mettre en place le strict minimum : un portail commun pour vos application web faisant office de firewall applicatif, avec une authentification simple, ainsi que l’ajout d’une application (mediawiki ici) sans SSO.

Les problématiques plus poussées seront développées dans un prochain article (SSO, ajout d’une authentification LDAP, …).

Gestion des utilisateurs

Comme dit plus haut, la première priorité est donc de changer le mot de passe de l’administrateur. Pour se faire, il suffit de cliquer sur le menu Users puis de cliquer sur la petite icône représentant une feuille et un crayon pour éditer l’utilisateur.

Pour une raison que j’ignore, même si je doute que ce soit une nouvelle fonctionnalité révolutionnaire, le mot de passe est affiché via son hash MD5. Et pour le modifier il faut entrer également un hash MD5 du nouveau mot de passe.

Une fois qu’on a modifié le mot de passe de l’administrateur, on peut ensuite créer tous les utilisateurs qu’on veut autoriser à se connecter au portail et au applications.

Creation d’un module de log

Pour générer les fichiers de journalisation sur les erreurs et les accès apache de chacun des composants interfacés au portail, Vulture se base sur le module apache mod_log.

Contrairement à la version précédente de Vulture, il est nécessaire de créer/paramétrer son propre module de logging avant de pouvoir commencer à déclarer les interfaces. A mon avis, là aussi, c’est juste un oubli, qui sera rajouté par la suite.

En attendant, voici les champs à remplir pour pouvoir disposer d’une journalisation correcte sur chaque interfaces et chaque application :

Name : Combined
Error Log Verbosity : error
Access Log Format : « %h %l %u %t « %r » %>s %b « %{Referer}i » « %{User-agent}i » »
Directory where to place Logfiles : /var/log/

Création d’une interface

Vulture permet de créer un certain nombre d’interfaces, qui correspondent en fait aux virtualhosts en écoute pour le portail qui regroupe toutes les applications.

Il est donc nécessaire d’en créer au moins une, que l’on liera par la suite à toute nos applications.

Dans mon cas, j’ai souhaité que toutes les applications web que je publie sur Internet soient centralisées par un portail HTTPS. Pour ce faire, j’ai créé plusieurs alias DNS qui pointent tous vers l’IP du portail vulture (192.168.0.XX), ainsi qu’un alias pour le portail lui même (portail.example.org).

J’ai ensuite généré les certificats SSL (autosignés ici). Pour générer plus rapidement les certificats, il est possible d’utiliser le modèle fournit sur le site vulture.open-source.fr (lien mort, j’utilise Internet Archive), puis exécuter la commande :

openssl req -x509 -days 1825 -newkey rsa:1024 -batch -out server.crt -keyout server.key -nodes -config openssl.cnf

Pour créer l’interface il suffit donc de remplir les champs correspondants

Creation de l’application

Une fois l’interface créée sans encombre, reste maintenant à définir les paramètres de vulture pour l’application que l’on souhaite protéger derrière le Vulture. Ici, il s’agit d’un Mediawiki, sur lequel on peut s’authentifier via une base de données interne, ou via LDAP. Dans les deux cas, il n’était pas possible d’interfacer Mediawiki avec Vulture 1.99. Ici, je ne détaillerai pas la méthode pour effectuer ce SSO normalement disponible depuis la 2.00, pour la simple raison que je ne l’ai pas encore testé, mais cela fera l’objet d’un prochain article.

Ici, les champs à remplir sont :

Internet Name : l’alias que l’on a décidé pour l’application, mediawiki.example.org par exemple
Interface : L’interface qu’on vient de créer
Private URL : L’url complète vers laquelle on doit pointer pour trouver l’application web. Ici il s’agit de l’IP et du numéro de port du mediawiki
Authentication : les méthodes qui sont autorisées pour décider si l’utilisateur à l’accès ou non. Ici la seule méthode dont on dispose pour l’instant est vulture (il faut donc la sélectionner)

Après une petit redémarrage de l’interface (logo avec les deux flèches vers en cercle), le portail et l’application devraient être disponible

Enjoy