Le site de sourceforge
|
|
|
|
Le site de sourceforge |
**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
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 .
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 est EVOLUTIF : Il ne fait qu'intégrer des composants robustes et connus et vous permet de rajouter des « plug-in » en fonction de votre système d'information.
Lemonldap est SCALABLE: Il est possible de rajouter autant que de besoin de reverse-proxy lemonldap grâce à son système de sessions partagées dans une base de données ou en ferme de serveurs mémoires . La répartition de charge peut être assurer très simplement par le DNS ou d'une manière fine par un équipement de niveau 7 ISO (4 DOD) .
Lemonldap est SOUPLE . Il s''intègre dans votre architecture existante et s'adapte à vos applications. Son proxy interne basé sur libwwperl permet de personnaliser l'accès à vos applications.
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 .
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)
Config
Parameters (gère les paramètres de base de lemonldap)
Handler
IpcSharedUsers (gère le cache de niveau 2 IPC des handlers)
Intrusion (gère les actions à mener en cas d'accès
non autorisé)
Config (gère l'accès à la configuration
centralisée)
Portal
Standard (propose une pile standard d'authentification)
Authntsso (vérifie l'authentification aupres d'un système
NT )
Sslsso (propose une authentification forte par certificat client)
Cda (propose le Cross Domain Authentification)
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 :
Apache::Session::File : session stockée dans le file system
Apache::Session::MySQL : session stockée dans une base de données MySQL
Apache::Session::MemoryCached : session stockée dans un serveur Memcached
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)
.
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 :
Le cache de niveau 1 : C'est un cache système qui détecte si la requête sur un fils apache provient du client précédent .
Le cache de niveau 2 : C'est un cache IPC qui permet à tous les fils d'un serveur apache sur une même machine de retrouver les informations de session . Il est utilisé aussi pour mettre en cache la configuration des lemonldap.
Le cache de niveau 3 : Il stocke la session de manière permanente par le biais d' Apache::Session .
L'empilement de tous ces caches permet d'obtenir des performances élevées.
Le boitier lemonldap fonctionne selon trois modes :
Le mode direct : l'utilisateur veut accéder à une application protégée , il n'est pas authentifié : Le système lui réclame son nom d'utilisateur et son mot de passe et après vérification positive, l'utilisateur est re-dirigé directement vers la ressource protégée.
Le mode selection: L'utilisateur accède à une page menu listant l'ensemble des applications sur lesquelles il possède les autorisations d'accès. La page menu est considérée comme une ressource protégée . Le menu est un CGI hébergé par le serveur Apache du système (cela n'est pas une obligation) .
Le mode time-out : L'utilisateur est resté inactif apres s'etre connecté . Il est automatiquement déconnecté et se retrouve dans le cas de figure "mode direct"
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:
Vérification de l'identité de l'utilisateur.
Chargement auprés du LDAP des profils applicatifs.
Création des informations de session
Création du cookie de session
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 :
Un répertoire de templates
Une feuille de style
Un handler est
sollicité à chaque demande d'accès à 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.
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>
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 .
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
Les scripts Perl.
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 :
Décompresser l'archive (tar -zxvhf mon_archive.tgz )
Lancer depuis le répertoire décompressé :
perl Makefile.PL
make && make install
Installez Lemonldap::Portal::Standard
Le module Perl de configuration.
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.
La configuration des applications.
Le fichier applications.xml comporte la description de l'arborescence des applications dans un format XML et tous les parametres du lemondap
Les patrons de HTML.
Les fichier de patron (template) ont pour extention .thtml
et concernent
la génération du HTML.
La feuille de style.
Le fichier style.css est la feuille de style des pages HTML générées.
L'image de fond.
Le fichier fond magellan.jpg est l'image de fond des pages HTML, il est appelé dans la feuille de style.
Répartition dans les répertoires
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
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 )
Il vous faut : une adresse IP à affecter au boitier , Un attribut LDAP discreminant , un code application .
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
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>
Modifications du
DNS .
Le navigateur du client doit pouvoir
résoudre l'url "publique" de la
ressource :
exemple : si votre ressource protégée
doit pouvoir être atteinte par le lien
:
http://ressource.appli.exemple
Alors votre DNS
doit résoudre cette url par l'alias de l'adresse IP du
boîtier .
(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
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 :
vérifier que l'utilisateur est bien authentifier
vérifier que l'utilisateur est habilité à aller sur l'application
Rajouter le header authorization contenant le DN et le profil .
Faire la requête sur la ressource protégée à la place de l'utilisateur et lui retourner la réponse de l'application
Il y a deux points importants à connaître pour configurer le handler :
Quel est l'url de la ressource publique et l'url de la ressource protégée ?
Quel est la clé du hash de session qui permet d'autoriser et de profiler l'utilisateur?
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.
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).
Pour pouvoir fonctionner sous le portail une application doit savoir récuperer l'entete et le décoder
Des exemples en perl / php / java
Une nouvelle architecture de log
Intégration de SAML
Définition d'un modèle XML pour les profils et la session
Utilisation du module plug-in de perl