Prérequis:

• Configuration des dépôts fws et epel (voir extras_repo)

La première étape est l'installation des différents RPM. Il faut activer le dépôt epel pour les dépendances

yum --enablerepo=epel --enablerepo=fws install smeserver-lemonldap-ng

Une fois les RPMS installés, il suffit de re-configurer apache:

signal-event webapps-update

Les domaines virtuels nécessaire à la gestion de LemonLDAP sont créés automatiquement:

• https://sso-manager.domain.tld permet d'accéder à la console de gestion de LemonLDAP. Par défaut, cette partie est protégée par une authentification basique HTTP, et demande le login admin du serveur
• https://auth.domain.tld est le portail utilisateur
• https://soapsso.domain.tls est le domaine utilisé pour les requêtes SOAP (utilisé par les handlers distants)

La protection d'une application Web se passe en plusieurs étapes

1. Déclaration du virtualhost dans la console de gestion de LemonLDAP, et configuration des règles souhaitées (ou simplement ajout des règles si le virtualhost est déjà déclaré)
2. Ajout de la ligne “PerlHeaderParserHandler My::Package” dans la configuration apache (soit au niveau du vhost, soit dans une section <Directory>)
3. Configuration de l'application (si nécessaire)

Pour protéger un domaine virtuel par LemonLDAP sur un serveur SME (ou une iPasserelle), il faut utiliser les templates fournit par le paquet smeserver-webapps-common:

db domains setprop myapp.domain.tld TemplatePath WebAppVirtualHost DocumentRoot /opt/myapp LemonLDAP enabled
signal-event domain-modify

Si vous utilisez un dossier partagé (contrib SharedFolders) pour y stocker votre application web, il faut aussi penser à désactiver les alias sur le domaine primaire (qui lui n'est pas protégé par LemonLDAP en général):

db accounts setprop myapp AliasOnPrimary disabled
signal-event share-modify-server myapp

Il est possible de configurer une authentification SSL (les clients présentent un certificat utilisateur pour s'authentifié auprès du portail). Pour activer cette fonctionnalité:

• Il faut tout d'abord disposer d'une PKI (on peut utiliser PHPKi par exemple). La CA de cette PKI signera les certificat des utilisateurs
• Pour chaque utilisateur, il faudra créer un certificat qui porte son login comme CN (Nom Commun)
• Il faut copier la partie public de la CA dans /etc/pki/tls/certs/cacert.pem et rendre ce fichier lisible par tous (chmod 644 /etc/pki/tls/certs/cacert.pem). Si vous utilisez PHPki sur le même serveur que LemonLDAP, il suffit de faire:

cp /opt/phpki/phpki-store/CA/certs/cacert.pem /etc/pki/tls/certs/cacert.pem
chmod 644 /etc/pki/tls/certs/cacert.pem
chown root:root /etc/pki/tls/certs/cacert.pem

• Il faut activer la fonction avec les commandes suivantes:

db configuration setprop lemonldap SSLAuth optional
signal-event webapps-update

• Pour activer la vérification de la validité des certificats clients par une CRL, il faut configurer l'URL de mise à jour. Si on utilise PHPki sur le même serveur:

db configuration setprop httpd-e-smith CrlUrl http://localhost:940/phpki/index.php?stage=dl_crl_pem
signal-event webapps-update

• Il ne reste plus qu'à configurer le reste dans le gestionnaire de configuration de LemonLDAP (https://sso-manager.domain.tld). Voici la liste des paramètres à modifier:

• Paramètres généraux
  • Modules d'authentification
    • Module d'authentification: Multiple (mettre SSL;LDAP dans le champ de saisie
    • Paramètres SSL
      • Champ extrait du certificat: SSL_CLIENT_S_DN_CN
      • Attribut LDAP pour le filtre: uid
      • SSL Requis: Activé
  • Sessions
    • Condition d'ouverture: $groups =~ /\bshared\b/
  • Journalisation
    • REMOTE_USER: $uid