Configurer la politique de sécurité générale de votre portail

Le choix le plus important consiste à déterminer si votre portail doit être public ou privé. Il s'agit de savoir si des utilisateurs non authentifiés seront en mesure d'accéder au portail ou s'il sera demandé aux visiteurs de s'inscrire pour y accéder.

Le fait de rendre votre portail public ne signifie pas que tout le monde aura accès à l'ensemble des jeux de données ! À l'aide des paramètres de sécurité précis pour les jeux de données et de paramètres explicites pour chacun d'entre eux, il vous sera toujours possible de restreindre ce à quoi les utilisateurs ont accès.

Voir la section dédiée pour plus d'informations sur la sécurité des jeux de données.

Ce paramètre se trouve dans la sous-section sécurité de la section configuration de l'interface d'administration de votre portail.

Notez que si vous décidez de ne pas autoriser les utilisateurs non authentifiés à accéder à votre portail, ils seront redirigés vers la page de connexion, sauf si vous préférez qu'ils soient redirigés vers une page spécifique que vous avez créée.

Peu importe votre choix de public ou privé, vous pouvez alors décider qui pourra devenir membre enregistré de votre portail. Pour cela, rendez-vous dans Accès > Connexion & Inscription du back office de votre portail.

N'oubliez pas d'ajouter le bouton d'inscription à votre menu d'en-tête, sinon les utilisateurs ne verront pas le formulaire d'inscription avant d'essayer d'accéder à une zone de votre portail dont l'accès est restreint.

Si vous décidez de ne pas autoriser les personnes à s'inscrire librement, le seul moyen d'ajouter des membres à votre portail sera d'envoyer des invitations directes par e-mail.

Si vous autorisez les inscriptions publiques, il vous faudra alors déterminer si vous souhaitez approuver manuellement ou non chaque demande d'accès à votre portail. Notez que, quelle que soit votre décision, chaque membre du portail autorisé à gérer les utilisateurs recevra une notification pour chaque nouvelle demande d'accès.

La procédure d'inscription est généralement très simple : une adresse e-mail, un mot de passe, et le tour est joué. Vous pouvez décider de personnaliser l'expérience en utilisant un texte personnalisé comme avis de non-responsabilité, en exigeant des utilisateurs qu'ils acceptent vos conditions d'utilisation et même qu'ils laissent un message à l'administrateur du portail (utile lorsque vous souhaitez approuver manuellement les demandes d'accès).

reCAPTCHA protège vos formulaires publics contre le spam et les abus en faisant la distinction entre les humains et les ordinateurs dans votre portail. Cette option est désactivée par défaut.

S'il est désactivé, une limite de débit est appliquée pour restreindre le nombre de requêtes qu'une seule adresse IP peut adresser au serveur au cours d'une période donnée. Cette limite ne peut pas être modifiée. Veuillez nous contacter si vous rencontrez des problèmes.

Plusieurs paramètres sont disponibles dans la section Configuration > Sécurité du back office pour gérer les sessions de vos utilisateurs.

Par défaut, tous les utilisateurs authentifiés sont automatiquement déconnectés après une période d'inactivité de deux semaines. Cette durée, exprimée en minutes, peut être personnalisée ici. Notez que ce paramètre s'applique aux utilisateurs inactifs ; chaque requête d'un utilisateur sur le portail réinitialise le délai d'attente.

Par défaut, tous les utilisateurs authentifiés sont automatiquement déconnectés après une période de deux semaines, même s'ils restent actifs (voir "Délai d'inactivité" ci-dessus). Cette durée, exprimée en minutes, peut être personnalisée ici.

Par défaut, les cookies de session sont configurés pour être persistants dans les navigateurs jusqu'à ce qu'ils expirent d'eux-mêmes. Toutefois, vous pouvez choisir de supprimer les cookies de session actifs lorsque le navigateur est fermé. Pour ce faire, désactivez la case à cocher ici.

Notez que le comportement peut changer en fonction du navigateur. La modification de ce paramètre ne s'applique qu'aux nouvelles sessions d'utilisateurs. Les utilisateurs déjà authentifiés conserveront leur cookie précédent et sa date d'expiration.

Si votre organisation possède déjà son propre système de gestion des identités, vous pouvez mettre en place un pont entre votre fournisseur d'identité et votre portail Opendatasoft. Cela donnera un accès général à votre portail à chacun des membres de votre organisation.

Opendatasoft prend en charge deux types de fournisseurs d'identité :

• Authentification unique avec SAML

• Authentification unique avec OpenID Connect

Lorsqu'un fournisseur d'identité SAML ou OpenID Connect est configuré sur un espace de travail, un utilisateur peut appartenir à trois catégories.

• Un utilisateur Opendatasoft standard qui a été invité par e-mail ou qui s'est inscrit sur un espace de travail : cet utilisateur se connecte sur l'espace grâce à l'interface de connexion standard avec son nom d'utilisateur et son mot de passe Opendatasoft habituels, et le compte est accessible dans tout le réseau Opendatasoft. Les utilisateurs Opendatasoft sont représentés sur la plateforme par le pictogramme  

  

• Un utilisateur local qui s'authentifie via le fournisseur d'identité de l'organisation : cet utilisateur se connecte sur l'espace de travail exclusivement via le fournisseur d'identité de l'organisation, et n'étant disponible que sur un espace de travail précis, il peut avoir un accès limité à certaines fonctionnalités basées sur le réseau Opendatasoft. Les utilisateurs locaux sont représentés sur la plateforme par le pictogramme

  

• Un utilisateur lié qui a un compte Opendatasoft standard associé sur cet espace de travail précis à une identité du fournisseur d'identité de l'organisation. Cet utilisateur est un utilisateur Opendatasoft standard qui peut à la fois s'authentifier via l'interface d'authentification Opendatasoft et via le fournisseur d'identité de l'organisation. Les utilisateurs liés étant des utilisateurs Opendatasoft disposant de la capacité de se connecter via SAML ou OpenID Connect, ils sont représentés sur la plateforme par les deux pictogrammes

  

  

Utilisateur local

Chaque utilisateur disposant d'un compte utilisateur auprès du fournisseur d'identité approuvé par un espace de travail, mais ne disposant pas d'un compte utilisateur Opendatasoft, peut se connecter. Lors de la première connexion, un utilisateur local sera créé pour l'utilisateur, en fonction des paramètres du fournisseur d'identité de l'espace de travail.

Ces utilisateurs locaux disposent des permissions pour explorer les jeux de données publics de l'espace de travail par défaut. Des permissions supplémentaires peuvent être octroyées à ces utilisateurs au niveau de l'espace de travail, pour des jeux de données individuels ou via des groupes (autres que les groupes Utilisateurs SAML ou Utilisateurs OpenID Connect, auxquels ils appartiennent automatiquement).

La création d'utilisateurs locaux via l'authentification sur un fournisseur d'identité peut être désactivée en cochant la case "Désactiver le provisionnement d'utilisateurs locaux" dans la configuration du fournisseur d'identité (SAML ou OpenID Connect). La désactivation du provisionnement d'utilisateurs locaux n'empêchera pas les utilisateurs locaux existants de se connecter.

Utilisateur lié

Les utilisateurs disposant d'un compte utilisateur Opendatasoft peuvent lier ce dernier à un autre compte du fournisseur d'identité. Cette procédure s'appelle : liaison de comptes.

Une fois la liaison établie, les utilisateurs liés qui se connectent via leur fournisseur d'identité seront connectés à leur compte utilisateur Opendatasoft. Néanmoins, ils seront toujours en mesure de se connecter avec leur mot de passe Opendatasoft.

Cliquez sur Lier votre compte à un compte SAML sur cet espace de travail ou Lier votre compte à un compte OpenID Connect sur cet espace de travail dans l'onglet Identité des paramètres de compte utilisateur:

La plateforme Opendatasoft permet de choisir la page de connexion qui s'affichera lorsque les utilisateurs cliqueront sur un lien d'identification ou essaieront d'accéder à une page à accès limité.

Si la page de connexion du fournisseur d'identité est sélectionnée par défaut, le processus d'identification (SAML ou OpenID Connect) sera démarré automatiquement lorsqu'un utilisateur non authentifié cliquera sur le lien de connexion ou essaiera d'accéder à une page dont l'accès est limité, comme l'interface d'administration. Lorsque la page de connexion du fournisseur d'identité est sélectionnée, les utilisateurs qui souhaitent se connecter à la plateforme avec leurs identifiants Opendatasoft auront la possibilité de le faire en se rendant sur la page de connexion de l'espace de travail à l'adresse https://<platform-url>/login/.

Les utilisateurs qui se sont connectés via la fédération d'identité (SAML 2.0 ou OpenID Connect) peuvent avoir défini des attributs de profil spécifiques. Ces derniers peuvent être utilisés pour filtrer le contenu des jeux de données auxquels ces utilisateurs ont accès.

Pour ce faire, vous pouvez modifier la configuration de sécurité d'un jeu de données spécifique et utiliser la fonction #attr dans la requête de filtre du groupe de sécurité SAML ou OpenID Connect associé à ce jeu de données. Ainsi, les utilisateurs appartenant à ces groupes seront uniquement en mesure de voir les enregistrements de jeu de données qui correspondent à la requête de filtrage, comme expliqué ci-dessous.

La fonction #attr vous permet de filtrer les enregistrements d'un jeu de données de façon que seuls les enregistrements renvoyés soient ceux qui correspondent à une valeur définie dans les attributs utilisateur envoyés par le fournisseur d'identité. Dans les exemples suivants, nous partons du principe que nous avons 3 utilisateurs avec des noms d'utilisateur et attributs SAML respectifs user-country et user-language :

Et un jeu de données avec les enregistrements suivants :

Nous pouvons limiter ces utilisateurs de façon qu'ils voient uniquement les messages concernant leur pays respectif en utilisant la requête "#attr(country, user-country)".

L'utilisateur 1 voit

L'utilisateur 2 voit

L'utilisateur 3 voit

Nous pouvons également limiter ces utilisateurs de façon qu'ils voient uniquement les messages dans leur langue respective en utilisant la requête "#attr(language, user-language)".

L'utilisateur 1 voit

L'utilisateur 2 voit

L'utilisateur 3 voit

Cette fonction étant propre au langage de requête, elle peut également être combinée aux opérateurs habituels. Nous pouvons, par exemple, limiter les utilisateurs de façon qu'ils voient uniquement les messages adaptés à leur pays et à leur langue en utilisant la requête #attr(language, user-language) AND #attr(country, user-country).

L'utilisateur 1 voit

L'utilisateur 2 voit

L'utilisateur 3 voit