Déployer OpenCloud en Docker avec authentification OIDC Authentik

Les solutions de stockage et de collaboration auto-hébergées sont devenues essentielles pour garder la maîtrise de ses données tout en proposant une expérience moderne aux utilisateurs. Si Nextcloud reste un acteur incontournable, de nouvelles alternatives apparaissent avec une architecture plus récente et des performances optimisées. C’est notamment le cas de OpenCloud.

Dans ce tutoriel, nous allons voir comment déployer OpenCloud avec Docker Compose, puis comment intégrer une authentification centralisée via OIDC grâce à Authentik. Vous disposerez ainsi d’une plateforme cloud rapide, moderne et sécurisée, avec une gestion simplifiée des utilisateurs grâce au Single Sign-On (SSO).

Nous verrons également la configuration du reverse proxy, l’intégration avec Collabora, les particularités liées aux certificats SSL internes ainsi que plusieurs retours d’expérience utiles pour réussir votre déploiement.

Qu’est-ce qu’OpenCloud ?

OpenCloud est une plateforme de stockage de fichiers et de collaboration open source issue de l’écosystème ownCloud, dont elle reprend l’héritage technique et fonctionnel dans une version modernisée. Le projet est souvent présenté comme un fork orienté nouvelle génération, pensé pour répondre aux besoins actuels de performance, de simplicité de déploiement et d’intégration avec les standards modernes.

L’un de ses principaux atouts est d’être entièrement développé en Go (Golang). Ce choix technique lui permet d’offrir d’excellentes performances, une faible consommation de ressources et une architecture plus légère que de nombreuses solutions historiques basées sur PHP. Dans un environnement conteneurisé, OpenCloud peut fonctionner avec une empreinte mémoire particulièrement réduite, ce qui en fait une solution idéale pour les petits comme les grands environnements.

OpenCloud permet de gérer le stockage de fichiers, les partages internes ou externes, la synchronisation des données ainsi que l’édition collaborative de documents via Collabora Online. Son interface moderne et sa rapidité d’exécution offrent une expérience utilisateur fluide, aussi bien sur poste de travail que sur mobile.

Autre point fort : la prise en charge native des méthodes d’authentification modernes comme OpenID Connect (OIDC). Il devient ainsi simple de connecter OpenCloud à un fournisseur d’identité tel que Authentik, Keycloak ou tout autre service compatible, afin de centraliser la gestion des accès et renforcer la sécurité de l’infrastructure.

Prérequis pour le déploiement d’Opencloud

Pour déployer Opencloud comme nous allons le voir dans ce tutoriel, vous aurez besoin :

• D’un reverse proxy en frontale (Nginx)
• D’un serveur Linux avec Docker et Docker compose
• De trois enregistrements DNS avec certificat SSL
  • opencloud.domaine.tld
  • opencloud-wopi.domain.tld
  • opencloud-collabora.domain.tld

Dans ce tutoriel, je vais utiliser les enregistrements suivants :

• ocloud.lab.local
• ocloud-wopi.lab.local
• ocloud-collabora.lab.local

Pour la génération du certificat j’ai utilisé un générateur de certificat auto-signé.

Déploiement d’Opencloud

On va commencer par le déploiement « simple » d’Opencloud, afin de vous faciliter la tâche, vous trouvez les fichiers ici : Gitlab ou Github.

La configuration proposée sur le Github officiel est assez complexe à mettre en place et difficile à « comprendre »

Commencer par créer un dossier sur votre serveur et mettre le contenu récupérer sur l’un dépôt de votre choix, pour la part je vais me travailler dans le dossier /containers/opencloud.

Copier le sample.env en le nommant .env.

cp sample.env .env

Puis éditer le fichier :

nano .env

Pour commencer, voici les variables à configurer :

Si nécessaire, modifier le fichier docker-compose.yml pour déclarer le réseau de votre reverse proxy si celui-ci est sur le même serveur.

Avant de démarrer les conteneurs, faisons un focus sur Collabora. Si vous utilisez un certificat SSL interne ou auto-signé, il est nécessaire d’utiliser une image personnalisée de Collabora dans laquelle le certificat de confiance a été ajouté. Pour cela, rendez-vous dans le dossier custom/collabora/, puis ouvrez le fichier ca-internal.pem et collez-y votre certificat, soit la partie publique du certificat serveur, soit de préférence celui de votre autorité de certification interne. Une fois cette étape réalisée, construisez l’image Docker personnalisée avec la commande docker build . -t collabora-code-custom. Ensuite, modifiez le fichier docker-compose.yml afin d’utiliser cette nouvelle image : commentez la ligne utilisant l’image officielle, puis décommentez celle prévue pour l’image personnalisée sur le service collabora et la ligne pull_policy: never. Cette opération permettra à Collabora de faire confiance à votre certificat interne et d’établir correctement les connexions HTTPS avec votre environnement.

Télécharger les images :

docker compose pull

Puis démarrer les conteneurs en affichant pour vérifier que tout « fonctionne bien » :

docker compose up -d && docker compose logs -f

Si vous êtes utilisateur de Nextcloud, je vous invite au passage à comparer les ressources CPU et RAM utilisées par OpenCloud à l’aide de la commande docker compose stats. Comme vous pourrez le constater, OpenCloud se montre particulièrement léger et consomme très peu de ressources, avec une utilisation mémoire pouvant rester inférieure à 100 MiB selon les services activés et la charge en cours.

Configuration du Reverse proxy

Maintenant, vous devez configurer votre reverse proxy afin de rediriger le flux HTTPS vers les différents services d’OpenCloud. Cette étape est indispensable pour permettre l’accès aux applications via une URL unique et sécurisée. Si vous utilisez Nginx, vous trouverez dans le dossier config/nginx/ un exemple de configuration prêt à l’emploi qu’il vous suffira d’adapter à votre environnement, notamment avec votre nom de domaine, vos certificats SSL et les adresses internes des services.

Accéder à Opencloud et valider son fonctionnement

Maintenant que tout est configuré, ouvrez votre navigateur web puis rendez-vous à l’URL que vous avez configurée afin d’accéder à OpenCloud. Si l’ensemble des étapes précédentes a été correctement réalisé, la page de connexion du service devrait s’afficher et vous pourrez commencer la prise en main de votre environnement.

Identifiez-vous avec le compte admin en utilisant le mot de passe défini dans le fichier .env, au niveau de la variable IDM_ADMIN_PASSWORD. Une fois connecté, vous pourrez accéder à l’interface d’administration et poursuivre la découverte de votre instance OpenCloud.

Une fois connecté, je vous invite à tester les différentes fonctionnalités de création de dossiers, fichiers et les fichiers gérer par Collabora.

Pour accéder à l’administration de votre instances, cliquer sur la gaufre en haut à gauche puis sur Paramètre d’administration.

Les dossiers et fichiers des utilisateurs sont stockés dans le répertoire de données d’OpenCloud, chaque utilisateur étant identifié par un GUID plutôt que par son nom de connexion. Les données se trouvent à l’emplacement suivant : opencloud-data/storage/users/users/. À l’intérieur de ce dossier, vous retrouverez un répertoire par utilisateur contenant l’ensemble de ses fichiers et dossiers personnels. Ce fonctionnement permet une gestion interne plus fiable des identifiants et évite les problèmes liés aux changements de nom d’utilisateur.

Configurer l’authentification avec Authentik

Pour finir ce tutoriel, je vais vous expliquer comment configurer Authentik et OpenCloud afin de mettre en place l’authentification centralisée. Cette intégration permettra aux utilisateurs de se connecter à OpenCloud via votre portail d’identité, tout en simplifiant la gestion des comptes, des accès et des politiques de sécurité. Nous allons voir ensemble les différentes étapes nécessaires pour relier les deux solutions et obtenir un fonctionnement fluide avec le Single Sign-On (SSO).

Avant de commencer la configuration, voici un petit retour d’expérience qui m’a coûté un peu de temps en phase de débogage entre Authentik et OpenCloud. Ce qu’il faut bien comprendre, c’est que l’authentification est gérée côté navigateur et non côté backend, car OpenCloud utilise un client public. Lors de mes premiers tests, j’ai utilisé mon compte habituel, synchronisé avec Active Directory via Authentik. Par défaut, Authentik retourne dans les claims du profil la liste complète des groupes de l’utilisateur. Dans mon cas, cela générait un jeton de plus de 16 000 caractères, ce qui provoquait des dysfonctionnements avec OpenCloud, notamment avec Collabora, car les en-têtes HTTP devenaient trop volumineux. Si vous rencontrez cette situation, il est nécessaire d’ajuster la configuration côté Authentik. La bonne pratique consiste à recréer un claim profile ne transmettant pas les groupes par défaut, puis à créer un claim dédié aux groupes en filtrant uniquement ceux réellement nécessaires, par exemple les groupes commençant par OPENCLOUD_*. Cela permet de réduire fortement la taille du jeton et d’éviter les problèmes liés aux headers trop volumineux.

Ajouter l’application et le fournisseur dans Authentik

On commence par la création de l’application et du fournisseur, cliquer sur le bouton Create with Provider 1.

Commencer par nommer l’application 1, le slug est généré automatiquement, cliquer ensuite sur Next 2.

Sélectionner le fournisseur OAuth2/OpenID Provider 1 puis cliquer sur Next 2.

Configurer le flux d’autorisation 1, puis choisir le type de client Public 2.

Ajouter maintenant les deux URL de redirections 1 puis cliquer sur Next 2.

URL de redirection :

• https://opencloud.domain.tld/oidc-callback.html
• https://opencloud.domain.tld/oidc-silent-redirect.html

Cliquer ensuite sur Next pour les différentes étape de l’assistant, l’application créée, cliquer sur Close 1.

Ajouter d’un mappage profile sans les groupes

Par défaut le scope profile d’Authentik retourne les groupes dont l’utilisateur est membre, comme évoquer précédemment si vous êtes dans le cas où les groupes Active Directory sont synchronisés, vous risquez d’avoir des problemes.

Dans le menu, aller sur Cuztomization -> Property Mapping et depuis la liste, cliquer sur Create.

Sélectionner Scope Mapping 1 puis cliquer sur Next 2.

Nommer la propriété 1, dans le champ scope name indiquer profile 2, dans le champ Expression 3 coller le python disponible sous la capture et cliquer sur Finish 4.

return {
    # Because authentik only saves the user's full name, and has no concept of first and last names,
    # the full name is used as given name.
    # You can override this behaviour in custom mappings, i.e. `request.user.name.split(" ")`
    "name": request.user.name,
    "given_name": request.user.name,
    "preferred_username": request.user.username,
    "nickname": request.user.username,
}

Configurer un mappage pour le groupe

Ce que je vous conseille, si vous souhaitez utiliser des groupes dans Opencloud avec Authentik, c’est de nommer vos groupes avec préfix spécifique pour Opencloud du type GAK-OPENCLOUD et de retourner que ces groupes en ajoutant un nouveau mappage de propriété.

allowed_prefix = "GAK-OCLOUD-"

groups = []

for group in request.user.groups.all():
    if group.name.startswith(allowed_prefix):
        groups.append(group.name)

return {
    "groups": groups
}

Configurer un mappage pour les rôles

Le droit administrateur et le droit de créer des espaces dans Opencloud avec l’authentification OIDC est gère avec un claim roles qui va permettre d’attribuer des droits.

Pour la gestion des rôles, j’ai créé les groupes suivants :

• GAK-OCLOUD-ADMIN
• GAK-OCLOUD-SPACEADMIN

Ensuite j’ai ajouté un nouveau scope roles pour envoyer les rôles en fonction du groupe :

roles = []

for group in user.ak_groups.all():
    if group.name == "GAK-OCLOUD-ADMIN":
        roles.append("opencloudAdmin")
    elif group.name == "GAK-OCLOUD-SPACEADMIN":
        roles.append("opencloudSpaceAdmin")

if not roles:
    roles.append("opencloudUser")

return {
    "roles": roles
}

Configurer le fournisseur Opencloud pour utiliser les nouveaux scopes

Aller dans les propriétés du fournisseur, dans la section Scope, retirer authentik default OAuth Mapping: Openid ‘Profile’ et ajouter ceux qui ont été créés.

Configurer l’authentification OpenID avec Authentik dans Opencloud

Dernière étape, il faut modifier le .env d’Opencloud pour configurer l’authentification OpenID, après cette modification, les comptes locaux ne sont plus accessible.

Exemple de configuration :

# OPENID External
IDP_DOMAIN=authentik.domain.tld
WEB_OIDC_CLIENT_ID=<CLIENT_ID>
WEB_OIDC_SCOPE=openid profile groups email roles
OC_OIDC_ISSUER=https://authentik.domain.tld/application/o/ocloud/
#OC_EXCLUDE_RUN_SERVICES=idp
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none
PROXY_OIDC_SKIP_VERIFICATION=false
PROXY_OIDC_REWRITE_WELLKNOWN=true
PROXY_USER_OIDC_CLAIM=email
PROXY_USER_CS3_CLAIM=email
PROXY_AUTOPROVISION_ACCOUNTS=true
GRAPH_USERNAME_MATCH=none                                                    # Uncomment when PROXY_AUTOPROVISION_ACCOUNTS equal true
PROXY_ROLE_ASSIGNMENT_DRIVER=default
RAPH_ASSIGN_DEFAULT_USER_ROLE=true
PROXY_ROLE_ASSIGNMENT_DRIVER=oidc
PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM=roles
GRAPH_ASSIGN_DEFAULT_USER_ROLE=false

Pour plus d’informations sur la configuration et les explications des variables :

• Integrating external OpenID Connect Identity Providers
• Keycloak Integration

Si vous prévoyez l’utilisation des clients PC ou Mobile, il faut faire une configuration particulière pour chaque Client OIDC : https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/external-idp#client-configuration

La configuration des clients OIDC étant en dur dans les applications, pour chaque client vous devez créer une application et un fournisseur.

Le fichier .env modifié, redémarrer les conteneurs :

docker compose down
docker compose up

Conclusion

OpenCloud s’impose comme une alternative moderne et performante aux solutions de cloud auto-hébergées plus traditionnelles. Grâce à son architecture entièrement développée en Go, la plateforme se montre particulièrement légère, rapide et adaptée aux environnements conteneurisés.

Dans ce tutoriel, nous avons vu comment déployer OpenCloud avec Docker Compose, configurer un reverse proxy, intégrer Collabora Online et mettre en place une authentification centralisée via OIDC avec Authentik. Cette approche permet de bénéficier d’un environnement professionnel, sécurisé et simple à administrer.

Si vous recherchez une solution de stockage moderne avec une faible consommation de ressources et une compatibilité avec les standards actuels d’authentification, OpenCloud mérite clairement votre attention. Son évolution rapide et sa simplicité de prise en main en font un projet à suivre de près pour les années à venir.

FAQ – OpenCloud avec Docker et Authentik