Nextcloud est une solution open-source en alternative à Dropbox et consort. C’est une solution plutôt simple à mettre en place mais comme toujours, SAML complique les choses. A commencer par une documentation relativement pauvre, ce qui conduit à tâtonner jusqu’à trouver la bonne configuration. Sans plus tarder, voici comment configurer Nextcloud pour déléguer l’authentification à ADFS en SAML.

Pré-requis

• Un Nextcloud déjà configuré
• Un IdP qui marche, il s’agira ici de ADFS 4.0 (Windows Server 2016)
• Un certificat signé par une autorité reconnue par l’IdP, avec sa clé privée. La clé doit obligatoirement être du RSA. Ce certificat sera assigné au SP (Service Provider), c’est à dire Nextcloud afin de déchiffrer les requêtes SAML de l’ADFS passant à travers le navigateur. Ce certificat est optionnel dans l’absolu mais le tutoriel suppose qu’il existe.

Configuration de ADFS

Nextcloud propose des méta-data permettant de configurer rapidement l’IdP, cependant ces metadatas sont incomplets et l’on ne peut donc se reposer dessus pour faire une configuration fonctionnelle. Il va donc falloir tout faire à la main.

Dans le gestionnaire ADFS, nous créons un nouveau RP Trust de type Claims Aware.Vu que les metadatas générés par Nextcloud ne sont pas suffisants, la configuration du Relying Party Trust va se faire manuellement.

Nous donnons un nom à ce Relying Party Trust pour le différencier des autres, avec éventuellement un commentaire à destination des administrateurs.

Cette étape est optionnelle. Nous allons ici renseigner le certificat demandé dans les pré-requis.

Nous spécifions ensuite le endpoint vers lequel ADFS va rediriger le navigateur après l’authentification. Celui-ci doit être https://[nom.de.domaine.de.nextcloud]/apps/user_saml.acs .

Nous spécifions l’ID avec lequel Nextcloud va se déclarer auprès de l’ADFS dans les requêtes SAML. Celui-ci doit être https://[nom.de.domaine.de.nextcloud]/apps/user_saml/saml/metadata .

L’écran suivant permet de spécifier les personnes pouvant s’authentifier avec succès avec ADFS pour accéder à Nextcloud. Pour mon cas, j’indique tout le monde.

Le Relying Party Trust est enfin créé mais nous allons devoir compléter la configuration en l’éditant immédiatement.

Dans l’onglet Signature, nous allons spécifier le même certificat que celui utilisé dans l’onglet Encryption.

Nextcloud ne supporte pour le moment que l’utilisation du SHA-1, particularité que nous précisons dans l’onglet Advanced.

Nous pouvons valider les changements.

Configuration des claims

Viens ensuite la configuration des claims, c’est à dire d’une part les informations sur l’utilisateurs qui seront transmises à Nextcloud et d’autre part le mapping de ces informations.
Pour cela, nous allons ouvrir la boîte de dialogue d’édition des claims et ajouter deux règles de transformations :

La première règle est simple et sert à définir l’id de l’utilisateur côté Nextcloud.

La seconde règle va permettre de transmettre l’email et le nom d’affichage de l’utilisateur.

La configuration côté ADFS est désormais totalement terminée. Nous pouvons donc maintenant poursuivre avec NextCloud.

Configuration de Nextcloud

Nextcloud vient avec un plugin nommé « SSO & SAML authentication ». Celui-ci doit au préalable être activé dans la page listant les Apps afin d’ajouter une section au niveau de l’administration.

Une fois cela fait, vous trouverez ci-dessous les paramètres miroir à ce que nous avons paramétré précédemment dans ADFS. Prenez garde au warning afin d’éviter un tour en base de données si les choses tournent mal !

Le premier certificat à indiquer dans la section Service Provider Data est celui généré en pré-requis que nous avons renseigné comme token de chiffrage dans ADFS. Il doit être indiqué sous forme PEM, c’est à dire sous forme d’une chaîne en base-64 entouré des balises  « —–BEGIN CERTIFICATE—– » et « —–END CERTIFICATE—–« .

Dans la section Identity Provider, on fera attention à distinguer l’ID de l’IdP, lequel n’est pas une url et est par défaut http://[nom.de.domaine.de.adfs]/adfs/services/trust , sans le s dans http, du endpoint de l’IdP dans le second champ. Le certificat à indiquer dans les options cachées de l’Identity Provider est le token de signature de ADFS. Il se récupère dans la console ADFS dans Services > Certificates. Nextcloud s’attend à la partie publique du token, donc le certificat. Comme précédemment Nextcloud s’attend à ce que le certificat soit sous forme PEM.

La section suivante tire partie des informations envoyées par ADFS, notamment le nom d’affichage de l’utilisateur et son email. Les noms d’attributs peuvent être obtenus dans ADFS en cliquant sur le bouton View Rule Language ou bien en analysant les requêtes SAML lorsqu’elles ne sont pas chiffrées.

Enfin la dernière partie spécifie si le dialogue SAML est signé, chiffré et part qui. Dans le cas où Nextcloud est derrière un reverse proxy, il pourrait être nécessaire de désactiver l’option Indicates if the SP will validate all received XML.

It works!

Vous devriez à partir de maintenant pouvoir vous connectez à Nextcloud de manière totalement transparente. N’oubliez pas de désactiver l’option Allow the use of multiple user back-ends (e.g. LDAP) si tout fonctionne correctement. Cette option forcera toutes les authentifications à se faire via l’IdP.

Je pense qu’on peut faire mieux, notamment au niveau des claims où certain attributs me semblent inutile mais parce que ça marche je n’ai pas poussé ces tests. J’espère ainsi pouvoir vous éviter l’enfer, ça sera pour une prochaine fois.

Enjoy!