Accueil
» Comment faire
»
Connectez ownCloud Infinite Scale à Keycloak avec OIDC
Connectez ownCloud Infinite Scale à Keycloak avec OIDC
Il arrive souvent que les utilisateurs accèdent à la page de connexion Keycloak, s'authentifient, puis soient redirigés vers l'écran de connexion d'ownCloud Infinite Scale, ou rencontrent une erreur « utilisateur inconnu ». Les causes habituelles sont un émetteur de domaine incompatible, un client web copié d'une autre version d'exemple, ou une revendication d'identité ne correspondant pas à un compte oCIS. Configurez Keycloak comme fournisseur OpenID Connect externe (OIDC) d'oCIS, assurez-vous que ces trois valeurs sont correctement alignées et vérifiez que le navigateur et les clients peuvent accéder au fournisseur via HTTPS.
Ce guide utilise des hôtes fictifs : cloud.example.comun pour oCIS et un sso.example.compour Keycloak. La configuration fait référence à la documentation d’ownCloud Infinite Scale 8.2 ; comparez les noms avec la documentation de votre version installée avant de les appliquer. Ceci concerne Infinite Scale (oCIS), et non ownCloud Server 10.
1. Vérifiez le domaine et le point de terminaison de découverte
Un fournisseur d'identité (IdP) authentifie les utilisateurs pour un autre service. OpenID Connect est le protocole de connexion qui permet à oCIS de faire confiance aux informations de connexion et d'identité de Keycloak. Un domaine est un ensemble distinct d'utilisateurs, de clients et de paramètres Keycloak. Choisissez le domaine qui servira à oCIS, puis indiquez son URL d'émetteur : pour le domaine d'exemple ocis, il s'agit de https://sso.example.com/realms/ocis.
Avant de modifier oCIS, ouvrez-le https://sso.example.com/realms/ocis/.well-known/openid-configurationdans un navigateur. Ce document de découverte OpenID Connect décrit les points de terminaison du fournisseur. Vérifiez que sa issuervaleur correspond exactement à l'URL du domaine, y compris le schéma, l'hôte, la casse et le chemin. L'émetteur ne doit pas être la page d'administration ni l'URL de découverte la plus longue. Le certificat TLS du fournisseur doit être approuvé par les navigateurs des utilisateurs et par le serveur/conteneur oCIS.
Le document de découverte doit indiquer l'émetteur exact du domaine configuré dans oCIS.
Si l'URL de découverte ne se charge pas, commencez par résoudre les problèmes de DNS, de routage de proxy inverse, de pare-feu ou de certificat. Une réponse positive du navigateur ne prouve pas à elle seule que le conteneur oCIS peut accéder à Keycloak ; vérifiez également l'accès réseau depuis le réseau de déploiement du serveur. Les règles de découverte OpenID Connect exigent que l'émetteur renvoyé identifie le même fournisseur. Consultez la spécification OpenID Connect Discovery .
2. Associez le client Keycloak à l'application web oCIS.
Utilisez l' exemple de déploiement ownCloud Keycloak maintenu comme point de départ et faites correspondre son fichier de domaine à votre version d'oCIS. N'utilisez pas de versions différentes : l'exemple Compose actuel utilise l'ID client web web, tandis que les notes d'installation plus anciennes mentionnent un autre ID ocis-web. Keycloak et oCIS doivent utiliser le même ID client.
Dans Keycloak, ouvrez le domaine et le client web sélectionnés. Faites correspondre le flux de connexion et l'ID client à l'exemple ownCloud. Définissez les URI de redirection valides aux adresses de rappel exactes requises par ce domaine, en utilisant l'hôte HTTPS public. Configurez les origines web uniquement selon les exigences du modèle. Le caractère générique ci-dessous est donné à titre d'illustration et ne constitue pas une recommandation pour la production : des schémas de redirection trop larges peuvent autoriser des destinations non souhaitées. Les étiquettes varient selon la version de Keycloak.
Utilisez l'URI de redirection et l'ID client du modèle de domaine qui correspondent à votre version d'oCIS ; les valeurs affichées sont des exemples.
Assurez-vous que le nom d'hôte public de Keycloak reste stable. Si la connexion TLS se termine par un proxy inverse, configurez son nom d'hôte public et ses en-têtes de proxy de confiance, sinon les redirections risquent d'utiliser un schéma ou un hôte incorrect ; suivez les instructions relatives aux proxys inverses de Keycloak . Remplacez les identifiants d'administrateur de démonstration avant de rendre Keycloak accessible.
3. Indiquez à oCIS le même émetteur et le même client.
Ajoutez ces variables au service oCIS dans votre configuration de déploiement, en conservant ses autres paramètres et secrets. L'exemple utilise des URL fictives et l'ID client d'exemple actuel :
OCIS_URLIl s'agit de l'adresse oCIS publique ; l'identifiant de l'émetteur et celui du client doivent correspondre exactement à ceux de Keycloak. La réécriture active le chemin de découverte utilisé par les clients de bureau, Android et iOS. L'exclusion de idpcette ligne désactive le fournisseur intégré dans les déploiements avec un fournisseur d'identité externe ; omettez-la si votre configuration utilise intentionnellement ce service.
Ces paramètres oCIS configurent l'authentification pour utiliser Keycloak et acheminent la découverte OIDC vers le fournisseur externe.
Appliquez les modifications lors du redémarrage normal de votre déploiement. Avec Docker Compose, exécutez la commande docker compose up -ddepuis le répertoire Compose pour recréer les services modifiés, puis consultez les journaux oCIS. Utilisez des certificats TLS de confiance en production. L'exemple ownCloud indique INSECURE=truequ'il s'agit d'une option de certificat auto-signé local ; supprimez-la ou définissez-la sur « false » sur un serveur exposé à Internet. ownCloud recommande également de ne pas l'utiliser PROXY_OIDC_INSECUREen production.
4. Déterminer comment oCIS doit identifier les utilisateurs
Une revendication est un champ d'identité OIDC, tel que sub` username`, preferred_username`username` ou email`userid`. oCIS l'utilise pour trouver un compte. Pour les utilisateurs existants, associez-la à l'attribut qu'ils utilisent déjà : nom d'utilisateur, adresse e-mail ou identifiant utilisateur. Une incohérence peut entraîner l'affichage du message « Utilisateur introuvable » après l'acceptation de la connexion par Keycloak.
Pour créer des comptes lors de la première connexion, configurez l'identifiant PROXY_AUTOPROVISION_ACCOUNTS=trueuniquement lorsque cela est prévu et après avoir activé les écritures dans le système de gestion des utilisateurs oCIS Graph. L'identifiant doit être unique, stable et ne jamais être réattribué. ownCloud le considère subcomme approprié ; utilisez l'adresse e-mail ou le nom d'utilisateur préféré uniquement s'il ne peut pas être modifié. Assurez-vous que les revendications de création et de recherche restent cohérentes.
Vérifiez que Keycloak renvoie bien la revendication choisie dans la réponse token ou userinfo. Si l'approvisionnement automatique est désactivé, aucun nouvel utilisateur n'est créé lors de la connexion ; avec un backend Graph en lecture seule, l'approvisionnement peut échouer. N'ajoutez le mappage de groupe ou de rôle qu'une fois la connexion fonctionnelle. Consultez la documentation d'ownCloud 8.2 relative au proxy et à l'approvisionnement automatique avant d'activer l'accès en écriture ou de modifier les mappages d'identité.
Vérifiez le processus de connexion complet
Ouvrez oCIS dans une fenêtre de navigation privée et connectez-vous. Vous devriez accéder au domaine Keycloak, vous authentifier, puis revenir à l'hôte oCIS correspondant au compte attendu. Commencez par tester un compte existant. Si le provisionnement est activé, testez un nouvel utilisateur approuvé et vérifiez qu'il est bien créé avec le nom d'utilisateur prévu. Déconnectez-vous et reconnectez-vous.
Après une authentification réussie, le navigateur devrait revenir à l'interface de fichiers cloud.
Pour la découverte sur ordinateur ou mobile, ouvrezhttps://cloud.example.com/.well-known/openid-configuration ; la réécriture doit exposer les informations du fournisseur Keycloak. Une boucle de connexion indique une incompatibilité d'hôte de redirection ou de schéma. Un utilisateur rejeté après une connexion réussie indique une revendication manquante ou une incompatibilité entre PROXY_USER_OIDC_CLAIMet PROXY_USER_CS3_CLAIM.