Configurer la politique de sécurité générale de votre portail
Mis à jour le par Patrick Smith
Accès au portail: Public ou privé ?
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.
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.
Politique d'inscription
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 la sous-section Configuration/Inscription du back office de votre portail.
Politique d'inscription fermée
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.
Politique d'inscription ouverte
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.
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.
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).
Activation de reCAPTCHA
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.
Gestion des sessions
Plusieurs paramètres sont disponibles dans la section Configuration > Sécurité du back office pour gérer les sessions de vos utilisateurs.
Délai d'inactivité
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.
Durée maximale de la session
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.
Rendre les cookies de session persistants
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.
Authentification unique
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é :
À propos des utilisateurs locaux et des utilisateurs liés
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
ouOpenID 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.
Il existe 2 méthodes pour lier un compte utilisateur Opendatasoft :
- La première consiste à cliquer sur
Lier votre compte à un compte SAML sur cet espace de travail
ouLier votre compte à un compte OpenID Connect sur cet espace de travail
dans l'onglet Identité des paramètres de compte utilisateur:
- L'autre méthode consiste à établir la liaison lors du processus de création du compte utilisateur en cliquant sur le lien permettant de terminer l'inscription via le protocole SAML. Cette méthode permet d'accélérer le processus de création du compte utilisateur et de lier rapidement ce dernier :
Sélection de la page de connexion par défaut
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/
.
Utilisation des attributs utilisateur pour filtrer les données
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
:
Utilisateur |
|
|
Utilisateur1 | France | Français |
Utilisateur2 | Canada | Français |
Utilisateur3 | États-Unis | Anglais |
Et un jeu de données avec les enregistrements suivants :
|
|
|
Monde | Anglais | Hello world |
France | Français | Bonjour à tous les Français |
Canada | Français | Bonjour à tous les Canadiens |
Canada | Anglais | Hello to all Canadians |
États-Unis | Anglais | Hello to all Americans |
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
|
|
|
France | Français | Bonjour à tous les Français |
L'utilisateur 2 voit
|
|
|
Canada | Français | Bonjour à tous les Canadiens |
Canada | Anglais | Hello to all Canadians |
L'utilisateur 3 voit
|
|
|
États-Unis | Anglais | Hello to all Americans |
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
|
|
|
France | Français | Bonjour à tous les Français |
Canada | Français | Bonjour à tous les Canadiens |
L'utilisateur 2 voit
|
|
|
France | Français | Bonjour à tous les Français |
Canada | Français | Bonjour à tous les Canadiens |
L'utilisateur 3 voit
|
|
|
Monde | Anglais | Hello world |
États-Unis | Anglais | Hello to all Americans |
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
|
|
|
France | French | Bonjour à tous les Français |
L'utilisateur 2 voit
|
|
|
Canada | French | Bonjour à tous les Canadiens |
L'utilisateur 3 voit
|
|
|
États-Unis | Anglais | Hello to all Americans |