L’authentification dans Qlik Sense - Quelles possibilités ?

Objectif

L’objectif de ce wiki sous forme de documentation est de présenter les différentes possibilités d’authentification dans l'outil QlikSense, le but étant de sécuriser de manière centralisée le serveur Qlik Sense (cet article ne parle pas du tout du desktop) pour que celui-ci ne soit pas accessible directement depuis l’extérieur. Vous pourrez ainsi configurer et déployer des applications Qlik Sense en toute sécurité et ce sur différents environnements.

L’authentification sous QlikSense

Qlik Sense demande toujours à un système externe de vérifier qui est l'utilisateur et s'il peut le prouver. L'interaction entre Qlik Sense et le fournisseur d'identité externe est gérée par des modules d'authentification des connections.

Pour qu'un module communique avec Qlik Sense, il doit être fiable. La sécurité de la couche de transport (TLS) et l'authentification par certificat sont utilisées pour autoriser les composants externes comme une application Web à communiquer avec Qlik Sense.

Dans Qlik Sense, l'authentification d'un utilisateur se compose de trois étapes distinctes :

1. Module d’authentification : obtenez l'identité et les informations d'identification de l'utilisateur.
2. Module d’authentification : demandez à un système externe de vérifier l'identité de l'utilisateur à l'aide des informations d'identification.
3. Transférez l'utilisateur vers Qlik Sense à l'aide de l'API Ticket, de l'API Session, des en-têtes ou de SAML.

Les deux premières étapes sont toujours gérées par le module d'authentification. Il appartient au module d'authentification de vérifier l'utilisateur de manière appropriée.

La troisième étape peut être effectuée des manières suivantes :

• Utilisation de l'API Ticket, qui transfère l'utilisateur et les propriétés de l'utilisateur à l'aide d'un ticket unique.
• À l'aide de l'API Session, un module externe peut transférer des sessions Web qui identifient l'utilisateur et ses propriétés vers Qlik Sense.
• Utilisation d'en-têtes (headers), avec lesquels un système de confiance peut transférer l'utilisateur à l'aide d'en-têtes HTTP. Il s'agit d'une solution courante pour l'intégration avec les systèmes d'authentification unique (SSO).
• Qlik Sense peut être configuré pour gérer les autorisations des utilisateurs anonymes, à l'aide, par exemple, de SAML.

Les solutions d’authentification sous Qlik Sense

Authentification Qlik Sense par défaut (windows/ntlm)

Après une installation par défaut de Qlik Sense, le service de proxy Qlik Sense (QPS) comprend un module qui gère l'authentification des utilisateurs Microsoft Windows. Le module prend en charge l'utilisation d’Apache Kerberos et NTLM.

Il serait donc possible de créer un second nœud QlikSense ne contenant que ce service proxy, sur la DMZ. L’utilisateur ouvrira alors une URL pointant sur la DMZ et s’authentifiera au travers d’une pop-up (ou automatiquement selon le paramétrage du navigateur) en renseignant ses identifiants Windows.

Contraintes :

• Le compte utilisateur de service utilisé pour le service proxy doit avoir un accès complet aux cluster de répertoires partagés du nœud central.
• Plusieurs ports doivent être ouverts entre le nœud central et la DMZ sur le Windows server.
• Pour que l’authentification sous Windows puisse se mettre en place, la DMZ doit être rattachée au Domain.

Ces contraintes font que le serveur contenant le service proxy ne peut plus être considéré comme une DMZ puisque de multiples connexions se feront avec le nœud central et au travers d’un compte de domaine.

Le ticket Qlik Sense

Cette méthode consiste à demander un ticket auprès de l’API Qlik Proxy après s’être identifié. L’utilisateur envoie ce ticket à QlikSense et, s’il est valide, il est alors authentifié. Pour que le ticket soit sûr, certaines restrictions sont appliquées :

• Un ticket n’est valide qu’une seule fois.
• Un ticket n’est valide que pendant une courte période.
• Un ticket est généré de façon aléatoire et donc difficile à obtenir.

Toutes les communications entre le module d’authentification et le service proxy utilisent la couche TLS et doivent autoriser les certificats.

Schéma présentant les flux lors d’une authentification par ticket :

1. L’utilisateur accède à Qlik Sense via son identifiant et mots de passe.
2. Qlik Sense redirige l’utilisateur vers le module d’authentification qui va vérifier son identité avec un fournisseur d’identité (identity provider) externe à Qlik.
3. Une fois que les identifiants ont été vérifiés, un ticket est demandé au service proxy (QPS).
4. Le module d’authentification reçoit un ticket.
5. L’utilisateur est redirigé vers le QPS avec le ticket, le service vérifie que ce ticket est valide.
6. Une session est créée pour l’utilisateur.
7. L’utilisateur est désormais connecté.

Contraintes :

• Nécessite la mise en place d’un module d’authentification forte et donc de ressources ayant les connaissances dans le langage utilisé. Quelques exemples :
  • Node.js.
  • Powershell.
  • ASP.
  • Java.

>> Solution la plus couramment utilisée pour une ouverture de QlikSense sur internet notamment lors de l’intégration dans un portail existant avec un système d’authentification déjà en place. Le module d’authentification se trouvant sur la DMZ et le serveur QlikSense derrière un pare-feu.

La session qlik sense

Cette solution permet au service Qlik Sense Proxy (QPS) d'utiliser une session d'un système externe pour valider l'identité de l'utilisateur et gérer le contrôle d’accès.

Toutes les communications entre le module d'authentification et le QPS utilisent Transport Layer Security (TLS) et doivent être autorisées à l'aide de certificats.

Schéma présentant les flux lors d’une authentification par session :

1. La technique permet aux utilisateurs d’accéder au fournisseur d’identité qui peut par exemple être intégré à un portail. Une fois l’identité vérifiée, le fournisseur d’identité créé une nouvelle session.
2. Le fournisseur d’identité enregistre un jeton de session auprès du module de session QlikSense.
3. Le fournisseur d'identité définit le jeton de session comme cookie de session.
4. L’utilisateur accède au service proxy pour obtenir un contenu.
5. Le QPS valide la session au travers du module dédié.
6. Si la session est valide, le user-agent est alors authentifié, sa requête exécutée.

Contraintes :

• Nécessite la mise en place d’un fournisseur d’identité et donc de ressources ayant les connaissances dans le langage utilisé. Quelques exemples :
  • Node.js.
  • Powershell.
  • ASP.
• Le client et le module de session doivent se trouver sur le même nom de domaine
• Semblable à la solution par ticket mais moins souvent implémentée. 2e contrainte à confirmer.

Le header qlik sense

Cette solution est souvent utilisée avec un reverse proxy en SSO pour authentifier l’utilisateur.

L'authentification par en-tête est l'une des méthodes d'authentification de l'environnement Qlik Sense. Il est facile à mettre en place et donc un bon choix pour un environnement de développement ou entre des systèmes de confiance.

Lors de l'utilisation de l'authentification d'en-tête, l'authentification traditionnelle est contournée et à la place, les paramètres transmis dans l'en-tête HTTP sont utilisés pour identifier l'utilisateur autorisé actuel. Cela en fait une méthode idéale à utiliser dans un système de confiance où un système de gestion d'identité existant a déjà identifié l'utilisateur donné en tant qu'utilisateur autorisé à accéder à Qlik Sense.

Schéma présentant les flux lors d’une authentification par header :

1. L’utilisateur accède au système et s’authentifie auprès du reverse proxy.
2. Le reverse proxy injecte le nom d’utilisateur dans un entête http défini. Toutes les requêtes vers le service proxy doivent alors contenir cet en-tête.
3. L’utilisateur est authentifié.

Contraintes :

• Pour que cette solution soit sécurisée, l'utilisateur final ne doit pas être en mesure de communiquer directement avec le QPS mais doit au contraire être obligé de passer par un reverse proxy ou un filtre pour qu’une requête s’exécute.
• Le reverse proxy/filtre doit être configuré pour conserver le nom d'hôte, c'est-à-dire que l'en-tête d'hôte du client ne doit pas être modifié ce qui peut complexifier les protocoles.

>> Solution moins sécurisée

Le saml qlik sense

Ce langage est un format de données standard ouvert basé sur le XML pour l’échange de données d’authentification et d’autorisation entre le fournisseur d’identité (Identity provider) et le fournisseur de services/QlikSense (Service provider). SAML est généralement utilisé pour l'authentification unique (Single Sign On - SSO) du navigateur Web.

Exemples avec des fournisseurs d’identité courants :

• Okta.
• Auth0.
• ADFS.
• Onelogin.
• Google.
• Salesforce.

Contraintes :

• Nécessite la mise en place d’un fournisseur d’identité centralisé et donc de ressources ayant les connaissances sur le fournisseur d’identité.
• Qlik Sense ne prend pas en charge la validation de signature de message SAML.

>> Autre solution souvent utilisée, seule une ouverture du port 443 doit être active entre le reverse proxy et le proxy Qlik.

Le jwt qlik sense

Json Web Token (JWT) est un type de transmission sécurisée d'informations entre deux parties en tant qu'objet JavaScript Object Notation (JSON).

JWT est utilisé pour l'authentification et l'autorisation des applications Web au sein du système d’information. Étant donné que JWT permet la connexion unique (SSO), il minimise le nombre de fois qu'un utilisateur doit se connecter aux applications cloud ou portées sur un datacenter ainsi qu’aux sites Web. Il joue le rôle d’un serveur d’authentification.

L’authentification est effectuée avec un jeton au format JSON signé avec la clé privée d'un certificat spécifique. Qlik Sense vérifiera si la signature est correcte en fonction du certificat fourni dans la configuration du proxy virtuel et si c’est le cas Qlik Sense offrira la connexion.

Un JWT se compose de trois parties : un en-tête, le payload et une signature.

• L'en-tête se compose généralement de deux parties : type (typ) et algorithme (alg). L'algorithme est utilisé pour générer la signature.
• Le payload est un objet JSON qui comprend les revendications que vous souhaitez faire. Les revendications sont des déclarations sur une entité (généralement l'utilisateur) et des métadonnées supplémentaires.
• La signature est utilisée pour vérifier l'identité de l'expéditeur JWT et pour s'assurer que le message n'a pas été falsifié.

L'authentification est effectuée en vérifiant la signature. Si la signature est valide, l'accès est accordé à Qlik Sense.

Contraintes :

• Nécessite l’implémentation d’un fournisseur d’identité et donc de charges de travail complémentaires et ainsi de ressources ayant les connaissances JSON.
• Les JWTs cryptés ne sont pas supportés (en utilisant le protocol https, tout le trafic est crypté, y compris les JWTs).

Vous recherchez une formation Qlik Sense ? Consultez notre catalogue de formations Qlik Sense en suivant ce lien : Formation Qlik Sense

Retour page précédente Retour au Wiki

Vous cherchez des experts dans la gestion de la sécurité et l’authentification Qlik sense, Next decision peut vous accompagner. Contactez-nous !