dict.html0100644040463302611160000001234610175714777014017 0ustar germanlinuxlemonldap

Dictionnaire XLM pour lemonldap

<domain>

Attribut

Valeur

Exemple

name

Nom du domaine

Appli.exemple

cookie

Nom du cookie à utiliser

lemontest

templates_dir

Répertoire des templates

/opt/apache/portail/templates

templates_options

Options à passer au moteur de template

ABSOLUTE => '1', INCLUDE_PATH => 'templates_dir'

login

Url de la page d'authentification

http://cpportail.appli.cp/portailtest/accueil_obj.pl

menu

Url de la page de menu des applications

http://cpportail.appli.cp/portailtest/application_new.pl

ldap_server

Nom ou adresse du serveur LDAP

Ldap.exemple.net

ldap_port

Port du serveur LDAP (def 389)

389

DnManager

DN du compte admin du ldap

Cn=Directory Manager

passwordManager

Mot de passe de l'admin LDAP

secret

ldap_branch_people

Base de la recherche des utilisateurs

Ou=personnes,dc=exemple,dc=net

session

Type de session utilisée

memcached



<cache>

Attribut

Valeur

Exemple

name

Nom du cache utilisé comme valeur du segment IPC

CONF

type

Backend du cache

IPC

ttl

Time to live : durée de vie du cache (def 0 = illimité)

10000



<session>

Attribut

Valeur

Exemple

name

Nom de backend de session

Memcached

type

Type du backend de stockage

Memcached,MySQL

servers

Serveur de memcached

['ip.ip.ip.ip:11211']





RETOUR http://lemonldap.sourceforge.net

dtd.html0100644040463302611160000003254710213601321013621 0ustar germanlinuxlemonldap

Paramètres généraux

Information Menu

Portée :<menu></menu>

Nom du cookie

portée : <domain> </domain>

Syntaxe XML : Cookie

Syntaxe httpd.conf: LemonldapCookie

exemple : Cookie = « lemontest »  ou

PerlSetvar LemonldapCookie lemontest

Commentaires : Sert à fixer le nom du cookie utilisé par la brique d'authentification.

Nom du fichier XML de configuration

portée : pas autorisé dans le fichier XML

Syntaxe httpd.conf : LemonldapConfig

exemple :

PerlSetVar LemonldapConfig /opt/apache/conf/application.xml

Commentaires : Sert à transmettre au handler le nom du fichier de configuration à utiliser - OBLIGATOIRE

Nom de l'identifiant IPC du XML de configuration

portée : <cache></cache>

syntaxe XML : ConfigIpcKey = « CONF »

Syntaxe httpd.conf : LemonldapConfigIpcKey

exemple :

PerlSetVar LemonldapConfigIpcKey CONF

Commentaires : Sert à transmettre au handler le nom de l'identifiant IPC utilisé pour la configuration - OBLIGATOIRE

Nom du domaine

portée : <domain></domain>

syntaxe XML <domain id=foo.bar>

syntaxe httpd.conf : LemonldapDomain

exemple :

PerlSetVar LemonldapDomain foo.bar

Commentaires : Sert à transmettre au handler le nom du domaine sur lequel il travaille et à implementer un domaine dans le XML.

Activation du mode DEBUG

portée : pas autorisé dans le XML

syntaxe httpd.conf :LemonldapDEBUG 0|1

exemple :

PerlSetVar LemonldapDEBUG 1

Commentaires : 0 :désactive le mode DEBUG . 1 : active le mode DEBUG .

Valeur par défaut : 0

Identifiant du handler

Portée :<hanler></handler>

syntaxe XML : <handler id=exemple>

syntaxe httpd.conf : LemonldapHandlerID

exemple

PerlSetVar LemonldapHandlerID iccappli

Commentaires: permet à un handler de retrouver sa section dans le fichier XML

Nombre de sessions à garder dans le cache de niveau 2 : IPC

portée : <handler></handler>

syntaxe XML : IpcNb= « nb »

syntaxe httpd.conf :LemonldapIpcNb nb

exemple :

PerlSetVar LemonldapIpcNb 5

Commentaires : Fixe la limite maximum d'element à conserver dans la pile des session , sachant que la plus recente chasse la plus ancienne .

La valeur « 0 » désactive le cache 2 IPC

Identifiant du cache IPC utilisé par le cache de niveau 2.

portée : <handler></handler>

syntaxe XML : IpcKey= « xxxx »

syntaxe httpd.conf :LemonldapIpcKey xxxx

exemple :

PerlSetVar LemonldapIpcKey ADE1

Commentaires : Cet identifiant est composé d'une chaine de 4 caractères .

Nom de l'attribut LDAP stockant les profils applicatifs.

portée : <handler></handler>

syntaxe XML : AttrLdap= « mefiapplicdc »

syntaxe httpd.conf :LemonldapAttrLdap string

exemple :

PerlSetVar LemonldapAttrLdap mefiapplicdc

Commentaires : Ce parametre est utilisé pour retrouver dans le tableau associatif de la session (hash %session ) le profil à appliquer , sachant que son absence invalide

l'acces à l'application.

Code de l'application protégée

portée : <handler></handler>

syntaxe XML : CodeAppli= «ADONIS »

syntaxe httpd.conf :LemonldapCodeAppli string

exemple :

PerlSetVar LemonldapCodeAppli ADONIS

Commentaires: C'est la deuxième dimension du tableau associatif de session , l'intersection $session{AttrLdap}{CodeAppli} doit exister et retourner le profil applicatifs.

C'est ce profil qui est envoyé à l'application dans le HEADER .

Contrôle des requêtes

portée : <handler></handler>

syntaxe XML : Disabled = »boolean »

syntaxe httpd.conf : LemonldapDisabled 0|1

exemple : LemonldapDisabled 1

Commentaires: ce parametre permet d'activer ou de desactiver les controles sur les URL . (0 : contrôle ON ; 1 contrôle OFF default 0) .

Cela permet de définir des filtres sur des url (ex: *jpeg ) qui ne seront pas contrôlées et qui pourront être mise en cache par mod_proxy.

Interception du cookie de la brique d'authentification

portée : <handler></handler>

syntaxe XML : StopCookie = »boolean »

syntaxe httpd.conf : LemonldapStopCookie 0|1

exemple : LemonldapStopCookie 1

Commentaires: Autorise ou empeche que le cookie de session aille jusqu'à la ressource protégée (0 : autorise; 1 interdit default 0) .

Backend de la session

portée : <domain></domain><session></session>

syntaxe XML : Session = »type_de_session»

syntaxe httpd.conf : LemonldapSession cache-level3

exemple : LemonldapSession memcached

Commentaires: Ce paramètre doit être le nom d'un paragraphe XML contenant les informations sur le backend de cache de niveau 3 (memcached ou mysql) .

URL publique

portée : <handler></handler>

syntaxe XML : BasePub = »nom du serveur public »

syntaxe httpd.conf : LemonldapBasePub serveur

exemple : LemonldapSession http://serveur.foo.bar

Commentaires: c'est la base de l adresse publique d'une ressource protégée . Elle correspond à un virtual host de la brique .

URL privée : ressource protégée

portée : <handler></handler>

syntaxe XML : BasePriv = »nom du serveur à protéger »

syntaxe httpd.conf : LemonldapBasePriv serveur

exemple : LemonldapSession http://serveurpriv.foo.bar

Commentaires: c'est la base de l adresse privée d'une ressource protégée .

Page de login (portail / accueil )

portée :<domain><domain>

syntaxe XML : Portal = »url du portail »

syntaxe httpd.conf : LemonldapPortal url

exemple : LemonldapSession http://lemonldap.foo.bar/portail/accueil.pl

Commentaires: c'est l adresse de la page sur lequel l'utilisateur non authentifié est dirigé .

paramètres du proxy intégré LWP.

Utilisation du proxy LWP intégré

portée : <domain> ou <handler>

syntaxe httpd.conf :LemonldapEnabledproxy 0|1

syntaxe XML : Enabledproxy= « boolean»

exemple :

PerlSetVar LemonldapEnabledproxy 1

Commentaires : 0 :ne pas utiliser le proxy intégré (donc passer la main à mod_proxy) . 1 : utiliser le proxy intégré .

Valeur par défaut : 0

Utilisation d'un proxy tiers par LWP

portée : <handler></handler>

syntaxe XML : ProxyExt = »url:port»

syntaxe httpd.conf : LemonldapproxyExt url:port

exemple : LemonldapproxyExt htpp://monproxy.foo.bar:3128

Commentaires: Ce paramètre indique l'adresse du proxy que la brique contacte pour s'adresser aux ressources protégées .

Comportement du proxy intégré LWP

portée : <handler></handler>

syntaxe XML : RECURSIVE = »boolean »

syntaxe httpd.conf : LemonldapRECURSIVE 0|1

exemple : LemonldapRECURSIVE 1

Commentaires: Fixe la stratégie de redirection 0 : LWP prend à son compte la redirection , 1 Le client prend à son compte les redirection default 0) .

Comportement pour le CDA : Cross Domain Authentification

Le domaine MAITRE n'a pas besoin de balise particulière.

Le domaine MAITRE doit retrouver la balise XML suivante dans le domaine ESCLAVE

<domain slave.bar

slavecda ="http://authen.slave.bar/cda/mycdaslave.pl"

>

Les handler de l'esclave doivent avoir dans leur configuration

Portal= »http://authen.master.foo/cda/mymaster.pl »









httpd2.html0100644040463302611160000001127010214312232014242 0ustar germanlinuxlemonldap

Installation d apache 1.3.N pour lemonldap

Vous devez disposer d'un daemon httpd compilé avec les modules suivants:

[root@lemon bin]# ./httpd -l



Il faut les sources d'apache, de mod_perl et de mod_ssl .
Commencer par decompacter les sources d'apache puis celles de mod_ssl et enfin celles de mod_perl.
procéder à l'installation de mod_ssl  (suivre la doc de mod_ssl).
Aller dans le répertoire de source de mod_perl   et lancer la  commande suivante : 


perl Makefile.PL APACHE_PREFIX=/opt/apache_dev APACHE_SRC=/opt/apache_1.3.27/src DO_HTTPD=1 USE_APACI=1 \

EVERYTHING=1 APACI_ARGS='--enable-module=ssl --disable-module=negotiation --disable-module=autoindex –disable-module=imap \

--disable-module=userdir --disable-module=auth --enable-module=proxy –enable-module=rewrite'


nb: le fichier  apache.txt du projet lemonlap contient le texte de la commande.
Procéder  depuis  le répertoire d'installation  d'apache à la génération des certificats .

Installation d apache 2.0 pour lemonldap

Dans le répertoire des sources d'apache2 :

./configure --with-layout=Apache --enable-mods-shared=all --enable-ssl
--enable-proxy --enable-proxy-http --enable-proxy-ftp
make
make install

Dans le répertoire des sources de mod_perl


cd mod_perl-2.0.0-RC4/
perl Makefile.PL MP_APXS=/usr/local/apache2/bin/apxs
make
make test
make install

Puis rajouter dans httpd.conf les lignes suivantes :

LoadModule perl_module modules/mod_perl.so
 PerlModule Apache2
 PerlModule Apache::compat



index2.html0100644040523602611160000007214307747236141013330 0ustar aliochalemonldap lemonldap1

SourceForge.net Logo annuwave lemonLDAP
Le site de sourceforge www.annuwave.net Le projet lemonldap

lemonLDAP


Responsable du projet: eric GERMAN germanlinux@yahoo.fr

Bienvenue sur le site du projet lemonLDAP :   Reverse-proxy d'authentification LDAP.

Principes : Le reverse-proxy lemonLDAP est un service réseau qui est un point d'entrée unique de toutes les requêtes HTTP des différentes applications web mises à disposition et qui en relation avec un serveur LDAP met en place un mécanisme unique d'authentification des utilisateurs et de contrôle d'accès à ces applications.

Après authentification de l'utilisateur en HTTPS auprès de l'annuaire LDAP, le reverse-proxy met en cache des attributs LDAP de l'utilisateur afin de contrôler l'accès de l'utilisateur aux différentes applications web .

Ces applications web sont dénommées  ressources protégées. Le dialogue entre le reverse-proxy et les applications est réalisé par le biais d'un entête (HEADER) AUTHORIZATION. le header  AUTHORIZATION est rajouté à chaque requête et il contient  le DN (distinguished name) de l'utilisateur suivi du profil applicatif .


Session.

La session est maintenue entre le reverse-proxy et l'utilisateur par un cookie de session qui contient un numéro de session faisant référence à un fichier stocké dans le système de fichier ou à une entrée dans une base de données .

Architecture.

Le "reverse-proxy" lemonLDAP n'est pas un logiciel en tant que tel mais plutôt la combinaison des composants bien connus  : Apache, mod_perl,MySQL,webmin et les Net::LDAP API de graham Barr

La clé de voute du système est le serveur web apache , compilé et configuré de manière particuliaire.
Autour de ce serveur on trouvera un handler apache par ressource à protéger . Deux CGI réalisent l'authentification et enfin une interface sous webmin  administre le système global. L'ensemble du système ou "boitier" fonctionne sous GNU/Linux.


Le serveur apache.
Il vous faut disposer d'un serveur apache contenant les modules suivants :

[root@cplemon003 bin]# ./httpd -l

Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_status.c
  mod_include.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_actions.c
  mod_alias.c
  mod_access.c
  mod_setenvif.c
  mod_ssl.c
  mod_perl.c

suexec: disabled; invalid wrapper /opt/apache/bin/suexec


Les modules sont compilés de maniere statique  (et non pas en tant que modules dynamiques)  pour des raisons de performances.
Le daemon httpd doit être le plus leger possible .

La configuration d'apache utilise le système de "virtual host" , par  exemple :

<virtualhost  10.ip.ip.ip>
ServerName ressource.appli.exemple
perlmodule My::egproxy_exemple
perltranshandler My::egproxy_exemple
loglevel debug
</virtualhost>


Explications :

Plusieurs adresses IP sont attribuées au système sur lequel est exécuté lemonLDAP (on pourra utiliser la technique de l'IP aliasing) .

Le serveur Apache répond à toutes les requêtes, que ce soit à destination de l'adresse de base ou des adresse virtuelles, sachant qu'à une adresse IP correspond un hôte virtuel (virtual host), et qu'un hôte virtuel est une ressource à protéger.
Dans l'exemple, 10.ip.ip.ip  est l'adresse virtuelle (VIP)  de la ressource placebo.appli.domaine . L'adresse réelle de la ressource (RIP) n'est connue et accessible qu'à travers le remote-proxy (§ configuration du DNS) .

La configuration des virtual  host est stockée  dans un fichier distinct pour alléger le fichier de configuration principal de httpd


La derniere ligne du fichier de configuration d'apache  (httpd.conf) à le contenu suivant:

.......
include conf/lemon.conf


Certificats

Le reverse-proxy redirige automatiquement l'utilisateur sur une page de connexion  si la phase d'authentification n'a pas été déjà faite .
La saisie du nom d'utilisateur et du mot de passe est protégée par le protocole HTTPS . Il est donc nécessaire de générer un (ou des) certificat(s) pour Apache.
La configuration la plus simple ne nécessite qu'un seul certificat  : le certificat serveur . Il peut s'agir d'un certificat  "autosigné" (selfsigned) , dans ce cas la présence du certificat du CA (autorité de certification) n'est pas obligatoire .

procedure :

         openssl req -new -x509 -keyout ./ca.key -out ./ca.crt

        openssl genrsa -out server.key
        et
        openssl req -new -key server.key -out server.csr


ATTENTION : Il faut utiliser le FQDN : nom pleinement qualifié du serveur

Pour cela créer un environnement pour la CA (avec CA.pl)
sinon faire un echo 01 > ca/serial
et lancer la commande:

openssl ca -config ./openssl.cf -out server.crt -infiles ./server.csr

openssl x509 -text -inserver.crt

Remarque: Dans certains articles il est dit de rajouter l'option -nodes pour eviter d'avoir à taper un mot de passe : la clé privée reste en clair .

La page d'authentification et la page "menu" .

Le boitier fonctionne selon trois modes :

Contenu de la page d'authentification.
La page d'accueil est un script CGI en perl qui réalise les operations suivantes:
vérification de l'identité de l'utilisateur.
Chargement aupres du LDAP des profils applicatifs.
Création du fichier de session
Création du cookie de session

Apres ces operation  le script se termine en chargeant une page "menu" ou en chargant la page demandée initialement.

use Template;
use Apache::Session::File;
use strict;
use CGI qw(-no_xhtml);
use Net::LDAP;
use MIME::Base64;
use Data::Dumper;
##############
my $ldap_serveur="cpldap";
my $ldap_port="389";
##############
if (CGI::param('op') eq 'c') {
 my $urlc= CGI::param('url');
my $urldc= decode_base64($urlc);
print CGI::header();
######### cas de connexion directe sur une ressource ##############
my $file= '/templates/p1_header.thtml';
my $template=Template->new({ABSOLUTE =>1} );
$template->process($file)||die $template->error();
$file= '/templates/p1_first.thtml';
my %data=( 'urlc' => $urlc , 'urldc' => $urldc );
$template->process($file,\%data)||die $template->error();
exit;
}
 if (CGI::param('op') eq 't') { my $urlc= CGI::param('url');
my $urldc= decode_base64($urlc);
print CGI::header();
######### cas de time out ##############
........
exit;
}
 unless (CGI::param()) {
 # grille vide
print CGI::header();
my $file= '/templates/p1_header.thtml';
my $template=Template->new({ABSOLUTE =>1} );
$template->process($file)||die $template->error();
$file= '/templates/p1_connect.thtml';
$template->process($file)||die $template->error();
exit;
}
 if (CGI::param('apply')) { my $nom = CGI::param('Identifiant');
my $secret = CGI::param('secret');
my $pass =$secret;
$pass = 1 if ($secret eq '0');
my $ligne=Dumper(\$pass);
######### grille incomplete ##########
unless (($nom) && ($pass)) {
........
 exit;

}
################champs remplis##############
######## controle dans ldap ######
my $ldap= Net::LDAP->new ($ldap_serveur,port=>$ldap_port);
$ldap->bind("cn=XXXXXXXXX" , password=> 'XXXXX');
my $name = $nom;
$nom.="-cp" unless ($nom=~ /-cp/) ;
my $filtre= "(uid=$nom)" ;
my $mesg=$ldap->search ( base=> 'ou=personnes,ou=dgcp,ou=mefi,o=gouv,c=fr', scope =>'sub', filter => $filtre );
my $retour=$mesg->entry(0) ;
unless ($retour) { ## il n existe pas exit;
}   ## fin il n existe pas
## il existe on essaye le bind
my $uid =$retour->get_value('uid');
my $dn =$retour->dn;
my $codique =$retour->get_value('affectation');
my $departement=$retour->get_value('departement');
my $mail = $retour->get_value('mail');
$ldap->unbind;
$ldap= Net::LDAP->new ($ldap_serveur,port=>$ldap_port);
my $bind=$ldap->bind($dn,password=> $secret);
if ($bind->code)
 { # erreur dans authentification
 ......  
 exit;
} # fin mauvais bind
#Le bind est bon tout est ok
#on recupere les attributs et on cree le cookie
# et on ferme la boutique
 my $cookie;
my $urlc = CGI::param('urlc');
my $url =decode_base64($urlc);
my $id =CGI::cookie(-name=>"lemon");
my $tl;
my $url;
if (CGI::param('urlc')) { # c est une reconnexion
$url = decode_base64(CGI::param('urlc')) ;
}
 if ($url) {
 undef $id;
}
tie my %session,'Apache::Session::File', $id, {Directory => "/var/tempcookie/" , LockDirectory => "/var/tempcookie/"};
unless ($id) {
 $cookie = CGI::cookie ( -name=>'lemon',
                                         -value=>$session{_session_id},
                                         -domain=>'.appli.exemple',
                                         -path => '/' );
             }
 $session{uid} =$uid;
$session{dn} =$dn;
$session{departement} = $departement ;
$session{mail} = $mail ;
# construction tableau des profils applicatifs dans $session a partir d un attribut de l entree
.........

$session{codique} = $codique ;
### on met en cache dans l apache les mefiattributs
untie %session;
$ldap->unbind;
if ($url) { # c est une reconnexion
print CGI::header(-Refresh=> "1;URL=$url",-cookie=>$cookie);
.........
print CGI::end_html;
exit;
}
print CGI::header(-Refresh=> "1;URL=https://cpportaildgcp.appli.dgi/portail/s2.pl",-cookie=>$cookie); print CGI::start_html ();
.......
print CGI::end_html;
exit;
}


(squelette de p1.pl )


remarque à porpos de l'information de session.

Dans l'exemple précédent on utilise un hash "%session"   ce hash  doit pouvoir etre exploité par le handler  perl .
Il est opportun d'y stocker  le maximum d'information , il joue ainsi le role d'un cache et le portail n'aura plus à aller chercher des informations  aupres du serveur LDAP .


Les handlers


Un handler   est solocité à chaque demande d'acces à une ressource protégée .
Il réalise les opérations suivantes:


  • Vérification de la présence du cookie
  • Retrouver les infos de session (le hash %session)
  • vérifier si l'utilisateur peut accéder à la ressource
  • Fabriquer ' entête (header) avec le DN suivie d'une chaîne de caractères (souvent le profil ou autre chose) .
  • Faire la requête à la place de l'utilisateur  auprès de la ressource protégée et renvoyer la réponse à l'utilisateur.

package My::egproxy_exemple;
use strict;
use vars qw(@ISA $VERSION);
use LWP::UserAgent ();
use Apache::URI();
use Apache::Constants qw(:common :response);
use Apache::Session::File;
use Data::Dumper;
use MIME::Base64;
use Template; $| =1;
#my ($DEBUG,$NOTICE);
$DEBUG=1;
$NOTICE=1;
##my $HEADER=1;
##my $STOP_COOKIE=0;
#@ISA = qw(LWP::UserAgent);
$VERSION = '1.00';
my $UA = __PACKAGE__->new;
$UA->agent(join "/", __PACKAGE__, $VERSION);
sub handler { my($r) = @_;
print STDERR "handler je passe \n" if $DEBUG;
$r->handler("perl-script");
#ok, let's do it $r->push_handlers(PerlHandler => \&proxy_handler);
return OK;
} sub proxy_handler { my($r) = @_;
print STDERR "proxy handler \n" if $DEBUG;
my $url =$r->uri ;
my $rf = $r->the_request();
my $arg =$r->args;
my %entete =$r->headers_in();
print STDERR "proxy requete $rf \n" if ($DEBUG||$NOTICE);
print STDERR "proxy query $arg \n" if $DEBUG;
print STDERR "proxy avant trt $url \n" if $DEBUG;
################## applicatif ###############################
$url ="http://ressource.appli.exemple".$url unless $url=~ /\.appli\.exemple/ ;
$url ="http://ressource.appli.exemple".$url unless $url=~ /ressource\./ ;
print STDERR "proxy avant trt 8080 $url \n" if $DEBUG;
################## applicatif ###############################
#
#
########### redirection port 8080 ########################
##
$url.="?$arg" if $arg;
###########################################################
#
my $urlc ;
$urlc = encode_base64($url);
$urlc=~ s/\n//g;
print STDERR "proxy apres trt $url \n" if ($DEBUG||$NOTICE);
my $request = HTTP::Request->new($r->method, $url);
############# controle cookie #############
###
##
#
#
unless ($entete{'Cookie'}) {
# il n y a pas de cookie il faut donc
# rediriger le client vers la page de login
print STDERR "pas de cookie ! pour $url \n" if $DEBUG;
$r->header_out(location =>"https://portail.appli.exemple/portail/p1.pl?op=c&url=$urlc");
return REDIRECT;
}
#
##
################################################
##
#
#
######### ok ici tout est cool #################
## on recupere les infos du fichier id cookie
# et on lui balance l entete specialisee
################################################
my $idx =$entete{'Cookie'} ;
$idx =~ /lemon=(.+);/;
my $id =$1;
unless ($id) { $idx =~ /lemon=(.+)/ ;
$id=$1;
} print STDERR "id session : $id\n" if $DEBUG;
my $tl;
my %session ;
eval { tie %session,'Apache::Session::File', $id, {Directory => "/var/tempcookie" , LockDirectory => "/var/tempcookie"};
print STDERR "je verrouille\n" if $DEBUG;
};
if ($@) {
### erreur cookie deuxime essai ############
eval { tie %session,'Apache::Session::File', $id, {Directory => "/var/tempcookie" , LockDirectory => "/var/tempcookie"};
print STDERR "je verrouille" if $DEBUG;
    }
}
if ($@) { ### erreur cookie ############
print STDERR "je passe en erreur $@\n" if $DEBUG;
$r->header_out(location =>"https://portail.appli.exemple/portail/p1.pl?op=t&url=$urlc");
return REDIRECT;
exit;
}
my $uid = $session{uid};
$uid=~ s/ //g;
my $ligne= Dumper(%session) ;
print STDERR "session $ligne" if $DEBUG;
my $codique =$session{codique};
#acces sur le ldap pour le dn en question my $dn = $session{dn};
$dn=~ s/ //g;
my $etat; my $complement;
################# controle sur une location #############
if ($url =~ /ressource/ ) {
if ($session{'exemple'}{'RESSOURCE'})
{
$etat =1;
my $suite=$session{'exemple'}{'RESSOURCE'};
$suite=~ s/#.*//;
$complement=":$suite";
    }
}
#
if ($etat) { print STDERR "controle: $dn $url :ACCEPTED \n" if ($DEBUG||$NOTICE);
            } unless ($etat) {
print STDERR "controle: $dn $url :REJECTED \n" if ($DEBUG||$NOTICE);
}
################# fin controle location ############
#####################################################
#
# filtrage habilitation
#
#
#####################################################
unless ($etat) {
### c est meme pas la peine essayer connard !
my $file= '/templates/intrusion_header.thtml';
my $template=Template->new({ABSOLUTE =>1} );
$template->process($file)||die $template->error();
$file= '/templates/intrusion_body.thtml';
my %data=( 'url' => $url , );
$template->process($file,\%data)||die $template->error();
exit;
}
######### ici tout est ok pour moi
print STDERR "etat :$etat \n" if $DEBUG;
print STDERR "dn session $uid\n" if $DEBUG;
#recuperation de l attribut multivalue en fonction de l url
untie %session;
############################################
my $entete_spec = "Basic ";
my $ligne_h = $dn;
if ($complement) { $ligne_h.="$complement";
} my $hcode =encode_base64($ligne_h);
print STDERR "code avant encodage: $ligne_h\n" if ($DEBUG);
print STDERR "code apres encodage: $hcode\n" if $DEBUG;
$hcode=~ s/\n//g;
$entete_spec.=$hcode."\n";
$r->header_in('Authorization'=> $entete_spec);
my $cpe=1;
while (1) { print STDERR " rattrapage entete : $cpe \n" if ($DEBUG);
$r->header_in('Authorization'=> $entete_spec) unless $r->header_in('Authorization') ;
last if $r->header_in('Authorization') ;
$cpe++;
} print STDERR "entete : $entete_spec\n" if ($DEBUG);
###########################################################
# tout est fini la messe est dite #
# on fabrique la requete pour le robot #
###########################################################
$r->headers_in->do(sub { my $ligne = Dumper(@_);
print STDERR "HEADER $ligne\n" if ($DEBUG||$HEADER);
print STDERR "header ouput ok\n" if (($ligne=~ /Authorization/) && ($DEBUG||$HEADER||$NOTICE));
if ($STOP_COOKIE) { (my $cle ,my $valeur) = @_;
if ($valeur=~ /lemon/) { $_[1]=~ s/lemon=.+\b//;
print STDERR "STOP_COOKIE : on \n" if ($DEBUG||$HEADER);
} } $request->header(@_);
1;
});
######### verif un dernier coup ###############
########
unless ($request->header('Authorization')) {
$request->header('Authorization'=> $entete_spec);
print STDERR "header debug\n" if ($DEBUG||$HEADER);
}
################################################
# copy POST data,
if any if($r->method eq 'POST') {
my $len = $r->header_in('Content-length');
my $buf;
$r->read($buf, $len);
$request->content($buf);
$request->content_type($r->content_type);
} my $ligne= $request->as_string();
print STDERR "requette $ligne\n" if $DEBUG ;
#$UA->proxy(http => 'http://ip.ip.ip.ip:3132');
# my $response = $UA->request($request);
# my $lignex= $response->as_string();
# print STDERR "reponse $lignex \n";
$r->content_type($response->header('Content-type'));
#feed response back into our request_rec* $r->status($response->code);
$r->status_line(join " ", $response->code, $response->message);
$response->scan(sub { $r->header_out(@_);
});
if ($r->header_only) { $r->send_http_header();
return OK;
} my $content = \$response->content;
$r->content_type('text/html') unless $$content;
$r->send_http_header;
$r->print($$content || $response->error_as_HTML);
print STDERR "handler termine reponse envoyee \n" if ($DEBUG);
return OK;
} 1;



(squelette egproxy_exemple.pm)




Le module pour webmin

Ce module permet de visualiser l'état du reverse-proxy.
-Il donne des informations sur :
-Les hôtes virtuels
-Le nombre de connexions simultanées

En outre , il est possible d'arrêter ou de démarrer le reverse-proxy par le biais de ce module.
Il est en téléchargement ici.












index.html0100644040463302611160000017565410173156204014176 0ustar germanlinuxlemonldap lemonldap1

SourceForge.net Logo annuwave lemonLDAP english version
Le site de sourceforge www.annuwave.net Le projet lemonldap English version

lemonLDAP              

**Toujours chercher le problème a la source...                                                                                                 
** Toujours aller chercher les infos à la source...                                                                                                           
** La source, c'est la connaissance.
** Use your brain..
                   -- by  z33w  --

Responsable du projet: eric GERMAN germanlinux@yahoo.fr

Nouveautées : 

La nouvelle version lemonldap V1.0_mfaf : lien de la documentation en cours d elaboration

Avec: modules CPAN , Certificats clients , triples caches , integration dans apache

Bienvenue sur le site du projet lemonLDAP :   Reverse-proxy d'authentification LDAP.

Principes : Le reverse-proxy lemonLDAP est un service réseau qui est un point d'entrée unique de toutes les requêtes HTTP des différentes applications web mises à disposition et qui en relation avec un serveur LDAP met en place un mécanisme unique d'authentification des utilisateurs et de contrôle d'accès à ces applications.

Après authentification de l'utilisateur en HTTPS auprès de l'annuaire LDAP, le reverse-proxy met en cache des attributs LDAP de l'utilisateur afin de contrôler l'accès de l'utilisateur aux différentes applications web .

Ces applications web sont dénommées  ressources protégées. Le dialogue entre le reverse-proxy et les applications est réalisé par le biais d'un entête (HEADER) AUTHORIZATION. le header  AUTHORIZATION est rajouté à chaque requête et il contient  le DN (distinguished name) de l'utilisateur suivi du profil applicatif .


Architecture.

Le "reverse-proxy" lemonLDAP n'est pas un logiciel en tant que tel mais plutôt la combinaison des composants bien connus  : Apache, mod_perl,MySQL,webmin et les Net::LDAP API de graham Barr

La clé de voute du système est le serveur web apache , compilé et configuré de manière particulière
Autour de ce serveur on trouvera un handler apache par ressource à protéger . Deux CGI réalisent l'authentification et enfin une interface sous webmin  administre le système global. L'ensemble du système ou "boitier" fonctionne sous GNU/Linux.

Architecture simplifiée du serveur apache
Cette "pile" réalise l'authentification
 ressource protégée 1
 ressource protégée 2
 ressource protégée n
adresse IP principale du boitier
 IP alias 1
 IP alias 2
 IP alias n
pages d 'authentification
 hote virtuel 1
 hote virtuel 2
 hote virtuel n
pas d'handler particulier
 handler1
 handler2
 handler n



Session.

La session est maintenue entre le reverse-proxy et l'utilisateur par un cookie de session qui contient un numéro de session faisant référence à un fichier stocké dans le système de fichier ou à une entrée dans une base de données . Au point  de vue de mod_perl et mod_session les informations de session ne sont qu'un hash stocké de manière permanente.

Le serveur apache.
Il vous faut disposer d'un serveur apache contenant les modules suivants :

[root@cplemon003 bin]# ./httpd -l

Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_status.c
  mod_include.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_actions.c
  mod_alias.c
  mod_access.c
  mod_setenvif.c
  mod_ssl.c
  mod_perl.c

suexec: disabled; invalid wrapper /opt/apache/bin/suexec


Les modules sont compilés de maniere statique  et non pas en tant que modules dynamiques  pour des raisons de performances.
Le daemon httpd doit être le plus léger possible .

La configuration d'apache utilise le système de "virtual host" , par  exemple :

<virtualhost  10.ip.ip.ip>
ServerName ressource.appli.exemple
perlmodule My::egproxy_exemple
perltranshandler My::egproxy_exemple
loglevel debug
</virtualhost>


Explications :

Plusieurs adresses IP sont attribuées au système sur lequel est monté lemonLDAP (on pourra utiliser la technique de l'IP aliasing) .

Le serveur Apache répond à toutes les requêtes, que ce soit à destination de l'adresse de base ou des adresses virtuelles, sachant qu'à une adresse IP correspond un hôte virtuel (virtual host), et qu'un hôte virtuel est une ressource à protéger.
Dans l'exemple, 10.ip.ip.ip  est l'adresse virtuelle (VIP)  de  ressource.appli.exemple  . L'adresse réelle de la ressource (RIP) n'est connue et accessible qu'à travers le remote-proxy (§ configuration du DNS) .

La configuration des virtual  host est stockée  dans un fichier distinct (lemon.conf) pour alléger le fichier de configuration principal de httpd


La dernière ligne du fichier de configuration d'apache  (httpd.conf) à le contenu suivant:

.......
include conf/lemon.conf


Certificats

Le reverse-proxy redirige automatiquement l'utilisateur sur une page de connexion  si la phase d'authentification n'a pas été déjà faite .
La saisie du nom d'utilisateur et du mot de passe est protégée par le protocole HTTPS . Il est donc nécessaire de générer un (ou des) certificat(s) pour Apache.
La configuration la plus simple ne nécessite qu'un seul certificat  : le certificat serveur . Il peut s'agir d'un certificat  "autosigné" (selfsigned) , dans ce cas la présence du certificat du CA (autorité de certification) n'est pas obligatoire .

procedure :

         openssl req -new -x509 -keyout ./ca.key -out ./ca.crt

        openssl genrsa -out server.key
        et
        openssl req -new -key server.key -out server.csr


ATTENTION : Il faut utiliser le FQDN : nom pleinement qualifié du serveur

Pour cela créer un environnement pour la CA (avec CA.pl)
sinon faire un echo 01 > ca/serial
et lancer la commande:

openssl ca -config ./openssl.cf -out server.crt -infiles ./server.csr

openssl x509 -text -inserver.crt

Remarque: Dans certains articles il est dit de rajouter l'option -nodes pour éviter d'avoir à taper un mot de passe : la clé privée reste en clair .

La page d'authentification et la page "menu" .

Le boitier fonctionne selon trois modes :

Contenu de la page d'authentification.
La page d'accueil est un script CGI en perl qui réalise les operations suivantes:

Après ces opérations  le script se termine en chargeant une page "menu" ou en chargant la page demandée initialement.

Les CGI qui réalisent les opérations d'authentifications  et de présentation d'un menu applicatif sont disponibles  dans l'archive dans le répertoire portail .
Ce répertoire contient :
La partie authentification et menu à été réecrite par sylvain lhulier.

Remarque à propos de l'information de session.

  Les informations de sessions sont chargé dans le  hash "%session" par les pages d'authentications. Ce hash  doit pouvoir etre exploité par les handlers  perl des ressources protégées.
Il est opportun d'y stocker  le maximum d'information , il joue ainsi le role d'un cache et le portail n'aura plus à aller chercher des informations  auprès du serveur LDAP .


Les handlers


Un handler   est sollicité à chaque demande d'acces à une ressource protégée .
Il réalise les opérations suivantes:
  • Vérification de la présence du cookie
  • Retrouver les infos de session (le hash %session)
  • vérifier si l'utilisateur peut accéder à la ressource
  • Fabriquer l'entête (header) avec le DN suivie d'une chaîne de caractères (souvent le profil ou autre chose).
  • Faire la requête à la place de l'utilisateur  auprès de la ressource protégée et renvoyer la réponse à l'utilisateur.
nb : le handler peut aussi à l'occasion dérouler un scénario de connexion


 Exemple d'un handler  (extrait)


package My::egproxy_exemple;
use strict;
use vars qw(@ISA $VERSION);
use LWP::UserAgent ();
use Apache::URI();
use Apache::Constants qw(:common :response);
use Apache::Session::MySQL;
use Data::Dumper;
use MIME::Base64;
use Template;
use ReverseProxyConfig; # Variables de configuration (préfixées par ReverseProxyConfig)
$| =1;
#
my ($DEBUG,$NOTICE);
my $cook=$ReverseProxyConfig::cookie_name;
$DEBUG=1;
$NOTICE=1;
#
#
my $HEADER=1;
#
#
my $STOP_COOKIE=0;
#
@ISA = qw(LWP::UserAgent);
$VERSION = '1.00';

my $UA = __PACKAGE__->new;
$UA->agent(join "/", __PACKAGE__, $VERSION);

sub handler {
my($r) = @_;
print STDERR "handler je passe \n" if $DEBUG;
$r->handler("perl-script"); #ok, let's do it
$r->push_handlers(PerlHandler => \&proxy_handler);
return OK;
}
...

unless ($entete{'Cookie'}) {# il n y a pas de cookie il faut donc
# rediriger le client vers la page de login
print STDERR "pas de cookie ! pour $url \n" if $DEBUG;
$r->header_out(location =>"$ReverseProxyConfig::authentification_URL?op=c&url=$urlc_init");
return REDIRECT;
}
....

my $entete_spec = "Basic ";
my $ligne_h = $dn;
if ($complement) {
$ligne_h.="$complement";
}

my $hcode =encode_base64($ligne_h);
print STDERR "code avant encodage: $ligne_h\n" if ($DEBUG);
print STDERR "code apres encodage: $hcode\n" if $DEBUG;
$hcode=~ s/\n//g;
$entete_spec.=$hcode."\n";
$r->header_in('Authorization'=> $entete_spec);
 ...
##APPEL  a LWP pour faire la requete sur la ressource à protéger

my $response = $UA->request($request);
# my $lignex= $response->as_string();
# print STDERR "reponse $lignex \n";
$r->content_type($response->header('Content-type'));
#feed response back into our request_rec*
$r->status($response->code);
$r->status_line(join " ", $response->code, $response->message);
$response->scan(sub {
$r->header_out(@_);
});

if ($r->header_only) {
$r->send_http_header();
return OK;
}

my $content = \$response->content;
$r->content_type('text/html') unless $$content;
$r->send_http_header;
$r->print($$content || $response->error_as_HTML);
print STDERR "handler termine reponse envoyee \n" if ($DEBUG);

return OK;
}

 1;


(squelette egproxy_exemple.pm)

Générer un handler.

Il est possible d'utiliser un generateur de handler  qui à partir d'un modele (template)  et
d'un certain nombre de parametres génèrera un handler  personnalisé .
Le programme handler_genererator.pl   est d'une utilisation  très simple :
perl ./handler_generator.pl    >  mon_handler.pm 
Le mon_handler.pm devra ensuite etre placé dans le repertoire /opt/apache/My/

#!/usr/bin/perl -w
## ce programme genere un handler
## il s utilise comme ceci:
## perl ./handler_generator.pl > mon_handler.pm
##
##  germanlinux@yahoo.fr see http://lemonldap.sourceforge.net
##
use Template;
use strict;
 my $config = {};# option pour Template (ici aucunes)
my $input= "egproxy_modele.tpm";#le modele
### les options a passer
my  $vars= {
   log => 'DEBUG',# niveau de log : DEBUG NOTICE OU HEADER
   handler => 'egprogy_cpc' ,# nom du handler
   cookie => 1 ,#  interception du cookie 0/1
   url_prive => 'http://prive.appli.exemple' ,# ressource a proteger (RIP)
   url_publique => 'http://publique.appli.exemple' ,# ressource publique (RIP)
   port => 0,# si l appli travaille sur un port different de 80
   proxy => 0,# si un proxy s interpose entre le portail et l application
   controle => 'exemple',  # chaine de carateres a controler
   application => 'GER',# le code application
   # a partir d ici  ne rien modifier
   modele=> $input , # le nom  du modele
   generator => $0,# initialise automatiquement avec  le nom de ce script (ne pas modifier)
};
###
my $template = Template->new($config);
# process input template, substituting variables
$template->process($input, $vars)
             || die $template->error();

(handler-generator.pl)


Le module pour webmin

Ce module permet de visualiser l'état du reverse-proxy.
Il donne des informations sur :
-Les hôtes virtuels
-Le nombre de connexions simultanées

En outre , il est possible d'arrêter ou de démarrer le reverse-proxy par le biais de ce module.
Il est en téléchargement ici.
Installation du portail
 
Description des étapes d'installation du serveur apache , de la gestion de session , des pages d'authentification, d'une ressource protégée  et du menu applicatif.

a) Installation d'apache.

Il faut les sources d'apache, de mod_perl et de mod_ssl .
Commencer par decompacter les sources d'apache ,celles de mod_ssl et enfin celles de mod_perl.
Proceder à l'installation de mod_ssl  (suivre la doc de mod_ssl).
Aller dans le repertoire de source de mod_perl   et lancer la  commande suivante : 

perl Makefile.PL APACHE_PREFIX=/opt/apache APACHE_SRC=/opt/apache_1.3.27/src DO_HTTPD=1 \ USE_APACI=1 EVERYTHING=1 \
 APACI_ARGS='--enable-module=ssl --disable-module=negotiation --disable-module=autoindex  \
 --disable-module=imap --disable-module=userdir --disable-module=auth --disable-module=rewrite'

nb: le fichier  apache.txt du projet lemonlap contient le texte de la commande.
Procéder  depuis  le répertoire d'installation  d'apache à la génération des certificats .

Le fichier de configuration   d'apache  doit etre modifié pour  :
Délivrer le status étendu  du serveur :

Autoriser l'execution de script CGI  dans le répertoire "portail" :
ScriptAlias /portail/ "/opt/apache/portail/"

Inclure dans  le fichier httpd.conf le fichier lemon.conf

include conf/lemon.conf

Il ne reste plus qu'à lancer et tester le daemon httpd .

nb: Il est souhaitable d'installer le merveilleux navigateur lynx .

b) Installation de  la gestion   de session .

Le maintien  de la session est réalisée par les module standards Apache::Session ; déclinable sous  2 modes : le mode File ou le mode DBI .
Le mode "file"  permet de stocker les informations de session dans des fichiers du filesystem d'un boitier .
Avantages: Le temps d'acces est faible , technique simple.
Inconveniants: Les informations de session ne sont pas partageables entres differents lemonldap (sauf avec NFS) .
Le mode DBI  utilise une base de données pour stocker les sessions .
Avantages : Les informations de session sont accessibles par  plusieurs lemonldap   (autorise  la haute disponibilité et la répartition de charge) .
Inconveniants: on se retrouve en presence d'une couche et d'un omposant supplementaire . Il faut configurer et administrer une base de données.

Nous détaillerons l'installation du mode DBI .

Prérequits : une base de données   MySQL  (ça marche aussi avec postgreSQL) .
Création de la base et de la table
    La première opération a effectuer est la mise en place de table permettant de stocker les sessions.
 Pour cela il faut nous connecter au serveur MySQL avec l'identifiant administrateur MySQL en local :
 mysql -u root
    Nous allons créer une base dédiée aux sessions :
CREATE DATABASE portailSessions;
    Le nom de la base est portailSessions , il est tout à fait possible d'en choisir un autre (voir
section configuration du portail).
    La deuxième étape consiste en la création de la table en elle-même :
USE portailSessions;
CREATE TABLE sessions (
    id char(32) not null primary key,
    time timestamp,
    a_session text
);
Créations de l'utilisateur de la base de données
     Pour d'évidentes raisons de sécurité, le portail n'accède pas à la base de
données en tant qu'administrateur. Un utilisateur de MySQL va donc être
créé pour les scripts du portail.

GRANT ALL ON portailSessions.* TO portail IDENTIFIED BY 'mot_de_passe';

Cette instruction permet de créer un utilisateur portail qui a tous les droits sur la base portailSessions.
Cet utilisateur se connectera avec le mot de passe indiqué. L'utilisateur peut se connecter depuis n'importe quelle ordinateur connu
du DNS du serveur de la base de données. Attention à ce point : les ordinateurs portail doivent étre d´eclarées dans un DNS et ce DNS doit être indiqué dans le fichier /etc/resolv.conf du serveur de base de données.

nb: ne pas hésiter à tester la connexion à la base de données car la majorité des problèmes vient de ce composant (connexion, droits de l'utilisateur)

 
c) Installation des pages d'authentifications.
Les fichiers du portail se découpent de la manière suivante :
   Ils sont au nombre de deux : accueil.pl et applications.pl
  Ils assurent respectivement la fonction d'authentification et la construction de la page "menu" des applications.
   Le fichier ReverseProxyConfig.pm comporte l'affectation de nombre de variables de configuration du portail.
   Le fichier applications.xml comporte la description de l'arborescence des applications dans un format XML.
   Les fichier de patron (template) ont pour extention .thtml et concernent
  la génération du HTML.
   Le fichier style.css est la feuille de style des pages HTML générées.
   Le fichier fond magellan.jpg est l'image de fond des pages HTML, il est nommée dans la feuille de style.
      Les fichiers style.css et fond magellan.jpg doivent être à la racine
du serveur web. Dans le cadre d'une installation d'Apache dans le répertoire
/opt/apache il s'agit donc du répertoire /opt/apache/htdocs
     Les scripts Perl accueil.pl et applications.pl ainsi que le module de configuration ReverseProxyConfig.pm doivent être placés dans un répertoire qui leur est propre. Ce répertoire peut par exemple être  /opt/apache/portail
Ce répertoire doit faire l'objet d'une directive Apache dans le fichier de configuration httpd.conf afin que les scripts CGI y soient exécutés :
ScriptAlias /portail/ "/opt/apache/portail/"
Le fichier de configuration des applications applications.xml peut-être placé dans n'importe quel répertoire, pourvu que son chemin complet soit indiqué correctement dans le module de configuration ReverseProxyConfig.pm (voir section appropriée). Par exemple , il a été mis dans le répertoire  des scripts Perl /opt/apache/portail.
 Les fichiers patrons de HTML (templates) peuvent peut-être placé dans n'importe quel répertoire, pourvu que ce répertoire soit indiqué correctement dans le module de configuration ReverseProxyConfig.pm (voir section appropriée). Ici , ils ont été mis dans /opt/apache/portail/templates

      La configuration du portail s'effectue dans le fichier ReverseProxyConfig.pm qui est un module Perl chargé par les deux scripts du portail. Il contient la définition d'un certain nombre de variables qui font office de paramètres de configuration.

   LDAP

$ldap_serveur: nom ou adresse IP de l'hôte du serveur LDAP
$ldap_port : port du serveur LDAP
$ldap_admin dn : identifiant de l'administrateur LDAP
$ldap_admin pd : mot de passe de l'administrateur LDAP
$ldap_base :  base de recherche dans le LDAP
$ldap_filtre :  filtre  de recherche dans le LDAP

 MySQL

$mysql_datasource: ceci est la s´equence qui indique la manière de contacter la base de données. Le paramètre dbname indique le nom de la base de données (celle créée dans la section 2) et host indique le nom ou l'adresse IP de l'hôte.
$mysql_username: identifiant de connexion (celui créé dans la section 2)
$mysql password: mot de passe pour l'identifiant en question

 URL des pages

Ces informations sont utilisées lors des redirections HTTP.
$applications_list URL : URL de la page comportant la liste des applications
$authentification URL : URL de la page d'authentification

 Moteur de templates

$template dir : répertoire o`u trouver les patrons (templates)
$template config : options passées au moteur de templates (rien
       à modifier a priori)

 Cookie
 
$cookie name : nom du cookie (lemon)
$cookie domain : domaine du cookie (.appli.fr)
$cookie path : chemin du cookie (/)

 Fichier XML des applications

$fichier applications: chemin complet du fichier XML comportant la description arborescente des applications.

 Parser XML:Simple

     @xlm_simple_options: options de l'analyseur XML dans les cas courants (rien à modifier a priori)
     @xlm_simple_options codiques: options de l'analyseur XML dans le cas des codiques (Utilisé en interne au ministère des finances)
ATTENTION  : Suivant la distribution utilisée , la casse des options peut changer.

Installation d'une nouvelle ressource  protégée .
Il vous faut : une adresse IP  à affecter au boitier , Un attribut LDAP discreminant , un code application .

 A) Affectation d'une nouvelle adresse IP .
Pour une RedHat ou une Mandrake le plus simple est de  créer un fichier nommé ifcfg-eth0:nn   dans le répertoire /etc/sysconfig/network-scripts.
Ce fichier contient  les lignes suivantes :

IPADDR=10.nn.nn.nn
NETMASK=255.255.255.0



Puis il suffit de relancer le réseau par : service network restart

B) Création du virtual host d'apache :

<virtualhost  10.ip.ip.ip>
ServerName ressource.appli.exemple
perlmodule My::egproxy_exemple
perltranshandler My::egproxy_exemple
loglevel debug
</virtualhost>

C )  Modifications  du   DNS .

Le navigateur du client doit  pouvoir  resoudre   l'url "publique"  de la ressource :
exemple : si votre   ressource protégée doit pouvoir etre atteinte par le lien :
http://ressource.appli.exemple 

Alors votre DNS doit ressoudre cette url par l'alias de l'adresse IP du boitier .
(exemple extrait d'un fichier de named )

ressource.appli.exemple.        IN      A       10.nn.nn.nn


Le boitier lemonldap doit lui (et lui seul)  pouvoir aller sur la ressource protégée :
ressource_protegee.appli.exemple  .

 Pour   cela le DNS doit lui retourner la RIP grace à :

ressource_protegee.appli.exemple.        IN      A       ma.rip.protegee.nn

ou par une ligne de son fichier host .

ma.rip.protegee.nn  ressource_protegee.appli.exemple

D ) Mise en place du handler .
Il faut  maintenant mettre dans le répertoire apache/My    le handler associé au virtual host
Le handler est un package perl   (monhandler.pm)   qu'il convient de configurer .

Le handler est chargé de :
 Il y a deux points importants à connaitre pour configurer le handler :
E) Relation entre une application , le portail et le LDAP.

Je décris ici le mode de fonctionnement le plus souple à gerer et le plus facile à mettre en place .

Au niveau du LDAP il convient d'utiliser un attribut multivalué  contenant :
monattribut: code_application;profil
exemple :   CODE1;1S
Le code application est une chaine de caractere qui sera la clé du hash  de session , le profil sera sa valeur .
A la connexion initilale de l'utilisateur la page accueil.pl va chercher le contenu de cet atribut et va enrichir le hash de session par le couple $session{'code_application'} = "profil" .

Exemple :  $session{'CODE1'} = '1S'

Ce  code applicatif est à reporter dans le fichier portail/applications.xml  . Cet ajout permettra d'afficher une ligne dans la page de menu  sous la rubrique voulue .

Exemple :

 <menu>
       <rubrique id="rub1"
               name="Applications  diverses">
          <appli id="code_application"
                 name="le_nom_de_l_appli"
                 url="http://nom.appli.exemple/"
                 >
          </appli>
       </rubrique>
</menu>
applications.xml (END)

Le handler contiendra pour sa part les lignes suivantes :

my  $etat;
my $complement;
#################  controle sur une location #############
                if ($url =~ /exemple/ ) {
                    if ($session{'code_application}) {
                        $etat =1;
                        my $suite=$session{'code_application'};
                        $complement=":$suite";
                        }
                      }
my $entete_spec = "Basic ";
my $ligne_h = $dn;
if ($complement) {
$ligne_h.="$complement";
}

Le header  rajouté est de la forme :

Authorization :Basic dWlkPWVnZXJtYW4tY3Asb3U9cGVyc29ubmVzLG91PWRnY3Asb3U9bWVmaSxvPWdvd
XYsYz1mcjoxUw==

code avant encodage: uid=egerman-cp,ou=personnes,ou=dgcp,ou=mefi,o=gouv,c=fr:1S
code apres encodage: dWlkPWVnZXJtYW4tY3Asb3U9cGVyc29ubmVzLG91PWRnY3Asb3U9bWVmaSx
vPWdvdXYsYz1mcjoxUw==


Installation des packages Perl

Le boitier lemonldap utilise un certain nombre de package perl à installer par le procedé habituel :

perl Makefile.PL
make
make install .

Pour simplifier l'installation on peut utiliser le script suivant : install_rpm.pl  , ce programme se parametre avec le  fichier install.conf   qui contient les lignes suivantes :

CGI,/archive/rpm/perl-CGI-2.81-88.i386.rpm
MIME::Base64,/archive/rpm/perl-MIME-Base64-2.12-6.i386.rpm
XML::Simple,/archive/rpm/XML-Simple-2.09-1mdk.noarch.rpm
HTML::Tagset,/archive/rpm/perl-HTML-Tagset-3.03-28.noarch.rpm
HTML::Parser,/archive/rpm/perl-HTML-Parser-3.26-17.i386.rpm
LWP::UserAgent,/archive/rpm/perl-libwww-perl-5.65-6.noarch.rpm
Apache::Session::MySQL,/archive/rpm/Apache-Session-1.54-1german.noarch.rpm
AppConfig,/archive/rpm/AppConfig-1.55-1german.noarch.rpm
Template,--nodeps  /archive/rpm/Template-Toolkit-2.08-1german.noarch.rpm
Convert::ASN1,/archive/rpm/Convert-ASN1-0.18-1mdk.noarch.rpm
Net::LDAP,--nodeps /archive/rpm/perl-ldap-0.2701-1mdk.noarch.rpm


Une   ligne est de la forme :   <Nom du "use"  utilisé  par perl>  ","   < argument de la commande rpm>


Modification des applications

Pour pouvoir fonctionner  sous le portail une application doit  savoir récuperer l'entete et le décoder

Exemple en perl :

#!/usr/bin/perl -w
use strict;
use CGI;
use Data::Dumper;
use MIME::Base64;
my $encode;
my $decode;
my $r=shift;
my %head= $r->headers_in();
($encode) =$head{'Authorization'}=~ /basic(.+)/i;
$decode =decode_base64($decode);



Exemple en PHP :

function lire_entete()
    {
     // récupération de l'en-tête http renvoyé par le portail applicatif
     // découpage de la chaîne xml =>     $sParamètre[0] -> schéma ldap de base
     //                                   $sParamètre[1] -> identité de l'utilisateur
     //                                   $sParamètre[2] -> habilitations

     $sHeaders = getallheaders();
     while (list($sEntete, $sValeur) = each($sHeaders))
       {
        if ($sEntete=="Authorization")
          {
           $l=strlen($sValeur);
           $sModif=substr($sValeur,6,$l);
           $sDecode=base64_decode($sModif);
           $sParametre=decoupe_chaine($sDecode,":");
          }
       }
     return ($sParametre);
    }


Exemple en JAVA :

A COMPLETER
 
Monitoring de lemonLDAP

La surveillance d'un boitier peut etre réalisée  très simplement avec l'outils nagios comme n'importe quel service web.

Des statistiques supplementaires peuvent etre obtenues  en utilisant une RRD  (Round Robin Database) avec cacti comme
frontal .

Pour ces deux outils , l'usage du "status extended"  du serveur apache est  utile. Ceci n'est pas propre à lemonLDAP et il convient de se rapporter à la documentation d'apache, de  nagios et cacti .

Le lemonLDAP n'est qu'un serveur apache . Ainsi ses log sont ceux d'un serveur apache (apache/logs) .

A FAIRE :

De le documentation en francais  ou en anglais (merci à tous) .
Un meilleur système de log : un fichier par hôtes virtuels.
Un générateur de handler : utilisation des templates.
Des packages  debian et des rpm.
Gestion de la configuration par l'utilisation de modulr.
Introduction  du protocole SAML   dans   l'architecture .
 






 lemon.html0100644040463302611160000007056110223237017014166 0ustar germanlinuxlemonldap


SourceForge.net Logo

lemonLDAP

Le site de sourceforge

Le projet lemonldap

lemonLDAP

**Toujours chercher le problème a la source...
** Toujours aller chercher les infos à la source...
** La source, c'est la connaissance.
** Use your brain..





Responsable du projet: eric GERMAN germanlinux@yahoo.fr et xavier Guimard xavier.guimard@laposte.net

Bienvenue sur le site du projet lemonLDAP :   Reverse-proxy d'authentification LDAP.

Lemonldap est un système SSO sous GPL utilisé par des grands ministères comme le MINEFI , La Défense , La Justice et des organismes comme la RATP.

Principes : Le reverse-proxy lemonLDAP est un service réseau qui est un point d'entrée unique de toutes les requêtes HTTP des différentes applications web mises à disposition et qui en relation avec un serveur LDAP met en place un mécanisme unique d'authentification des utilisateurs et de contrôle d'accès à ces applications.

Après authentification de l'utilisateur en HTTPS auprès de l'annuaire LDAP, le reverse-proxy met en cache des attributs LDAP de l'utilisateur afin de contrôler l'accès de l'utilisateur aux différentes applications web .

Ces applications web sont dénommées  ressources protégées. Le dialogue entre le reverse-proxy et les applications est réalisé par le biais d'un entête (HEADER) AUTHORIZATION. le header  AUTHORIZATION est rajouté à chaque requête et il contient  le DN (distinguished name) de l'utilisateur suivi du profil applicatif .


Architecture.





Le "reverse-proxy" lemonLDAP n'est pas un logiciel en tant que tel mais plutôt la combinaison des composants bien connus  : Apache, mod_perl,mod_ssl,MySQL,webmin et les Net::LDAP API de graham Barr

La clé de voute du système est le serveur web apache , compilé et configuré de manière optimisée.
Autour de ce serveur on trouvera un handler apache par ressource à protéger . Un virtual host pourra être assigné à la ressource pour encore plus cloisonner les applications. Deux CGI réalisent l'authentification et enfin une interface sous webmin  administre le système global. L'ensemble du système ou "boitier" fonctionne sous GNU/Linux.

Lemonldap n'est qu'une configuration du serveur APACHE et rien d'autre. Il est donc possible d'utiliser tous les composants , outils ou plug-in du monde apache .

Modules du CPAN

Lemonldap se présente sous la forme d'une série de modules perl à télécharger sur le CPAN . Les modules sont organisés de la manière suivante.

Lemonldap (répertoire racine)

La session et les caches

La session est maintenue entre le reverse-proxy et l'utilisateur par un cookie de session qui contient un numéro de session faisant référence à un fichier stocké dans le système de fichier ou à une entrée dans une base de données ou en mémoire. Du point  de vue de mod_perl et mod_session , les informations de session ne sont qu'un hash sérialisé et stocké de manière permanente.

Apache::Session propose plusieurs méthodes pour gérer les sessions :

  1. Le mode "file"  permet de stocker les informations de session dans des fichiers du filesystem d'un boitier .
    Avantages: Le temps d'acces est faible , technique simple.
    inconvénients: Les informations de session ne sont pas partageables entres différents lemonldap (sauf avec NFS) .

  2. Le mode MySQL et memcached :
    Avantages : Les informations de session sont accessibles par  plusieurs lemonldap   (autorise  la haute disponibilité et la répartition de charge) .
    inconvénients: on se retrouve en présence d'une couche et d'un composant supplémentaire . Il faut configurer et administrer une base de données ou un serveur memcached.

3 niveaux de caches sont proposés :

L'empilement de tous ces caches permet d'obtenir des performances élevées.

La fonction Portail d'authentification.

Le boitier lemonldap fonctionne selon trois modes :

Contenu des pages d'authentification et de « menu » applicatif.
La page d'accueil est un script CGI/perl accueil.pl qui réalise les operations suivantes:

Après ces opérations  le script se termine en chargeant une page "menu" ou en chargeant la page demandée initialement.

Les CGI qui réalisent les opérations d'authentifications  et de présentation d'un menu applicatif sont disponibles sur le CPAN .

Des exemples sont proposés en fonction du mode d'authentification désiré (ldap/nt/certificat client ) .

Le menu applicatif est présenté par le script CGI/perl applications.pl

Le fichier applications.xml permet de parametrer le menu présenté à l'utilisateur. Ce fichier devient dans la version 1.0 de lemonldap le fichier principal de configuration.

On trouvera en plus dans le répertoire portail :

Les handlers

Un handler   est sollicité à chaque demande d'accès à une ressource protégée .
Il réalise les opérations suivantes:

nb : le handler peut aussi à l'occasion dérouler un scénario de connexion.

A partir de la version lemonldap 1.0 Il est possible d'utiliser mod_proxy ou mod_rewrite (ou n'importe quel module d'apache) dans la suite du traitement de l'url .

Exemple: dans httpd.conf

Avec mod_proxy

perlmodule Lemonldap::Handler
<virtualhost 10.ip.ip.ip>
ServerName ressource.appli.exemple
PerlInitHandler Lemonldap::Handler
ProxyPass / http://serveur-réel/
ProxyPassRProxyPass / http://serveur-réel/
ProxyPassReverse / http://serveur-réel/
</virtualhost>


Ou avec mod_rewrite 


perlmodule Lemonldap::Handler
<virtualhost 10.ip.ip.ip>
ServerName ressource.appli.exemple
PerlInitHandler Lemonldap::Handler
RewriteRule ^/(.*)$ http://serveur-réel/$1 [P]
</virtualhost>

Et enfin avec le proxy intégré avec lemonldap

perlmodule Lemonldap::Handler
<virtualhost 10.ip.ip.ip>
ServerName ressource.appli.exemple
PerlInitHandler Lemonldap::Handler
PerlSetVar LemonldapEnableproxy 1
</virtualhost>


Installation.

a) Installation d'apache.

Si vous êtes un heureux utilisateur de la DEBIAN vous n'avez rien à faire , le serveur Apache de la DEBIAN est celui utilisé par lemonldap .

Pour les autres distributions vous devez disposer d'un serveur apache en version 1.3.nn . Lemonldap est compatible avec apache 2 mais non certifié.

Pour installer apache 1.3.n suivre ces instructions .

b) Configuration d'apache.

Le fichier de configuration   d'apache  doit etre modifié pour  :
Délivrer l'extended statut du serveur par la ligne
ExtendedStatus On


Autoriser l'execution de script CGI  dans le répertoire "portail" :
ScriptAlias /portail/ "/opt/apache/portail/"

Ou encore mieux , pour le faire tourner sous Apache::Registry

alias /portail/ "/opt/apache/portail/"

<Location /portail>
    SetHandler perl-script
    PerlHandler Apache::Registry
    Options +ExecCGI
    PerlSendHeader On
</Location>

Il est recommandé de regrouper les directives effarantes à lemoldap dans un fichier distinct lemon.conf ou lemon.cfg puis d'ajouter dans httpd.conf

include conf/lemon.conf

ou

include conf/lemon.cfg

c) Installation du système de gestion de la session.



d) Installation des pages d'authentifications.

Les fichiers du portail se découpent de la manière suivante :

Ils sont au nombre de deux : accueil.pl et applications.pl
Ils assurent respectivement la fonction d'authentification et la construction de la page "menu" des applications.

Dans la dernière version lemonldap , il est possible d'utiliser les modules 'portal' du CPAN .

Pour installer un module du CPAN :

Installez Lemonldap::Portal::Standard

Le fichier ReverseProxyConfig.pm comporte l'affectation de nombre de variables de configuration du portail.

Dans la dernière version lemonldap , il est possible d'utiliser les modules 'config' du CPAN .

Installez Lemonldap::Config::Parameters.

  Le fichier applications.xml comporte la description de l'arborescence des applications dans un format XML et tous les parametres du lemondap

  Les fichier de patron (template) ont pour extention .thtml et concernent
  la génération du HTML.

  Le fichier style.css est la feuille de style des pages HTML générées.

  Le fichier fond magellan.jpg est l'image de fond des pages HTML, il est appelé dans la feuille de style.

     Les fichiers style.css et fond magellan.jpg doivent être à la racine du serveur web. Dans le cadre d'une installation d'Apache dans le répertoire /opt/apache il s'agit donc du répertoire /opt/apache/htdocs
     Les scripts Perl accueil.pl et applications.pl ainsi que le module de configuration ReverseProxyConfig.pm doivent être placés dans un répertoire qui leur est propre. Ce répertoire peut par exemple être  /opt/apache/portail

e) Configuration du lemondap.

Il y 3 modes de configuration du lemonldap

Le mode par fichiers de paramètres (ancienne version) .

Le mode par fichier XML / cache IPC (nouvelle version).

Le mode par fichier XML / cache IPC et CENTRALISEE (nouvelle version )

f) Installation d'une nouvelle application sous le portail.

Il vous faut : une adresse IP  à affecter au boitier , Un attribut LDAP discreminant , un code application .

IPADDR=10.nn.nn.nn
NETMASK=255.255.255.0

Puis il suffit de relancer le réseau par : service network restart

<virtualhost  10.ip.ip.ip>
ServerName ressource.appli.exemple
perlmodule My::egproxy_exemple
perltranshandler My::egproxy_exemple
loglevel debug
</virtualhost>

g ) Mise en place du handler .


Il faut  maintenant mettre dans le répertoire apache/My    le handler associé au virtual host
Le handler est un package perl   (monhandler.pm)   qu'il convient de configurer .

Le handler est chargé de :

Il y a deux points importants à connaître pour configurer le handler :

Avec la nouvelle version de lemonldap , il est possible d'utiliser qu'un seul header qui gérera plusieurs applications . C 'est dynamiquement que s'appliqueront les règles de résolution . Le droit d'accès , la réécriture des URL et la confection des entêtes se feront à partir du fichier XML de configuration.

La gestion des profils .

Toutes les requêtes à destination d'une ressource protégée passent par lemonldap . Celui ci doit pouvoir déterminer si l'utilisateur est autorisé à aller sur la ressource. Pour cela le handler associé à l'application recherche dans les informations de session l'élément qui fait autorité (un attribut ldap , un groupe ..) .

Je décris ici le mode de fonctionnement le plus souple à gérer et le plus facile à mettre en place .

Au niveau du LDAP il convient d'utiliser un attribut multivalué  contenant :
monattribut: code_application;profil
exemple :   CODE1;1S
Le code application est une chaîne de caractère qui sera la clé du hash  de session , le profil sera sa valeur .
A la connexion initiale de l'utilisateur la page accueil.pl va chercher le contenu de cet attribut et va enrichir le hash de session par le couple $session{'code_application'} = "profil" .

Exemple :  $session{'CODE1'} = '1S'


Le header  ajouté sera de la forme :

Authorization :Basic dWlkPWVnZXJtYW4tY3Asb3U9cGVyc29ubmVzLG91PWRnY3Asb3U9bWVmaSxvPWdvd
XYsYz1mcjoxUw==

code avant encodage: uid=egerman-cp,ou=personnes,ou=dgcp,ou=mefi,o=gouv,c=fr:1S
code après encodage: dWlkPWVnZXJtYW4tY3Asb3U9cGVyc29ubmVzLG91PWRnY3Asb3U9bWVmaSx
vPWdvdXYsYz1mcjoxUw==

L'autre mode de gestion de rôle peut être réalisé par le rattachement des utilisateurs à des groupes LDAP .

Dans ce cas le hash de session doit contenir un booléen précisant l'appartenance au groupe (ou la liste des groupes).



Modifications des applications

Pour pouvoir fonctionner  sous le portail une application doit  savoir récuperer l'entete et le décoder

Des exemples en perl / php / java

Feuille de route




mem.html0100644040463302611160000000630610173725615013640 0ustar germanlinuxlemonldap

Memcached

1) installation de MemoryCached.

memorycahed est un système de stockage de données utilisant la memoire de serveurs dédiés ou contributifs (eg. serveur web). Un serveur web mobilise plus de CPU que de mémoire . Il est intéressant de recycler cette mémoire disponible pour faire du cache.

Memorycached à besoin de la librairie LibEvent pour fonctionner. Cette librairie gère les entrées/sorties de manière pertinante et non bloquante. L'api libevent fournit un mécanisme pour exécuter une fonction de "callback" quand un événement spécifique se produit sur un descripteur de fichier ou après qu'un timeout a été atteint. En outre, libevent implémente également des "callback" dus aux signaux . libevent est censé remplacer la gestion standard de la file d'attente utilisée dans les serveurs . Une application doit juste appeler l'event_dispatch() et puis ajouter ou enlever des événements dynamiquement sans devoir changer la gestion de la file d'attente. installation de libevent à partir du code source: 

./configure
make 
make install

installation de memcached à partir du code source: 

./configure
make 
make install

2) Lancement de memcached. Le lancement de memcached se fait par la ligne de commande: 

./memcached -d -m 2048  -p 11211

(2 giga de mémoire port standard 11211)

3) Installation de l'API perl Cache-Memcached. Il faut recupere sur le CPAN le module Cache::Memcached puis faire un : 

perl Makefile.PL
make 
make  install

Dépendance: le module Cache-Memcached utilise le module String::CRC32

4) Sécurisation par iptables (pour éviter des telnets intempestifs) . 

iptables -A INPUT -p tcp  --destination-port 11211 -s  10.ip.ip.ip  -j ACCEPT
iptables -A INPUT -p tcp  --destination-port 11211 -s localhost     -j ACCEPT
iptables -A INPUT -p tcp  --destination-port 11211   -j DROP

RETOUR http://lemonldap.sourceforge.net



mysql.html0100644040463302611160000000633210173457725014232 0ustar germanlinuxlemonldap

Installation de la session gérée par MySQL.

Nous détaillerons l'installation du mode DBI .

Prérequits : une base de données   MySQL  (ça marche aussi avec postgreSQL) .
Création de la base et de la table
    La première opération a effectuer est la mise en place de table permettant de stocker les sessions.
 Pour cela il faut nous connecter au serveur MySQL avec l'identifiant administrateur MySQL en local :
 mysql -u root
    Nous allons créer une base dédiée aux sessions :
CREATE DATABASE portailSessions;
    Le nom de la base est portailSessions , il est tout à fait possible d'en choisir un autre (voir
section configuration du portail).
    La deuxième étape consiste en la création de la table en elle-même :
USE portailSessions;
CREATE TABLE sessions (
    id char(32) not null primary key,
    time timestamp,
    a_session text
);
Créations de l'utilisateur de la base de données

     Pour d'évidentes raisons de sécurité, le portail n'accède pas à la base de
données en tant qu'administrateur. Un utilisateur de MySQL va donc être
créé pour les scripts du portail.

GRANT ALL ON portailSessions.* TO portail IDENTIFIED BY 'mot_de_passe';

Cette instruction permet de créer un utilisateur portail qui a tous les droits sur la base portailSessions.
Cet utilisateur se connectera avec le mot de passe indiqué. L'utilisateur peut se connecter depuis n'importe quelle ordinateur connu
du DNS du serveur de la base de données. Attention à ce point : les ordinateurs portail doivent étre d´eclarées dans un DNS et ce DNS doit être indiqué dans le fichier /etc/resolv.conf du serveur de base de données.

nb: ne pas hésiter à tester la connexion à la base de données car la majorité des problèmes vient de ce composant (connexion, droits de l'utilisateur)



RETOUR http://lemonldap.sourceforge.net



param.html0100644040463302611160000000560010173725637014162 0ustar germanlinuxlemonldap

Mode fichier de paramètres

     La configuration du portail s'effectue dans le fichier ReverseProxyConfig.pm qui est un module Perl chargé par les deux scripts du portail. Il contient la définition d'un certain nombre de variables qui font office de paramètres de configuration.

   LDAP

$ldap_serveur: nom ou adresse IP de l'hôte du serveur LDAP
$ldap_port : port du serveur LDAP
$ldap_admin dn : identifiant de l'administrateur LDAP
$ldap_admin pd : mot de passe de l'administrateur LDAP
$ldap_base :  base de recherche dans le LDAP
$ldap_filtre :  filtre  de recherche dans le LDAP

 MySQL

$mysql_datasource: ceci est la s´equence qui indique la manière de contacter la base de données. Le paramètre dbname indique le nom de la base de données (celle créée dans la section 2) et host indique le nom ou l'adresse IP de l'hôte.
$mysql_username: identifiant de connexion (celui créé dans la section 2)
$mysql password: mot de passe pour l'identifiant en question

 URL des pages

Ces informations sont utilisées lors des redirections HTTP.
$applications_list URL : URL de la page comportant la liste des applications
$authentification URL : URL de la page d'authentification

 Moteur de templates

$template dir : répertoire où trouver les patrons (modèles/templates)
$template config : options passées au moteur de templates (rien
       à modifier a priori)

 Cookie
 
$cookie name : nom du cookie (lemon)
$cookie domain : domaine du cookie (.appli.fr)
$cookie path : chemin du cookie (/)

 Fichier XML des applications

$fichier applications: chemin complet du fichier XML comportant la description arborescente des applications.

 Parser XML:Simple

     @xlm_simple_options: options de l'analyseur XML dans les cas courants (rien à modifier a priori)
     @xlm_simple_options codiques: options de l'analyseur XML dans le cas des codiques (Utilisé en interne au ministère des finances)
ATTENTION  : Suivant la distribution utilisée , la casse des options peut changer.


RETOUR http://lemonldap.sourceforge.net

xml.html0100644040463302611160000000554010175714761013663 0ustar germanlinuxlemonldap

Mode fichier XML / cache.



Le principe est d'utiliser un fichier XML pour stocker la configuration. Le traitement d'un fichier XML est lourd. Il était hors de question d'aller lire et de 'parser' un fichier XML à chaque requête . La solution viens de la mise en cache du résultat du traitement du fichier XML . Cette mise en cache se fait par le module Lemonldap::Config::Parameters.

Le cache utilisé est de type IPC (module IPC::Shareable) .



Syntaxe proposée : (voir aussi le Dictionnaire )

<domain name="appli.cp"

cookie="lemontest"

path ="/"

templates_dir="/opt/apache/portailtest/templates"

templates_options = "ABSOLUTE => '1', INCLUDE_PATH => 'templates_dir'"

login ="http://cpportail.appli.cp/portailtest/accueil_obj.pl"

menu= "http://cpportail.appli.cp/portailtest/application_new.pl"

ldap_server ="ip.ip.ip.ip"

ldap_port="389"

DnManager= "cn=Directory Manager"

passwordManager="secret"

ldap_branch_people="ou=mefi,o=gouv,c=fr"

session="memcached" ;# type de session utilisée

>

</domain>

<cache type="IPC" name="CONF" ttl="1000"> ; # On indique au module de Config::Parameters de mettre en cache IPC la configuration

</cache>

<session name="memcached"

type="memcached"

servers="['ip.ip.247.30:11211']">

</session>



RETOUR http://lemonldap.sourceforge.net