Sso on slash-root.fr

Nextcloud : Intégration d’une authentification SSO avec AD FS

Fri, 08 Jul 2022 12:00:33 +0200

Cet article fait office de PoC (Proof of Concept) sur la mise en place d'une authentification SSO (Single-Sign-On) à travers le service ADFS (Active Directory Federation Services) de Microsoft et l'application Open Source Nextcloud.

Cela va permettre aux utilisateurs de la plateforme Nextcloud de s'authentifier avec leur compte Active Directory en utilisant le protocole SAML dans des contextes réseaux totalement différents.

Environnement

Environnements déjà déployés :
- Nextcloud v24.0.2
- Contrôleur de domaine Windows Serveur 2019
Informations :
- Domaine AD : aukfood.lan
- Nom serveur AD : adfs-dev
- Domaine publique utilisé : example.com (remplace les parties floutées dans les captures d'écrans)
- URL Nextcloud : https://nc-dev.example.com
- Enregistrement DNS pour l'ADFS : adfs2-dev.example.com

Génération du certificat Let’s Encrypt

A effectuer sur le serveur Windows (Tous les services seront déployés sur le contrôleur de domaine) :

Installation de IIS en Powershell :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Faire un enregistrement de type A dans une zone DNS publique pour le serveur IIS :
```
adfs2-dev IN A xxx.xxx.xxx.xxx
```
Dans ce PoC, le domaine publique utilisé sera example.com.
Créer la racine du site web pour résoudre le challenge :
```
mkdir c:\inetpub\adfs2-dev.example.com
```
Créer un fichier index.html dans la racine du site web :
```
notepad c:\inetpub\adfs2-dev.example.com\index.html
```
Insérer le contenu suivant puis enregistrer :
```
Hello world
```
Ouvrir la console de Gestionnaire des services Internet (IIS).
Supprimer le site web par défaut.
Ajouter un nouveau site web :
Télécharger le client ACME pour Let's Encrypt ici : https://www.win-acme.com/

A l'heure actuelle, la dernière version : https://github.com/win-acme/win-acme/releases/download/v2.1.22.1267/win-acme.v2.1.22.1267.x64.pluggable.zip
Décompresser l'archive et déplacer le fichier Web_Config.xml à la racine du site web.
Redémarrer le site web.
Lancer une ligne de commandes et se positionner dans le répertoire préalablement extrait.
Exécuter wacs.exe :
Créer un nouveau certificat (Choix N).
Sélectionner le site ajouté au préalable dans IIS :
Peu importe si le certificat est de type wildcard ou non.
Le certificat est généré avec une tâche planifiée qui va renouveller le certificat automatiquement :
Une liaison https (vhost) a été automatiquement générée pour le site web :
Ce certificat est celui qui sera exploité par le service AD FS.

Exportation du certificat au format pfx

Re-lancer l'outil wacs.exe.
Faire le choix A (Manage renewals) :
Afficher les détails avec D, puis noter le .pfx password :

Ouvrir le dossier des certificats Let's Encrypt :

explorer C:\ProgramData\win-acme\acme-v02.api.letsencrypt.org\Certificates\

Sélectionner le certificat .pfx correspondant puis démarrer l'assistant d'importation du certificat au niveau de l'ordinateur local (Pour rappel : c'est le DC) :
Saisir le mot de passe de la clé privée (.pfx password noté au préalable) et cocher Marquer cette clé comme exportable :
Sélectionner automatiquement le magasin de certificats.
Terminer l'assistant d'importation du certificat.
Ouvrir la gestion des certificats de l'ordinateur local :
```
certlm.msc
```
Dans "Personnel\Certificats" (1), sélectionner le certificat préalablement importé (2). Dans "Toutes les tâches" (3), sélectionner "Exporter" (4) :
Il est maintenant possible d'exporter la clé privée du certificat :
Exporter toutes les propriétés étendues :
Saisir un mot de passe pour protéger la clé privée :
Spécifier le nom du fichier à exporter au format pfx.
Terminer l'assistant d'exportation du certificat.

Installation AD FS

Installer le service ADFS-Federation en Powershell :

Install-WindowsFeature -name ADFS-Federation -IncludeManagementTools

Créer la clé racine du service de distribution de clés en Powershell :
```
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
```
La configuration du service se fera en mode graphique à travers le gestionnaire de serveur servermanager.exe :
Créer le premier serveur de fédération dans une batterie de serveurs de fédération.
Importer le certificat préalablement exporté au format .pfx (1). Puis, entrer un nom pour le service FS (2) :
Spécifier un compte de service :
Une base de données SQL Server peut être exploitée. Dans ce PoC, une base de données interne Windows est utilisée.
Après examen des options, la configuration peut être lancée :
Redémarrer le serveur Windows.

Activer la page de login de l'ADFS en Powershell :

Set-AdfsProperties -EnableIdpInitiatedSignonPage $true

Tester la connexion : https://adfs2-dev.example.com/adfs/ls/IdpInitiatedSignon.aspx

Paramétrage Nextcloud

Se connecter en SSH sur le serveur Nextcloud et se positionner à la racine du projet web :
```
cd /var/www/nc-dev.example.com/www/
```

Installer l'application user_saml avec occ (A adapter selon le propriétaire du projet web) :

sudo -u nextcloud php8.0 occ app:install user_saml
# user_saml 5.0.2 installed
# user_saml enabled

Se connecter à l'interface web du Nextcloud en admin.
Se rendre dans "Paramètres" (1) / "Authentification SSO & SAML" (2). Puis "Utiliser l'authentification SAML intégrée" (3) :
Dans la partie "Général", entrer l'Attribut pour relier l'UID :
```
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
```
C'est l'UPN du compte de l'utilisateur dans l'AD qui fera office de nom d'utilisateur au sein de l'instance Nextcloud.
Configurer les options IdP :
- Identifiant de l'entité IdP : http://adfs2-dev.example.com/adfs/services/trust
- URL cible du fournisseur d'identités à qui le fournisseur de service enverra la requête d'authentification : https://adfs2-dev.example.com/adfs/ls
Cliquer sur "Hide optional Identity Provider settings" pour accéder au champ Certificat public X.509 de l'IdP.
Sur le serveur Windows, ouvrir la console de gestion de l'ADFS :
```
%windir%\ADFS\Microsoft.IdentityServer.msc
```
Dans "Service" / "Certificats" (1), Afficher le certificat (2) utilisé pour la signature de jetons :
Dans l'onglet "Détails", copier dans un fichier :
Exporter au format : *X.509 encodé en base 64 (.cer)**
Spécifier un nom de fichier pour l'export.
Copier le contenu de ce fichier exporté au format .cer et le coller dans le champ Certificat public X.509 de l'IdP dans Nextcloud :
Mapper les attributs suivants au minimum :
- Attribut pour relier le nom d'utilisateur : http://schemas.microsoft.com/identity/claims/displayname
- Attribut pour relier l'adresse mail : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Télécharger le fichier metadata.xml :
Pour avoir la possibilité de garder l'authentification avec la base utilisateur interne de Nextcloud, cocher Autoriser l'utilisation de plusieurs systèmes d'authentification :

Bien vérifier l'enregistrement du paramétrage en quittant le menu "Authentification SSO & SAML" et en y revenant (Surtout sur le paramétrage du point précédent).

Paramétrage AD FS

Sur le serveur Windows, ouvrir la console de gestion de l'AD FS :
```
%windir%\ADFS\Microsoft.IdentityServer.msc
```
Ajouter une approbation de partie de confiance :
Prendre en charge les revendications.
Importer les données concernant la partie de confiance à partir du fichier metadata.xml téléchargé préalablement :
Saisir un nom pour cette approbation et éventuellement des notes.
Sélectionner une stratégie de contrôle d'accès. Dans ce PoC, tout le monde sera autorisé :
La partie de confiance a été configurée à l'aide du fichier metadata.xml fourni.
Editer la stratégie d'émission de revendication :
2 règles de revendication de transformations sont à ajouter au minimum :
- userPrincipalName
- Email
Le modèle de régle de revendication à suivre est : Envoyer les attributs LDAP en tant que revendications.
Règle userPrincipalName :
Règle Email :
Appliquer les 2 règles ajoutées.

Vérification de l’authentification

Se connecter à Nextcloud, et choisir de s'authentifier au travers une Connection SSO & SAML :
Utiliser un compte de l'Active Directory autoriser à se connecter à travers l'AD FS :
Congratulations !

Ressources en vrac

LemonLDAP : Installation avec un LDAP et FusionDirectory

Tue, 16 Nov 2021 14:48:52 +0100

Introduction

LemonLDAP::NG est un logiciel open source, créé en 2004 par la Gendarmerie nationale française. Il fournit une solution d' authentification unique distribuée avec gestion centralisée des droits sous licence GPL.

Le logiciel LemonLDAP::NG est issu d'un logiciel créé par Eric German suivant le protocole de gestion d'annuaire LDAP sous TCP/IP pour le Ministère des finances français. La Gendarmerie nationale reprend ce logiciel pour l'élargir et le conformer à ses besoins.

Le logiciel fonctionne avec les serveurs web Apache ou Nginx mais un mode reverse proxy permet de l'utiliser avec des applications exécutées sur un autre serveur (IIS, Tomcat, etc.)3,4.

Il peut gérer plus de 200000 utilisateurs de différentes organisations, il implémente à la fois5 :

les services de fournisseur d'identité et de service SAML, OpenID, CAS et OpenID Connect6 ;
peut-être utilisé comme Proxy protocolaire en fédération des identités ;
l'authentification basée sur LDAP, Kerberos, SQL, Twitter et d'autres protocoles ;
l'authentification à double facteur (U2F, TOTP, Yubikey, REST ou externe tels SMS ou mails)7
un système d'authentification unique basé sur des cookies sécurisés ;
un menu dynamique des applications ;
un module de réinitialisation de mots de passe ;
un module d'auto-création de compte ;
un dispositif de notification ;
un explorateur de sessions.

Depuis la version 1.9, il propose un connecteur FranceConnect, lui permettant d'être simplement soit fournisseur d'identités, soit fournisseur de services8.

La version 2.0.6 apporte, entre autres évolutions, les nouvelles fonctionnalités suivantes :

la sur-charge des seconds facteurs et la prise en charge du protocole RADIUS ;
la possibilité de définir une politique locale des mots de passe ;
un module de simulation d'identités pour des environnements de formation ;
un module d'endossement d'identité pouvant être activé à des fins de diagnostic ;
un module permettant de consulter le profil SSO d'un utilisateur et de vérifier ses droits d'accès ainsi que les en-têtes transmis ;
un module pour éditer la configuration en lecture seule.

La version 2.0.7 permet un meilleur support du protocole OpenId Connect et apporte de nombreuses améliorations ou correctifs.

La version 2.0.8 offre de nombreuses API et améliorations.

La version 2.0.9 apporte un outil de gestion des sessions, ameliore la gestion des mots de passe, une documentation intégrée au code source et des correctifs.

Source : LemonLDAP::NG — Wikipédia (wikipedia.org)

Pré-requis

Un serveur OpenLDAP installé et fonctionnel
FusionDirectory déployé sur le serveur LDAP
Un nom de domaine avec la gestion de sa zone DNS

Suite directe de : OpenLDAP : Installation avec FusionDirectory - slash-root.fr

Le nom de domaine utilisé dans cet article sera : example.com

LemonLDAP sera déployé sur le même serveur qu'OpenLDAP / FusionDirectory

Installation LemonLDAP

Utiliser le dépôt officiel :

sudo cat > /etc/apt/sources.list.d/lemonldap-ng.list << 'EOL'
# LemonLDAP::NG repository
deb https://lemonldap-ng.org/deb 2.0 main
deb-src https://lemonldap-ng.org/deb 2.0 main
EOL

Récupérer la clef GPG :

wget -O - https://lemonldap-ng.org/_media/rpm-gpg-key-ow2 | sudo apt-key add -

Mise à jour du cache apt :
```
sudo apt update
```
Installer le package principal et le module Perl pour Apache2 :
```
sudo apt install libapache2-mod-perl2 lemonldap-ng
```
LemonLDAP est également compatible avec Nginx mais cela ne sera pas abordé dans cet article.
Installer le module FCGID pour Apache :
```
sudo apt install libapache2-mod-fcgid
```

Activer les modules et les configurations :

sudo a2ensite manager-apache2.conf
sudo a2ensite portal-apache2.conf
sudo a2ensite handler-apache2.conf
sudo a2enmod fcgid perl alias rewrite headers

Tester la configuration d'Apache2 :
```
sudo apachectl configtest
```
Redémarrer Apache2 :
```
sudo systemctl restart apache2
```

Par défaut, le domaine est example.com. Celui-ci peut être changé.

Pour changer le nom de domaine par défaut :
```
sed -i 's/example\.com/mondomaine.local/g' /etc/lemonldap-ng/* /var/lib/lemonldap-ng/conf/lmConf-1.json
```
Adapter la suite des instructions avec le domaine utilisé en lieu et place d'example.com.

Accès Web UI

Pour accéder à la Web UI et effectuer les tests nécessaires, il y a 4 enregistrements A à réaliser dans la zone DNS du domaine :
- auth.example.com
- manager.example.com
- test1.example.com
- test2.example.com
C'est 4 URLs sont à rediriger vers le même serveur. test1 et test2 sont là pour simuler 2 applications différentes.
Avec un navigateur web, accéder à http://auth.example.com :

Dans un 1er temps, utiliser le login dwho avec le mot de passe dwho. Ce compte est local à LemonLDAP et à des droits administrateur sur la plateforme.

Se rendre sur WebSSO Manager ou directement via l'URL : http://manager.example.com :

La configuration qui va être appliqué peut se faire intégralement par cette Web UI :

Afin de pouvoir automatiser tout ce processus plus tard, la configuration sera réalisée en ligne de commande à l'aide de l'outil :
```
/usr/share/lemonldap-ng/bin/lemonldap-ng-cli help
```

Activer les applications de démonstration

LemonLDAP est fournit avec 2 applications de démonstration qui permettent de lire les en-têtes HTTP. Pour les activer :
```
sudo a2ensite test-apache2.conf
sudo systemctl reload apache2
```

C'est un vhost standard d'Apache2 :

sudo cat /etc/apache2/sites-enabled/test-apache2.conf

Remarquer la ligne qui à été ajoutée concernant le SSO :

 # SSO protection
 PerlHeaderParserHandler Lemonldap::NG::Handler::ApacheMP2

Vérifier l'accès aux applications de démonstration en se rendant sur :
- http://test1.example.com
- http://test2.example.com
Pas besoin de s'authentifier car cela a été fait l'autre de l'accès à la plateforme LemonLDAP :

Il est possible de se déconnecter de cette application test1, en bas de la page :

Lors de la prochaine tentative d'accès, une demande d'authentification de LemonLDAP sera demandée.

Configuration avec OpenLDAP / FusionDirectory

Pour le moment LemonLDAP est en mode démo et utilise une base de compte interne. La configuration de LemonLDAP va consister à utiliser l'annuaire OpenLDAP préalablement déployé avec FusionDirectory. Une chose à savoir est que l'accès au manager est réservé exclusivement à l'utilisateur dwho de la base de compte interne à LemonLDAP. Lors de la jonction de l'annuaire LDAP à LemonLDAP, la base de compte interne ne sera plus exploitable. Par conséquence, l'accès au WebSSO Manager ne se fera plus. Il y a plusieurs méthodes possibles pour retrouver cet accès. En voici une qui consiste à n'autoriser que l'utilisateur fd-admin de l'annuaire LDAP :

Avec l'utilisateur dwho se rendre dans le Manager. Puis Hôtes virtuels, manager.example.com, Règles d'accès :
Modifier la partie Règles à droite comme ci-dessus. Puis Sauver la configuration.

Paramétrer la liaison à l'annuaire LDAP :

sudo /usr/share/lemonldap-ng/bin/lemonldap-ng-cli -yes 1 \
 set \
 authentication LDAP \
 userDB LDAP \
 passwordDB LDAP \
 registerDB LDAP \
 ldapServer 'ldap://localhost' \
 managerDn 'cn=admin,dc=example,dc=com' \
 managerPassword 'MonSuperPassword' \
 ldapBase 'ou=people,dc=example,dc=com' \

Pour des raisons de praticité, le managerDn utilisé est le compte admin de l'annuaire. Dans un contexte de production un autre compte sera utilisé.

Afin d'avoir une vue synthétique de l'annuaire et obtenir les chemins complets pour la précédente commande, utiliser :
```
sudo slapcat | grep "dn:"
```

Exporter les attributs souhaités :

sudo /usr/share/lemonldap-ng/bin/lemonldap-ng-cli -force 1 -yes 1 \
 addKey \
 ldapExportedVars uid uid \
 ldapExportedVars cn cn \
 ldapExportedVars sn sn \
 ldapExportedVars mail mail \
 ldapExportedVars givenName givenName

Voici le retour attendu :

Status : [
 {
 'localhost' => 'OK'
 }
 ];

Redémarrer Apache2 :
```
sudo systemctl restart apache2
```
L'utilisateur fd-admin peut maintenant s'authentifier, avec accès au manager, sur la plateforme : http://auth.example.com.

Keycloak : Integration LDAP externe

Thu, 04 Nov 2021 17:33:31 +0100

Introduction

La solution Keycloak est embarqué avec la possibilité de joindre un annuaire LDAP/AD. Il est possible de fédérer plusieurs serveurs d'annuaires au sein d'un même royaume keycloak. Les attributs utilisateurs de l'annuaire LDAP peuvent être mappé dans un model d'utilisateur keycloak. Par défaut, les attributs username, email, first name, last name sont mappés mais d'autres attributs peuvent l'être également.

Cet article fait suite à :

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

OpenLDAP : Installation avec FusionDirectory

Prérequis

Un serveur Keycloak fonctionnel
Un serveur OpenLDAP/FusionDirectory fonctionnel

Toute la procédure fera référence aux configuration déployées dans les articles cités en introduction.

Configuration

Se rendre sur la WebUI du serveur Keycloak : https://keycloak.example.com
Se rendre dans la partie User Federation et ajouter ldap en provider :

Paramétrage - 1ère partie

Stockage

Par défaut, Keycloak importe les utilisateurs de l'annuaire LDAP dans sa base locale d'utilisateurs. Cette copie des utilisateurs peut être synchronisée soit manuellement soit automatiquement toutes les x minutes par exemple. Seul les mots de passes ne sont pas synchronisés. Dans le processus d'identification de l'utilisateur, la validation du mot de passe est délégué au serveur LDAP. L'avantage de cette approche est que toutes les fonctionnalités de Keycloak fonctionneront avec des attributs utilisateurs supplémentaires qui sont stockés localement sur Keycloak. Cela permet également de réduire la charge sur le serveur LDAP.

Il est possible de ne pas importer les utilisateurs de l'annuaire LDAP dans Keycloak en décochant Import Users. Cela aura pour effet d'augmenter les requêtes vers le serveur LDAP car aucune information utilisateur ne sera stockée localement sur Keycloak. L'autre conséquence de ce choix est que si une fonctionnalité de Keycloak repose sur une partie non supporté par l'annuaire LDAP, celle-ci ne fonctionnera pas. En revanche, l'avantage est de ne pas avoir à gérer la synchronisation des comptes.

Edition

L'Edit Mode permet aux utilisateurs et aux administrateurs, à travers leurs consoles respectives sur Keycloak, de modifier les metadas utilisateur.

READONLY : Les attributs utilisateurs resteront inchangés. Une erreur apparaitra si une modification d'attribut est faites. Cela est également valable pour la modification d'un mot de passe utilisateur.
WRITABLE : Tous les attributs utilisateurs modifiés seront synchronisés automatiquement avec l'annuaire LDAP.
UNSYNCED : Tous les changements d'attributs seront stockés localement dans la base de Keycloak. La synchronisation des modifications au sein de Keycloak vers l'annuaire LDAP devra être faites manuellement.

Vendor

Plusieurs choix sont possibles suivant le type d'annuaire LDAP en face :

Active Directory
Red Hat Directory Server
Tivoli
Novell eDirectory
Other

L'annuaire installé étant OpenLDAP, other est le choix à faire.

Paramétrage - 2nd partie

Connection URL : Indiquer le chemin d'accès au serveur LDAP
Users DN : Indiquer le chemin d'accès aux utilisateurs dans l'annuaire.
Bind DN : Indiquer un compte dans l'annuaire ayant des droits d'écriture.
Bind Credential : Le mot de passe du compte spécifié dans "Bind DN".

Synchronisation

Un peu plus bas de la page de configuration de la connexion au serveur LDAP, un menu Sync Settings est disponible :

Batch Size : Le nombre de compte utilisateurs qui seront traités en une synchronisation.
Periodic Full Sync : La planification en secondes de la synchronisation totale / complète.
Periodic Changed Users Sync : La planification en secondes de la synchronisation des changements apportés aux attributs utilisateurs.

Après avoir sauvegarder tous les paramètres, il est possible de déclencher manuellement une première synchronisation des utilisateurs de l'annuaire LDAP dans Keycloak :

Mappers

Par défaut, des Mappers sont mis en place. Un mapper va permettre de mapper un attribut utilisateur de l'annuaire LDAP à un attribut utilisateur de Keycloak :

Dans mes différents essais, en déployant cette solution de SSO avec un OpenLDAP, il est apparu que l'attribut firstName de Keycloak est mappé avec l'attribut cn de l'annuaire LDAP. L'attribut cn dans l'annuaire (avec la couche FusionDirectory) est une concaténation du prénom et du nom de l'utilisateur :

Au lieu de modifier la configuration de l'annuaire LDAP, modifier le mapper first name dans Keycloak :

Modifier LDAP Attribute pour indiquer givenName.

givenName est le nom de l'attribut prénom au sein de l'annuaire LDAP dans notre configuration.

OpenProject : Mise en place du SSO avec Keycloak

Thu, 28 Oct 2021 14:40:22 +0200

Introduction

Par défaut, OpenProject utilise une base locale d'utilisateurs pour gérer l'authentification. Afin de centraliser l'authentification sur un serveur dédié (avec OpenID-Connect) Keycloak, une configuration SSO est nécessaire sur OpenProject.

OpenProject va utiliser OpenID-Connect pour faire du SSO. Ca tombe bien Keycloak aussi ! Un paramétrage concernant cela est disponible via la web UI d'administration d'OpenProject mais celle-ci ne concerne que Google et Azure. Fort heureusement, c'est tout de même possible en éditant un fichier.

Référence :

OpenProject : Installation

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

Pré-requis

Pour mener à bien cette procédure, il faut :

Un serveur OpenProject installé avec une licence Entreprise
Un serveur Keycloak installé

Pour la licence OpenProject Entreprise, il est possible de faire un essai de 14 jours gratuitement. Sans licence Entreprise, le SSO n'est pas pris en charge par OpenProject. Lorsque l'essai de la version Entreprise arrive à son terme et que celle-ci n'est pas prolongé, alors la licence repasse automatique en Community Edition (Free).

Configuration partie Keycloak

Création d'un royaume :

Création d'un client :

Root URL : L'URL d'accès au serveur OpenProject.

Dans les propriétés du client nouvellement créer, définir l' Access Type sur confidential afin de générer un secret :

Bien penser à sauvegarder la modification en bas de la page.

Un nouvel onglet Credentials est apparu dans les propriétés du client. Un secret a été généré :

Créer un compte utilisateur si le serveur Keycloak est fraichement installé :

Attention : Sur l'illustration, seul le champ Username est indiqué comme obligatoire. Lorsque qu'un utilisateur s'authentifiera avec son compte Keycloak sur OpenProject, les champs Email , First Name , Last Name seront obligatoires. Ces propriétés ne peuvent en cas cas être communes à un autre compte.

Une fois l'utilisateur créé, dans l'onglet Credentials , définir son mot de passe :

Configuration partie OpenProject

Pour qu'un utilisateur puisse utiliser son compte Keycloak pour s'authentifier sur OpenProject, celui-ci doit être activé dans OpenProject. Par défaut l'activation se fait manuellement. Pour automatiser ce processus, une option d' activation automatique du compte existe dans OpenProject.

Se connecter en admin sur OpenProject puis "Administration -> Authentification", modifier l'option Auto-enregistrement comme suit :

Pour la suite des opérations, se connecter en SSH sur le serveur OpenProject.

Modifier le fichier /opt/openproject/config/configuration.yml afin d'ajouter la possibilité de s'authentifier sur OpenProject au travers du serveur SSO Keycloak. Ajouter les lignes suivantes dans la section default :

default:

# omniauth_direct_login_provider: openid

 openid_connect:
 openid:
 host: "keycloak.example.fr"
 identifier: "MonOpenProject"
 secret: "af90aced-0000-0000-0000-0959e6fd5226"
 icon: "openid_connect/auth_provider-google.png"
 display_name: "SSO"
 authorization_endpoint: "https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/auth"
 token_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/token'
 userinfo_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/userinfo'
 end_session_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/logout'
 check_session_iframe: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/login-status-iframe.html'
 sso: true
 issuer: 'https://keycloak.example.fr/auth/realms/MonRoyaume'
 discovery: false

Adapter les valeurs suivantes :

host : Le FQDN du serveur Keycloak
identifier : Le nom du client créé dans Keycloak
secret : Le secret du client généré dans Keycloak

# Les URLS suivantes peuvent facilement être obtenues dans Keycloak
# Realm Settings -> Endpoints : OpenIP Endpoint Configuration

authorization_endpoint: "https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/auth"
token_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/token'
userinfo_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/userinfo'
end_session_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/logout'
check_session_iframe: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/login-status-iframe.html'
issuer: 'https://keycloak.example.fr/auth/realms/MonRoyaume'

La directive omniauth_direct_login_provider indique que seul l'authentification passera par keycloak. Commenter cette directive pour avoir le choix d'authentification entre keycloak (SSO) ou la base locale d'OpenProject.

OpenProject : Redémarrer le service openproject

sudo systemctl restart openproject

Vérification du fonctionnement

Dorénavant lors de la connexion sur OpenProject, une option de connexion SSO est disponible :

Le serveur Keycloak prends le relais pour demander les credentials :

Après la 1ère connexion d'un utilisateur au travers du SSO, celui-ci est présent dans OpenProject avec un fournisseur d'authentification OpenID :

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

Mon, 25 Oct 2021 17:37:16 +0200

Introduction

Keycloak est une solution opensource permettant d'implémenter du SSO (Single-Sign-On) au sein d'une infrastructure. Il est compatible avec les principaux protocoles d'authentification (OAuth2.0, OpenID-Connect). Il peut être couplé à un annuaire LDAP.

Dans cet article, Keycloak, va être déployé sur une Debian 10 conteneurisé dans 2 images dockers. Docker-Compose va orchestrer le tout. Un serveur nginx sera en frontal en tant que reverse-proxy.

Prérequis

1 serveur Debian 10 à jour qui sera dédié à hébergé le serveur Keycloack
1 serveur web Nginx opérationnel
Certificats SSL générés pour votre nom de domaine

Voir article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS

Installation

Installation des paquets

Installer docker :
```
sudo apt install docker
```
Installer docker-compose :
```
sudo apt install docker-compose
```
Vérifier l'installation de docker-compose :
```
docker-compose --version
```

Création du docker-compose

Créer un répertoire afin d'y stocker le fichier docker-compose :
```
sudo mkdir keycloak
```
Se positionner dans le répertoire nouvellement créé :
```
cd keycloak
```
Créer un fichier docker-compose.yml :
```
sudo vi docker-compose.yml
```

Attention, le fichier doit être au format YAML ce qui signifie que la tabulation est interdite (il faut mettre des espaces pour l'indentation).

Copier / Coller le fichier suivant :

version: '3.3'

volumes:
postgres_data:
 driver: local

services:
postgres:
 image: postgres
 volumes:
 - postgres_data:/var/lib/postgresql/data
 environment:
 POSTGRES_DB: keycloak
 POSTGRES_USER: keycloak
 POSTGRES_PASSWORD: password
keycloak:
 image: jboss/keycloak:latest
 environment:
 PROXY_ADDRESS_FORWARDING: 'true'
 DB_VENDOR: POSTGRES
 DB_ADDR: postgres
 DB_DATABASE: keycloak
 DB_USER: keycloak
 DB_PASSWORD: password
 KEYCLOAK_USER: admin
 KEYCLOAK_PASSWORD: Mon_mot_de_passe
 ports:
 - 9090:8080
 depends_on:
 - postgres

Le numéro de version indiqué en 1ère ligne peut varier suivant votre version de docker-compose. Dans mon cas, j'ai une version de docker-compose en 1.21.0.

Le port de keycloak dans le conteneur est le 8080, il sera bind sur le 9090 du serveur.

La directive PROXY_ADDRESS_FORWARDING est très importante dans le cas d'une utilisation de reverse proxy.

Lancement du docker-compose

Exécuter le docker-compose :

sudo docker-compose -f ~/keycloak/docker-compose.yml up

Pour lancer le docker-compose en arrière-plan :

sudo docker-compose -f ~/keycloak/docker-compose.yml up -d

Vérifier que les conteneurs docker soient bien démarrés :
```
sudo docker ps
```

Le résultat soit être similaire à :

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
643f26101b75 jboss/keycloak:latest "/opt/jboss/tools/do…" About a minute ago Up 52 seconds 8443/tcp, 0.0.0.0:9090->8080/tcp keycloak_keycloak_1
6789a8285283 postgres "docker-entrypoint.s…" About a minute ago Up 52 seconds 5432/tcp keycloak_postgres_1

Configuration reverse-proxy SSL avec Nginx

Un serveur Nginx doit être opérationnel.

S'appuyer sur cet article : Nginx : Installation d’un Reverse Proxy
Les certificats SSl doivent être générés.

S'appuyer sur cet article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS
Créer le fichier de configuration du virtual host :
```
sudo vi /etc/nginx/sites-available/keycloak.conf
```

Copier / Coller le fichier suivant :

server {
 listen 80;
 server_name keycloak.example.com;
 rewrite ^ https://keycloak.example.com permanent;
}

server {
 listen 443 ssl;
 server_name keycloak.example.com;
 ssl_certificate /etc/letsencrypt/live/keycloak.example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/keycloak.example.com/privkey.pem;
 ssl_session_cache builtin:1000 shared:SSL:10m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
 ssl_prefer_server_ciphers on;

 location / {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_pass http://IP_MON_SERVEUR_KEYCLOACK:9090;
 }

}

Remplacer keycloak.example.com par le nom de domaine pour le serveur keycloak. Le nécessaire doit être fait au sein de la zone DNS.

Vérifier les chemins d'accès aux certificats SSL.

Modifier la directive proxy_pass pour correspondre avec le serveur keycloak.

Créer un lien symbolique pour activer le virtual host :

sudo ln -s /etc/nginx/sites-available/keycloak.conf /etc/nginx/sites-enabled/keycloak.conf

Vérifier la configuration de Nginx avec :
```
sudo nginx -t
```
Redémarrer le service nginx :
```
sudo systemctl restart nginx
```

Accès administrateur à Keycloak

Se rendre à l'adresse : https://keycloak.example.com
Accéder à Administration Console :

Les credentials à entrer sont ceux définit dans le fichier docker-compose.yml aux lignes suivantes :
 KEYCLOAK_USER: admin
 KEYCLOAK_PASSWORD: Mon_mot_de_passe

Démarrage automatique avec le système

Avec la configuration actuelle au redémarrage du serveur keycloak, le docker-compose ne sera pas lancé.
Pour activer le démarrage automatique des conteneurs Postegresql et Keycloak au boot du serveur, modifier le docker-compose.yml et ajouter cette ligne dans chaque services qui doit démarrer avec le service docker :
```
restart: always
```
Si les conteneurs sont arrêtés à la main, ils ne démarreront pas automatiquement. Docker comprend que c'est une action manuelle et que c'est l'état désiré.
Pour que cela soit fonctionnel, le service docker.service doit être en status enable :
```
sudo systemctl status docker.service
```

Le résultat doit être le suivant :

Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)

Si cela n'est pas le cas :
```
sudo systemctl enable docker.service
```