Skip to content

Sécurité

Utilisateurs Tock Studio

Authentification

Tock supporte plusieurs systèmes d’authentification pour l’interface d’administration. Il utilise les librairies vert.x correspondantes.

Voici les systèmes disponibles par défaut (tous implémentations de TockAuthProvider) :

Des détails et exemples de configuration sont donnés plus bas dans cette page.

Si ces modèles ne correspondent pas à votre besoin, il est relativement simple d’en développer d’autres en se basant sur les exemples ci-dessus. N’hésitez pas à contribuer au projet et à nous contacter pour toute question!

Rôles

Tock permet d’affecter plusieurs rôles ou niveaux d’habilitations aux utilisateurs dans les interfaces Tock Studio. En fonction du système d’authentification utilisé (par propriétés, 0Auth, etc.) chaque utilisateur se voit assigné un ou plusieurs de ces rôles, lui donnant différents accès dans l’application.

Les rôles disponibles sont définis dans l’enum TockUserRole:

Rôle Description
nlpUser NLP platform user, allowed to qualify and search sentences.
botUser Bot platform user, allowed to create and modify stories, rules and answers.
admin Allowed to update applications and configurations/connectors, import/export intents, sentences, stories, etc..
technicalAdmin Allowed to access encrypted data, import/export application dumps, etc.

La manière de configurer quel utilisateur Tock Studio a quel rôle dépend du mode d’authentification, autrement dit l’implémentation de TockAuthProvider utilisée.

Implémentation par propriétés

La configuration par “propriétés” est utilisée par défaut. Elle ne dépend d’aucun système tiers pour fonctionner.

Ce mode consiste a configurer utilisateurs et rôles par des propriétés ou variables d’environnement. Selon le mode de déploiement utilisé, ces variables peuvent être définies soit directement en ligne de commande, soit dans un descripteur type docker-compose.yml, dockerrun.aws.json ou autre.

Si aucune variable n’est définie (par exemple dans les descripteurs fournis dans le dépôt tock-docker), des valeurs par défaut sont utilisées.

Voici les propriétés et leurs valeurs par défaut :

Variable d’environnement Valeur par défaut Description
tock_users admin@app.com Identifiants (séparés par des virgules).
tock_passwords password Mots de passe (séparés par des virgules).
tock_organizations app Organisations (séparées par des virgules).
tock_roles Vide (ie. tous les rôles) Rôles séparés par des | (puis par des virgules).

Pour définir l’identité et les rôles de plusieurs utilisateurs, on sépare les valeurs par des virgules.

Attention : chacune de ces propriétés doit posséder le même nombre de valeurs (et dans le même ordre) pour permettre de corréler ces valeurs (index par index, pour chaque utilisateur).

Ci-dessous un exemple au format Docker-Compose :

{ "name" : "tock_users", "value" : "alice@tock.ai,bob@tock.ai" },
{ "name" : "tock_passwords", "value" : "secret1,secret2" },
{ "name" : "tock_organizations", "value" : "tock,tock" },
{ "name" : "tock_roles", "value" : "botUser,nlpUser|botUser|admin|technicalAdmin" },

Dans cet exemple, Alice a le rôle botUser, alors que Bob a tous les rôles.

Pour en savoir plus sur le fonctionnement précis de cette implémentation, voir la classe PropertyBasedAuthProvider.

Implémentation 0Auth2 générique

Cette implémentation générique est à utiliser dès que vous souhaitez paramétrer une configuration OAuth2.

Voici les propriétés et leurs valeurs par défaut :

Variable d’environnement Exemple de valeur Description
tock_oauth2_enabled true Activation de l’authentification 0Auth2
tock_oauth2_client_id CLIENT_ID Identifiant pour interroger l’API GitHub
tock_oauth2_secret_key SECRET_KEY Mot de passe pour interroger l’API GitHub
tock_oauth2_site_url https://provider Url du provider oauth2
tock_oauth2_access_token_path /oauth2/token Chemin relatif pour récupérer l’access token
tock_oauth2_authorize_path /oauth2/authorize Timeout vérification de l’identité (API GitHub)
tock_oauth2_userinfo_path /oauth2/userInfo Timeout vérification de l’identité (API GitHub)
tock_oauth2_proxy_host   host du proxy (ne pas indiquer si pas de proxy)
tock_oauth2_proxy_port   port optionnel du proxy

Il est nécessaire d’indiquer en callback url https://[host admin]/rest/callback.

Implémentation 0Auth/GitHub

Cette implémentation assez simpliste est utilisée à titre d’exemple, ainsi que pour la plateforme publique de démo https://demo.tock.ai.

Elle consiste à interroger l’API GitHub pour vérifier l’identité d’un utilisateur à partir de son jeton (access_token).

Remarque : aucune autre donnée du profil GitHub n’est accédée par Tock, à part l’identifiant.

Dans ce mode, activé par la propriété tock_github_oauth_enabled, chaque utilisateur reçoit automatiquement tous les rôles Tock Studio et une organisation (ie. namespace) du même nom que son identifiant.

Voici les propriétés et leurs valeurs par défaut :

Variable d’environnement Valeur par défaut Description
tock_github_oauth_enabled false Activation de l’authentification 0Auth/GitHub.
tock_github_oauth_client_id CLIENT_ID Identifiant pour interroger l’API GitHub.
tock_github_oauth_secret_key SECRET_KEY Mot de passe pour interroger l’API GitHub.
tock_github_api_request_timeout_ms 5000 Timeout vérification de l’identité (API GitHub).

Pour en savoir plus sur le fonctionnement précis de cette implémentation, voir la classe GithubOAuthProvider.

Implémentation AWS/JWT

Une implémentation est fournie utilisant des jetons au format JWT vérifiés par un service AWS (Amazon Web Services).

Ce mode permet de créer une authentification unique (SSO (Single Sign-On) ou Fédération d’identité) dans une infrastructure Cloud AWS. Par défaut, la région ciblée pour vérifier les clefs publiques est la région Irlande (eu-west-1).

Dans ce mode, activé par la propriété tock_aws_jwt_enabled, l’affectation des rôles Tock Studio aux utilisateurs se fait à travers leur jeton JWT et la propriété tock_jwt_custom_roles_mapping.

Voici les propriétés et leurs valeurs par défaut :

Variable d’environnement Valeur par défaut Description
tock_aws_jwt_enabled false Activation de l’authentification AWS/JWT.
tock_jwt_custom_namespace_mapping Vide Organisations (séparées par des virgules).
tock_jwt_custom_roles_mapping Vide Correspondances groupe=rôles séparés par des virgules (puis par des |).
jwt_algorithm ES256 Algorithme de décodage du jeton JWT.
tock_aws_public_key_request_timeout_ms 30000 Timeout vérification des clefs (API AWS).

Ci-dessous un exemple au format Docker-Compose :

{ "name" : "tock_jwt_custom_roles_mapping", "value" : "MY_USER_GROUP=nlpUser,botUser|MY_ADMIN_GROUP=nlpUser,botUser,admin,technicalAdmin" },

Dans cet exemple, les utilisateurs appartenant au groupe MY_USER_GROUP possèdent les rôles nlpUser et botUser, alors que les membres de MY_ADMIN_GROUP ont tous les rôles.

Pour en savoir plus sur le fonctionnement précis de cette implémentation, voir la classe AWSJWTAuthProvider.

Données

Les utilisateurs pouvant transmettre aux bots des données personnelles à travers leurs conversations, il est important de réfléchir à la nature des données manipulées dans Tock Studio ou stockées par Tock, et de mettre en oeuvre des mécanismes de protection appropriés (anonymisation, chiffrement, durée de rétention, restrictions d’accès basées sur des rôles, etc.).

Voir en particulier la réglementation RGPD.

Chiffrement des données

Chiffrement de la base

Il est recommandé de déployer vos bases de données MongoDB en mode chiffré.

Chiffrement applicatif

Tock peut réaliser un chiffrement applicatif (facultatif) de certains champs en base de données, indépendamment du chiffrement de la base elle-même.

C’est le rôle de la variable d’environnement tock_encrypt_pass, qui permet d’indiquer un mot de passe pour chiffrer et déchiffrer ces champs. Par défaut en environnement prod, Tock chiffre toutes les données utilisateurs jugées sensibles à condition que tock_encrypt_pass soit défini.

Pour plus de détails, vous pouvez vous réferrer au code source.

Remarque : définir tock_encrypt_pass est requis pour utiliser les fonctions d’anonymisation d’entités NLP dans les interfaces Tock Studio.

Anonymisation

Il est souvent souhaitable que certaines phrases soient anonymisées que ce soit dans les logs (journalisation) ou dans l’interface (Tock Studio). Par exemple, des coordonnées, numéros de cartes de fidélité, etc. ne devraient être lus ni par les utilisateurs de Tock Studio ni par les administrateurs de la plateforme.

Par le framework

Pour anonymiser ces données, Tock met à disposition dans son framework une solution basée sur des expressions régulières (RegExp) dont l’interface de base est StringObfuscator.

Par le modèle NLP

Tock permet également d’anonymiser dans Tock Studio (vue Inbox notamment.) les valeurs des entités reconnues par le modèle NLP.

Cette anonymisation par types d’entités se configure dans la vue Language Understanding > Entities. Seuls les utilisateurs ayant un rôle admin ou technicalAdmin dans Tock Studio peuvent activer/désactiver cette fonctionnalité.

Pour en savoir plus, voir Rôles.

Dans les vues où les phrases sont affichées anonymisées (Inbox, Search par exemple), un admin ou technicalAdmin peut décider d’afficher quand même (pour lui-même uniquement) une phrase non anonymisée grâce à l’action Reveal the sentence (oeil ouvert).

Remarque : définir tock_encrypt_pass est requis pour utiliser les fonctions d’anonymisation d’entités NLP dans les interfaces Tock Studio.

Stockage & conservation

Tock stocke automatiquement différents types de données, allant d’informations peu sensibles (configuration de Stories et réponses du bot, structure des intentions, statistiques de navigation tous utilisateurs confondus, etc.) à des données plus personnelles (détails des conversations, préférences utilisateurs, etc.).

En fonction de leur nature et leur utilisation dans le fonctionnement de Tock (NLP, supervision, debug…), ces données ont des durées de rétention spécifiques, et configurables. Chaque utilisateur de Tock décide et configure combien de temps les données stockées sont conservées, en fonction de ses besoins.

La section Installation > Conservation des données décrit les différents types de données conservées et comment modifier leur durée de rétention.