Application de la démarche scientifique

Interfaçage entre un service REST protégé par une authentification forte

Réalisé par HAMICHE Abderrahmane

Encadré par Gabriel HANOTAUX&
WIRANE Taoufik
 Remerciements

Je tiens tout d'abord à exprimer ma gratitude envers Gabriel HANOTAUX, mon

tuteur en entreprise, pour m'avoir offert cette opportunité et pour m'avoir
accompagné avec bienveillance et patience. Son expertise, ses conseils et son
soutien m'ont permis de progresser considérablement dans mes compétences
professionnelles.

Je souhaite également remercier chaleureusement mon collègue Mathieu GIRARD

pour son aide précieuse et sa disponibilité. Sa collaboration a été essentielle pour
la réussite de mes missions, et j'ai beaucoup appris à ses côtés.

Enfin, je tiens à exprimer ma gratitude envers mon tuteur à l'école, Taoufik

WIRANE, pour ses précieux conseils et son suivi attentif. Sa bienveillance et ses
encouragements m'ont permis de progresser dans mes compétences académiques
et de mieux appréhender les enjeux de mon futur métier.

2
Résumé
Le présent rapport traite de la problématique de l'interfaçage de PowerBI avec une API
Rest disposant d'une authentification forte, dans le contexte d'un projet de reporting SLA
développé par l'entreprise SLIB. Le rapport vise à proposer une solution pour la définition
des crédentials des comptes de service se connectant au service de reporting SLA et le
stockage sécurisé de ces informations au sein de PowerBI.

Dans la première partie du rapport, je présente la problématique ainsi que l'entreprise et

son activité. J'expose également le cadre de ma mission et l'analyse de l'existant qui a été
menée pour prouver l'existence du problème.

Dans la deuxième partie, je présente l'état de l'art ainsi que les recherches menées pour
identifier les solutions optimales pour répondre à la problématique posée. J'expose les
différentes solutions envisageables, leur pertinence et les critères de choix qui ont été
établis pour déterminer la meilleure solution.

Dans la troisième partie, je présente la solution choisie et son déploiement. J'analyse les
résultats obtenus et présente également des pistes d'amélioration pour la solution retenue.

Enfin, je conclus sur les résultats obtenus et l'importance de la problématique traitée dans
le contexte de l'entreprise SLIB. Je présente également une bibliographie et un glossaire
pour faciliter la compréhension du rapport.

Abstract
The present report deals with the problem of interfacing PowerBI with a Rest API having
strong authentication, in the context of an SLA reporting project developed by the company
SLIB. The report aims to propose a solution for defining service account credentials
connecting to the SLA reporting service and the secure storage of this information within
PowerBI.

In the first part of the report, I introduce the problem as well as the company and its activity.
I also present the framework of our mission and the existing analysis that was conducted to
prove the existence of the problem.

In the second part, I present the state of the art as well as the research conducted to identify
optimal solutions to address the problem posed. I present the different possible solutions,
their relevance, and the selection criteria established to determine the best solution.

In the third part, I present the chosen solution and its deployment. I analyze the results
obtained and also present avenues for improving the selected solution.

Finally, I conclude on the results obtained and the importance of the problem addressed in
the context of the SLIB company. I also provide a bibliography and glossary to facilitate the
understanding of the report.

3
 Tables des matières
I. Caractérisation de la problématique......................................................................... 6
1. Introduction............................................................................................................. 6
2. Présentation de l’entreprise ..................................................................................... 6
3. Présentation de l’ADS. ............................................................................................. 7
4. Cadrage de la problématique ................................................................................... 7
• A quel(s) problème(s) se rapportent mes missions en entreprises ? ............................. 7
5. Analyse de l’existant ................................................................................................ 8
• Prouver l’existence du problème ................................................................................... 8
II. Identification de la solution optimale ....................................................................... 9
1) Etat de l’art .............................................................................................................. 9
• Aspects théoriques rattachés à ma problématique......................................................... 9
- API [1] ......................................................................................................................... 9
✓ Comment sécuriser une API [1] [4] ........................................................................ 11
- Power BI [2] .............................................................................................................. 18
- RH-SSO [3] ............................................................................................................... 19
• Recherche de la problématique dans d’autres entreprises/Domaines ......................... 21
Connecteur personnalisé [2]: ..................................................................................... 21
Solution adoptée par JCDecaux [1] .............................................................................. 25
III. Recherche de solution ............................................................................................ 28
• Solutions envisageables & pertinence ......................................................................... 28
Solution 1 (configuration OpenID Connect dans l’API) [4] : ....................................... 28
Solution 2 (api Key) [1] : .............................................................................................. 29
Solution 3 (mettre en place un connecteur personnaliser Power BI) [2] : .................... 30
IV. Choix des solution idéales ...................................................................................... 32
• Critères de choix et leur pondération .......................................................................... 32
• Matrice de décision ..................................................................................................... 33
V. Déploiement et analyse des résultats ..................................................................... 34
1) Validation de la solution ........................................................................................ 34
• Vérification du cadre d’applications et de la réussite de la solution retenue .............. 34
2) Perspectives........................................................................................................... 34
• Pistes d’amélioration de la/les solution(s) ................................................................... 34
VI. Conclusion ............................................................................................................. 35
VII. Bibliographie ......................................................................................................... 36
VIII. Glossaire ................................................................................................................ 37

4
Tables des illustrations
Figure 1 : rôle de chacun dans un écosystème OAuth 2.0 ..................................................... 12
Figure 2 : Client Credentials Grant ........................................................................................ 13
Figure 3 : Resource Owner Credentials Grant ....................................................................... 14
Figure 4 : Implicit Grant......................................................................................................... 15
Figure 5 : Authorization Code Grant...................................................................................... 16
Figure 6 : Décision flow Oauth .............................................................................................. 17
Figure 7 : Source de données Power BI ................................................................................. 18
Figure 8 : Authentification Power BI ..................................................................................... 19
Figure 9 : Architecture RH-SSO ............................................................................................ 20
Figure 10 : Power BI options ................................................................................................. 22
Figure 11 : Power BI custom connector ................................................................................. 23
Figure 12 : Power BI connector authentication ...................................................................... 24
Figure 13 : Power BI server authorization ............................................................................. 24
Figure 14 : API key account................................................................................................... 25
Figure 15 : API key documentation ....................................................................................... 26
Figure 16 : API key response ................................................................................................. 27
Figure 17 : API key ................................................................................................................ 27
Figure 18 : RH-SSO configuration......................................................................................... 28
Figure 19 : Tableu des degrés de pertinence .......................................................................... 31
Figure 20 : Légendes des critères ........................................................................................... 32
Figure 21 : Matrice de décision pondérée .............................................................................. 33

5
 I. Caractérisation de la problématique

1. Introduction
Ce rapport permet d'étudier la faisabilité d'interfacer PowerBI avec une API Rest disposant
d'une authentification forte, dans le contexte d'un projet de reporting SLA développé par
l'entreprise SLIB. Le rapport vise à proposer une solution pour la définition des crédentials
des comptes de service se connectant au service de reporting SLA et le stockage sécurisé de
ces informations au sein de PowerBI. Ce sujet est d'une grande importance car l'utilisation de
sources de données protégées par un mécanisme d'authentification forte est peu documentée
dans PowerBI, et une telle solution permettra d'optimiser le traitement des KPIs pour la
vérification du respect du SLA et la définition des pénalités éventuelles. Dans ce rapport, nous
présenterons donc les différentes étapes de la démarche scientifique que nous avons suivie
pour étudier cette problématique et proposer une solution adaptée.

2. Présentation de l’entreprise

SLIB est une entreprise basée à Lyon, en France, qui propose des solutions de traitement des
transactions financières pour les banques, les courtiers et les gestionnaires d'actifs. Depuis sa
création, l'entreprise a acquis une solide réputation pour son expertise et sa capacité à répondre
aux besoins de ses clients.

Les produits phares de SLIB incluent le traitement des opérations sur titres, le post-marché, la
gestion de collatéraux, la gestion de portefeuilles et la comptabilité. L'entreprise s'efforce
continuellement de développer de nouvelles fonctionnalités pour ses produits existants et de
créer de nouveaux produits pour répondre aux besoins en constante évolution de ses clients.

SLIB dispose également d'une équipe de support technique disponible 24 heures sur 24 et 7
jours sur 7 pour aider les clients à résoudre les problèmes techniques et répondre à leurs
questions. Cette équipe est très appréciée pour son professionnalisme et son engagement à
fournir un excellent service client.

SLIB édite également le logiciel VOTACCESS, développé sous l'égide de l'AFTI

(Association Française des Professionnels des Titres). Cette solution permet aux actionnaires
de voter en ligne de manière générale pré-assemblée. Ce projet a été certifié par l'innovation
de financement de grappe de compétitivité mondiale. Mis sur pied en 2012, il a été adopté par
EDF, Vivendi, GDF Suez, Suez Environnement, Danone et Pernod Ricard. En 2013, il s'est
développé et a servi à l'assemblée générale de plus de 20 entreprises dont Air liquide, Société
Générale, Total et L'Oréal.

6
 3. Présentation de l’ADS.
Pour étudier un phénomène, résoudre un problème ou répondre à un sujet de recherche, on
utilise une procédure rigoureuse appelée méthode scientifique. Elle comporte plusieurs étapes,
telles que l'élaboration d'une hypothèse, la conception d'une expérience ou d'une enquête, la
collecte de données, l'analyse des résultats et la formulation d'une conclusion.

La première étape de tout processus scientifique consiste à cerner un problème ou une question
de recherche. Sur la base de cela, on développe une hypothèse, c'est-à-dire une hypothèse ou
une prédiction qui peut être vérifiée. Puis, une expérimentation ou une enquête est prévue pour
tester l'hypothèse. Les facteurs sont identifiés et surveillés durant cette étape pour garantir des
résultats fiables.

Une fois les données recueillies, elles sont analysées à l'aide de techniques statistiques afin de
déterminer si l'hypothèse est vraie ou non. Si les résultats ne sont pas concluants ou ne
confirment pas l'hypothèse, la procédure scientifique peut être répétée avec des ajustements
pour améliorer l'expérience ou l'enquête.

La recherche est présentée sous la forme d'un rapport ou d'un article scientifique lorsque les
conclusions sont tirées des résultats. Cela permet à d'autres scientifiques d'examiner la
recherche et de la reproduire pour en vérifier les résultats.

4. Cadrage de la problématique
• A quel(s) problème(s) se rapportent mes missions en entreprises ?

Je suis actuellement en train de travailler sur un projet au sein de mon entreprise, dont l'objectif
est de mettre en place un système informatique de gestion de service pour nos clients. Ce
système permettra de garantir la qualité du service délivré et d'assurer une performance
optimale, tout en s'inscrivant dans une démarche d'amélioration continue.

Pour cela, nous avons mis en place une convention de service (CS) avec notre partenaire, qui
définit conjointement les niveaux de service précis et mesurables que nous nous engageons à
fournir. Cette convention de service repose sur trois grandes familles d'indicateurs de SLA :
les indicateurs de performance technique/exploitation, les indicateurs de réactivité support
client en cas d'incident, et le taux de disponibilité du système.

Nous avons également mis en place des modalités de mise en œuvre des indicateurs et des
mesures, qui seront calculés mensuellement sur l'ensemble des activités du mois. Les
indicateurs seront suivis et pourront être adaptés en fonction de la période de rodage de 6 mois
suite à la mise en production.

Cependant, étant donné que la sécurité de notre système est un enjeu majeur pour nous, nous
avons intégré dans notre démarche de sécurité informatique un sujet de recherche portant sur
7
la sécurisation de notre projet. En effet, nous souhaitons nous assurer que toutes les mesures
de sécurité nécessaires sont mises en place pour protéger les données de nos clients, ainsi que
notre système informatique en lui-même.

Ainsi, en tant que responsable de ce projet, j'ai pour mission de veiller à ce que toutes les
mesures de sécurité nécessaire soient mises en place et intégrées dans notre système
informatique. Pour cela, je m'appuie sur les connaissances acquises grâce à mon sujet de
recherche, qui me permettent d'avoir une vision claire des risques potentiels et des mesures à
prendre pour les prévenir.

En conclusion, mon sujet de recherche et mon projet en entreprise sont intimement liés,
puisque mon sujet de recherche m'a permis d'acquérir les compétences nécessaires pour
assurer la sécurité de notre système informatique. Ce projet est donc pour moi une excellente
opportunité de mettre en pratique les connaissances que j'ai acquises grâce à mon sujet de
recherche, et de contribuer à la mise en place d'un système informatique performant et sécurisé
pour nos clients.

5. Analyse de l’existant
• Prouver l’existence du problème

La sécurité des API est une préoccupation majeure pour les entreprises, en particulier pour
celles qui gèrent des données sensibles telles que les banques. Il est essentiel de s'assurer que
seules les personnes autorisées ont accès aux données et aux fonctionnalités exposées par
l'API. Sans une sécurité adéquate, les informations confidentielles peuvent être exposées, ce
qui peut entraîner des pertes financières importantes pour l'entreprise ainsi qu'une perte de
confiance des clients.

En conclusion, la sécurité des API est d'une importance capitale pour toute entreprise qui gère
des données sensibles. Il est crucial de mettre en place des mécanismes de sécurité appropriés
tels que l'authentification et l'autorisation afin de garantir que seules les personnes autorisées
ont accès aux données et aux fonctionnalités exposées par l'API. La gestion des rôles et des
permissions est également essentielle pour garantir que chaque utilisateur a uniquement accès
aux informations dont il a besoin pour effectuer son travail.

8
II. Identification de la solution optimale

1) Etat de l’art
• Aspects théoriques rattachés à ma problématique

- API [1]

Dans le domaine informatique, une API (Interface de Programmation d'Application) est un

ensemble standardisé de classes, de fonctions, de méthodes et de constantes, qui permet à un
logiciel de fournir des services à d'autres logiciels. Cette interface est souvent proposée par
une bibliothèque logicielle ou un service web, et est accompagnée d'une description détaillée
qui précise comment les programmes "consommateurs" peuvent utiliser les fonctionnalités
offertes par le programme "fournisseur". En somme, l'API est une façade qui permet de
simplifier l'interaction entre différents programmes informatiques.

Dans notre étude a nous, mais aussi dans le cadre de la recherche, nous allons nous focaliser
sur les API REST, car le sujet de recherche a été inspiré de cette dernière. Pour bien
comprendre il est nécessaire de connaitre les caractéristiques d’une API REST.

Une API REST (Representational State Transfer Application Program Interface) est un style
architectural qui permettant aux logiciels de communiquer entre eux, que ce soit sur un réseau
ou sur un même appareil. Les développeurs utilisent souvent les API REST pour créer des
services web, également appelés services web RESTful. Pour récupérer et publier des données
entre un périphérique client et un serveur, REST utilise des méthodes HTTP.

En utilisant le protocole HTTP, les API REST permettent à des logiciels de différents appareils
ou de même appareil, mais avec des systèmes d'exploitation et des architectures différentes,
de communiquer entre eux. Le client peut demander des ressources avec un langage que le
serveur comprend, et le serveur renvoie la ressource avec un langage que le client accepte. Le
format de réponse peut être du JSON (JavaScript Object Notation), XML (Extensible Markup
Language) ou du texte, mais de nombreuses API prennent également en charge d'autres
formats.

REST est un ensemble de principes directeurs auxquels un développeur doit adhérer avant de
pouvoir considérer son API comme « RESTful ». Et parmi ces principes on citera

Architecture client-serveur : Les clients de l’API utilisent des appels HTTP pour demander
une ressource (une méthode GET) ou envoyer des données au serveur (une méthode POST),
ou l’une des autres méthodes HTTP prises en charge par l’API. GET et POST sont les
méthodes les plus fréquemment utilisées, mais d’autres méthodes comme HEAD, PUT,
PATCH, DELETE, CONNECT, OPTIONS ET TRACE peuvent également être prises en
charge. La documentation de l’API montre les méthodes disponibles prises en charge par
l’API.

Sans état : Une application sans état ne maintient pas de connexion ni ne stocke
d’informations entre deux requêtes du même client. Un client fait une requête, l’API exécute
9
l’action définie dans la requête et répond. Une fois que l’API a répondu, elle se déconnecte et
ne conserve aucune information sur le client dans sa mémoire active. L’API traite chaque
requête comme une première demande.

Avec mise en cache : Un REST API doit normalement permettre la mise en cache des données
fréquemment demandées. Pour réduire la bande passante, la latence et la charge du serveur,
une API doit pouvoir identifier les ressources pouvant être mises en cache, déterminer qui
peut les mettre en cache et décider pendant combien de temps elles peuvent rester dans le
cache.

Interface uniforme : Le client interagit avec le serveur selon une manière définie,
indépendamment de l’appareil ou de l’application.

Identification des ressources : L’API doit avoir un URI (identifiant de ressource uniforme)
spécifique pour chaque ressource, tel que /kpi/{kpiGuid}

Auto-descriptif : Comprend des métadonnées telles que Content-Type qui décrit comment
interpréter la réponse.

On peut constater la facilité de conception et la flexibilité qu’apporte les API REST, cette
nouvelle approche n’a pas tarder à devenir populaire auprès des plus grandes entreprises.

Il faut noter que les API transportent des données, et à ce stade il est impossible de passer à
côté d’un concept primordial. La Sécurité des API dans cette partie on vas évoquer les raisons
pour lesquelles on doit se protéger, et des mécanismes de sécurisation étroitement lié à notre
cas sans s’attarder sur les autres mécanismes.

Le but principal et ce qui nous a pousser à réfléchir et à se poser des questions sur l’existence
d’une problématique est L'authentification et l’autorisation. Ils sont couramment utilisés
ensemble, l’authentification est utilisée pour déterminer de manière fiable l’identité d’un
utilisateur final, l’autorisation est utilisée pour déterminer les ressources auxquelles
l’utilisateur identifié a accès.
Sur le Web, l’authentification est le plus souvent implémentée via un formulaire qui demande
le nom d’utilisateur et le mot de passe. Des clés matérielles et des périphériques externes
peuvent être utilisés pour compléter la sécurité des certificats de logiciels. Une fois que
l’utilisateur est authentifié, le système décide quelles ressources ou données peuvent être
accédées.
Pour les API, il est fréquent d’utiliser un type de jeton d’accès, soit obtenu par un processus
externe (par exemple lors de la signature de l’API) ou par un mécanisme distinct (par exemple,
OAuth). Le jeton est transmis avec chaque demande à une API et est validé par l’API avant
de traiter la demande et de renvoyer la ressource demandée.

10
 ✓ Comment sécuriser une API [1] [4]

Dans le cas présent il est question d’autorisation, mais avant on vas expliquer ce qu’il existe
comme mécanisme pour sécuriser une API.

OAuth 2.0 et OpenID Connect sont deux protocoles en charge de la sécurité cependant ils ont
étroitement lié, car les applications sont amenées à authentifier et à autoriser à la fois.

OAuth 2.0 vas permettre principalement à des applications tierces de se connecter à un compte
utilisateur sans avoir besoin de ses identifiants, comme une application qui souhaite accéder
à vos photos sur Facebook alors cette dernière utilisera OAuth 2.0, car on parle juste
d’autorisation d’accès à une ressource.

OpenID Connect, quant à lui, est une extension d'OAuth 2.0 qui ajoute une couche
d'authentification à OAuth 2.0. Il permet à un utilisateur de s'authentifier auprès d'un
fournisseur d'identité (IdP) tel que Google, Facebook, Microsoft, etc., et de récupérer un jeton
d'identification qui peut être utilisé pour prouver son identité auprès d'autres applications.

A ce stade nous savons que nous allons avoir besoin que de la partie autorisation, de ce fait
notre étude théorique portera sur le mécanisme OAuth 2.0.

Champs lexical OAuth 2.0 :

• Client : l’application écrite par le développeur, qui consomme les ressources de l’API
• Resource Server (Serveur de ressources) : c’est celui qui expose via une API REST
les ressources auxquelles le Client veut accéder

• Resource Owner (Propriétaire de la ressource) : l’utilisateur final, qui utilise le

Client
• Authorization Server (Serveur d’autorisation) : un nouvel acteur, dont le rôle est de
fournir des jetons (tokens) aux clients
• Scope (Périmètre) : une description de ce que l’utilisateur permet à l’application de
faire en son nom
• Consumer (Consommateur) : le développeur de l’application. Il n’est pas présent
explicitement dans la spécification mais est présent dans beaucoup d’implémentations
• Token (Jeton) : une information opaque qui relie un client, un ou plusieurs scopes et
éventuellement un utilisateur.

11
Voici un schéma qui explique le rôle de chacun dans un écosystème OAuth 2.0 :

Figure 1 : rôle de chacun dans un écosystème OAuth 2.0

Les types de clients existant dans OAuth2.0 :

1- Clients confidentiels
Un client qui a été développés et déployé et exploité par la même organisation que celle qui
gère les ressources ainsi que le serveur d’autorisation.

2- Clients externes
Ce sont des clients d’anciennes spécifications de OAuth0 et OAuth1,

3- Clients publics
Ce sont les clients auxquelles on fera le moins confiance, car ils ne sont pas capables de
garantir la sécurité de leurs identifiants (client_id et client_secret).

12
A présent nous allons voir plus en détail comment fonctionne OAuth 2.0 pour obtenir ce
fameux Token. OAuth 2.0 propose 4 scenarios pour l’obtention du Token.

a- Client Credentials Grant

Le scénario le plus simple en matière d'authentification consiste à fournir un Token à un client

pour qu'il puisse s'identifier auprès d'un serveur de ressources. Contrairement aux autres
scénarios, celui-ci ne permet pas aux clients de réaliser des actions au nom d'un utilisateur. Il
est surtout utilisé pour des traitements serveur à serveur ou pour des actions d'administration.

Ce scénario permet également aux applications de mettre à jour leurs propres informations.
Toutefois, le client doit être authentifié et doit savoir conserver ses identifiants en sécurité.
Par conséquent, il est recommandé de n'utiliser ce scénario que pour des clients confidentiels
ou externes.

Figure 2 : Client Credentials Grant

13
 b- Resource Owner Credentials Grant

Ce scénario implique que le Client reçoive un Token directement depuis le serveur

d'autorisation sur un Endpoint /Token. Pour ce faire, il est de la responsabilité du client de
récupérer les identifiants de l'utilisateur afin d'identifier le Resource Owner. Cependant, ces
informations sont considérées comme des données sensibles, ce qui signifie que ce type de
scénario n'est acceptable que dans le cas d'un client confidentiel. En effet, le client doit être
en mesure de garantir la sécurité et la confidentialité des données de l'utilisateur.

Il est important de souligner que le serveur d’autorisation doit toujours contrôler les
identifiants du client, en plus de ceux de l’utilisateur.

Figure 3 : Resource Owner Credentials Grant

14
 c- Implicit Grant

Ce mécanisme s'adresse à des clients publics. Dans le scénario implicite, le code d'autorisation
intermédiaire n'est pas envoyé au client. D'autre part, le Token d'accès est envoyé directement
via une URL reconnue par le serveur d'autorisation. Cette URL ne peut être accédée que par
HTTPS et contient un programme Javascript qui peut lire le Token à partir du fragment de
l'URL. Au moment de la récupération, ce jeton peut être utilisé par l'application JavaScript
correspondante.

Figure 4 : Implicit Grant

15
 d- Authorization Code Grant

C’est un scenario inspirer de OAuth1 vulgarisé, son rôle est d’assurer la communication entre
des serveur, prenons exemple sur un service web (lorsqu’un utilisateur utilise un navigateur
web), adapté aux clients confidentiels et externes, bien sûr dans le cas ou le client est un
serveur.

Figure 5 : Authorization Code Grant

16
Comme on a bien pu le voir les scénarios vont nous aider à prendre une décision sur lequel
nous correspond le mieux, selon le type de client, pour synthétiser tout ça je vous propose un
schéma qui résume le choix à faire face un client.

Figure 6 : Décision flow Oauth

17
 - Power BI [2]

Power Bi est un outil développé par Microsoft, il permet de générer des rendus visuels depuis
des sources de données différentes et variées, les rendus peuvent se traduire en tableaux de
bords ou bien rapport personnalisable à souhait, il facilite la prise de décision.

Il est au sommet du podium depuis des années, aux yeux des plus grandes entreprises mondiale

Nous allons alimenter Power BI avec des données issue de notre API, c’est pour cela qu’il fait
partie de notre étude. Il nous met à disposition plusieurs types de source de données.

Figure 7 : Source de données Power BI

18
Après avoir sélectionné le service web il vas nous demander de renseigner l’url qu’on souhaite
interroger pour récupérer des données, après avoir fourni l’url si ce dernier est sécurisé Power
Bi affichera une fenêtre spécifique avec plusieurs options d’authentification.

Figure 8 : Authentification Power BI

L’utilisateur pourras naviguer dans les choix d’authentification qui sont exposé dans la partie
gauche de la fenêtre.

Après authentification Power BI affichera les données renvoyées par l’API interrogée.

- RH-SSO [3]

RHSSO est l'abréviation de "Red Hat Single Sign-On" et est un produit open source de gestion
des identités et des accès proposé par Red Hat. Il offre une solution de connexion unique pour
les utilisateurs qui ont besoin d'accéder à plusieurs applications en utilisant un seul ensemble
d’identifiants. Il s'agit d'un système d'authentification et d'autorisation à la fois de sécurité
avancée qui permet de protéger les applications en utilisant des mécanismes de sécurité
accrues.

RH-SSO utilise le protocole OpenID Connect pour fournir une couche d'authentification et
d'autorisation sécurisée pour les applications web et mobiles. Il prend également en charge
d'autres protocoles standards tels que OAuth2. C’est pour cela que nous l’avons mis en avant
dans les aspects théoriques à maitriser, il est le plus adapter à notre problématique.

En utilisant RH-SSO, SLIB simplifie la gestion des identités et des accès, par la même
occasion réalise des économies, tout en améliorant la sécurité et en réduisant les risques.

19
Architecture RH-SSO [3]:

Figure 9 : Architecture RH-SSO

20
 • Recherche de la problématique dans d’autres entreprises/Domaines

Dans cette partie nous allons partir à la recherche de problématique similaire, soit au sein de
l’entreprise ou bien dans d’autres entreprises, ou sinon des personnes qui ont déjà fait face à
cette problématique. Le but de cela est de sortir du cadre connu et d’explorer d’autres pistes
dans l’espoir de s’en inspirer, si à l’issue de cette recherche on trouve une solution qui semble
correcte ou bien logique, ou la démarche se conjugue parfaitement avec notre situation, alors
là on pourra adapter la solution en question pour que cela puisse répondre à notre
problématique.

Connecteur personnalisé [2]:

Un certain Jussi Roine s’est penché sur la question. Il a souhaité visualiser des données du
Cloud d’Oura, en passant par leurs API, mais leurs API est sécurisé et nécessite une
autorisation.

Il n’est pas difficile de répondre à cette problématique, il faudra construire un mécanisme

classique pour pouvoir interroger une API nécessitant une autorisation. Sauf que Jussi
souhaite interroger l’API depuis Power Bi, donc il faut Power Bi puisse contacter un serveur
d’autorisation pour qu’il puisse lui procurer une autorisation (Token).

Pour pouvoir arriver à ses fins Jussi passera par un Connecteur personnalisé, il va nous
permettre de créer de nouvelles sources de données adapter à notre besoin, dans notre cas le
besoin se traduit par un aspect de sécurisation. Pour pouvoir mettre en place un connecteur il
faut passer par un kit de développement logiciel (SDK) de chez Microsoft, pour
l’implémentation de flux d’authentification OAuth 2.0.

21
Après implémentation de leurs solutions, nous allons décrire les différentes étapes.

Figure 10 : Power BI options

22
Il est important de noter qu’il faut activer l’option Custom data connectors pour pouvoir
utiliser les connecteurs qu’on a développés.

Figure 11 : Power BI custom connector

Après activation de cette option, on peut voir leurs connecteurs qui apparaissent dans la liste
des connecteurs proposé par Power Bi, en sélectionnant le connecteur personnalisé et en
renseignant l’URL sécurisé le connecteur demandera alors de s’authentifier auprès du serveur
d’autorisation qui appartient à l’organisation détenant la ressource demandée

23
 Figure 12 : Power BI connector authentication

Donc, en appuyant sur s’identifier Power Bi va rediriger l’utilisateur vers la page de Login du
serveur d’autorisation.

Figure 13 : Power BI server authorization

Et à partir de là l’utilisateur s’authentifie avec ses identifiants et le serveur d’autorisation

renvoi un jeton (Token) qui sera utilisé pour appeler l’API sécurisé

24
Solution adoptée par JCDecaux [1]

JCDecaux est une multinational qui propose des systèmes de location de vélos en libre-
service, JCDecaux expose une API qui renvoi les données en temps réel des stations de vélos
en libre-service, pour utiliser cette API il faut avoir un compte développeur chez JCDecaux,
c’est totalement gratuit est accessible à tout le monde.

L’API en question est sécurisée, par une APIKEY en d’autres termes clé d’api. Cette APIKEY
est générer sur le compte du développeur en utilisant ses informations, et lorsque le
développeur souhaitera interroger l’API il aura juste à envoyer avec son APIKEY disponible
sur son compte.

Une documentation sur le site est disponible pour utiliser leurs API. Je me suis créé un compte
moi-même pour tester leurs solutions.

En créant le compte on se retrouve directement sur cet écran

Figure 14 : API key account

25
On peut voir qu’ils ont déjà généré pour nous la clé d’API qui est valide et prête à être utilisé.

Figure 15 : API key documentation

26
On se rendant sur la documentation, il est possible de prendre en main l’API.

Figure 16 : API key response

Voici la réponse obtenue lorsque j’interroge l’API en lui donnant mon APIKEY qui est sur
mon compte.

Figure 17 : API key

Cette solution garantie que seule la personne détenant la clé a le droit d’accéder à la ressource.

27
III. Recherche de solution
• Solutions envisageables & pertinence

Les deux exemples présentés précédemment nous ont aidés à voir mieux et à comprendre dans
quel sens on doit se diriger pour répondre au mieux à notre problématique.

Certaines questions ont trouvé réponse après analyse en profondeur des deux solutions
étudiées, cela va nous servira principalement à prendre une décision et à faire le choix entre
les solutions qu’on proposera par la suite, car nos solutions vont forcément s’inspirer des
données recueillies.

Solution 1 (configuration OpenID Connect dans l’API) [4] :

Cette solution consiste à configurer OpenID Connect directement dans notre API, dans ce cas
l’API se chargera de contacter le serveur d’authentification et de récupérer le jeton et de le
vérifier.

Figure 18 : RH-SSO configuration

La figure ci-dessus représente la configuration avec les paramètres de notre serveur

d’authentification RH-SSO [3].

Lorsque l’utilisateur souhaite accéder à une partie de l’application qui nécessite une
authentification, notre application Quarkus demande un jeton d'accès au serveur
d'authentification en utilisant les paramètres de configuration définies. Si l'authentification
réussit, le serveur d'authentification renvoie un jeton d'accès JWT qui contient des
informations sur l'utilisateur authentifié et les autorisations associées. Notre application peut
alors utiliser ce jeton pour autoriser l'accès à des ressources protégées.

Configuration utilise le type de subvention "password", ce qui signifie que l'authentification

est basée sur un nom d'utilisateur et un mot de passe. Cela peut être moins sûr que d'autres
types de subventions, car les informations d'identification sont envoyées directement au
serveur d'authentification. Il est recommandé d'utiliser d’autres types de subvention plus
sécurisés.

28
Avantages :

• Facile à mettre en place : l'authentification basée sur un nom d'utilisateur et un mot de

passe est relativement simple à implémenter dans une application.
• Familiarité des utilisateurs : cette méthode est très courante et familière pour les
utilisateurs, qui sont habitués à s'authentifier avec un nom d'utilisateur et un mot de
passe.
• Pas besoin d'interagir avec l'utilisateur : cette méthode permet une authentification
automatique sans interaction de l'utilisateur. Cela peut être utile pour les applications
qui nécessitent une authentification transparente.

Inconvénients :
• Faible sécurité : les informations d'identification sont envoyées directement au serveur
d'authentification, ce qui les expose aux risques de piratage, tels que l'interception de
paquets. Les noms d'utilisateur et les mots de passe peuvent également être facilement
devinés ou compromis, ce qui rend cette méthode moins sûre que d'autres méthodes
d'authentification.
• Pas de protection contre les attaques de phishing : cette méthode ne fournit aucune
protection contre les attaques de phishing, dans lesquelles un attaquant tente de
tromper l'utilisateur en révélant ses informations d'identification.
• Difficulté de gérer les mots de passe : la gestion des mots de passe peut être difficile
pour les utilisateurs, qui doivent se rappeler de nombreux mots de passe pour différents
services. Les administrateurs systèmes doivent également mettre en place des
politiques de mot de passe solides et les faire respecter pour éviter les compromissions.

Solution 2 (api Key) [1] :

On propose cette solution car elle répond en partie à la problématique de manière efficace,
elle permettra aux personnes ayant une clé d’accéder à la ressource protégée.

L’utilisateur qui souhaitera accéder à la ressource devra se munir de sa clé d’API, pour pouvoir
l’envoyer dans l’URL. Cependant cette clé devra être généré soit par le serveur
d’authentification ou bien par un programme tiers. Le backend de notre API se chargera de
vérifier la validité ou non de la clé.

Avantages :
• Facilité d'implémentation
• Possibilité de contrôler l'accès à une API à l'aide d'une clé unique
• Possibilité de révoquer une clé en cas de compromission
• Possibilité d'attribuer différentes autorisations à différentes clés
Inconvénients :
• Les clés peuvent être compromises ou volées
• Les clés peuvent être facilement partagées entre les utilisateurs
29
 • Les clés ne fournissent pas d'informations sur l'identité de l'utilisateur
• Les clés peuvent être difficiles à gérer à grande échelle

Solution 3 (mettre en place un connecteur personnaliser Power BI) [2] :

La mise en place d’un connecteur personnalisé, le but est d’isoler notre API de
l’authentification.

Avec le kit de développement fourni par Microsoft on développera le connecteur avec une
configuration qui sera capable d’entrer en communication avec le serveur d’authentification,
et ensuite d’exposer les ressources protégées.

Nous allons essayer de décrire le déroulement en utilisant la solution du connecteur

personnalisé

1. L'utilisateur renseigne l'URL de la ressource protégée : L'utilisateur demande l'accès

à une ressource protégée en fournissant son URL.
2. Une fenêtre s'affiche demandant à l'utilisateur de s'authentifier : Power BI affiche une
fenêtre d'authentification demandant à l'utilisateur de fournir ses informations
d'identification (nom d'utilisateur et mot de passe).
3. Power BI redirige l'utilisateur vers la page Login de RH-SSO : Une fois que
l'utilisateur a fourni ses informations d'identification, Power BI redirige l'utilisateur
vers la page de connexion de RH-SSO.
4. Après authentification RH-SSO renvoie un JWT : RH-SSO authentifie l'utilisateur et
génère un jeton JWT contenant des informations sur l'utilisateur et ses autorisations.
RH-SSO renvoie ce jeton à Power BI.
5. Le connecteur utilise ce JWT pour interroger la ressource protégée : Power BI transmet
le jeton JWT au connecteur personnalisé. Le connecteur utilise le jeton JWT pour
interroger la ressource protégée et récupérer les données nécessaires pour alimenter le
rapport Power BI.

Il est important de souligner que ce connecteur intégrera le mécanisme OAuth2.0.

Avantages :

• Flexibilité : des connecteurs personnalisés peuvent êtres conçu pour s'adapter à des
sources de données spécifiques.
• Contrôle : en créant notre propre connecteur personnalisé, on a le contrôle total sur la
façon dont les données sont extraites et intégrées à Power BI.
• Performance améliorée : un connecteur personnalisé peut être optimisé pour améliorer
les performances lors de l'extraction de données volumineuses ou complexes.
30
Inconvénients :

• Temps et coûts de développement : la création d'un connecteur personnalisé peut

prendre du temps et des ressources, en particulier si vous n'avez pas d'expérience en
développement de connecteurs.
• Maintenance et support : une fois le connecteur personnalisé créé, vous devez le
maintenir et fournir un support en cas de problèmes.
• Sécurité : la sécurité est une préoccupation importante lors de la création d'un
connecteur personnalisé, car vous devez vous assurer que les données sont extraites et
stockées de manière sécurisée.

Analyse des degrés de pertinence [5]

Numéro La solution Temps Couts Pertinence

1 Configuration OpenID Connect dans

l’API 2 1 2

2 Api Key
1 1 1

Un connecteur personnaliser Power

3 BI 3 2 3

Figure 19 : Tableu des degrés de pertinence

Le tableau apporte une conclusion prématurée, car on ne peut pas se fier à ce tableau pour une
prise de décision, c’est possible de suivre les résultats du tableau, mais cela sera sans prendre
en compte l’objectif principale de la recherche. Donc on ne va pas tirer de conclusion a ce
niveau de l’étude.

Informations concernant le tableau

Le tableau présenté ci-dessus permet de visualiser les différentes solutions proposées, mais
aussi de les classer selon un ordre bien défini. Pour faire cela, nous avons déterminé trois
critères avec 4 niveaux du plus faible au considérable, on pourra à présent évaluer chaque
solution selon les critères et déterminer le plus pertinent selon le niveau de chaque critère

31
 Critères Degré

Faible 1

Modéré 2

Élevé 3

Considérable 4

Figure 20 : Légendes des critères

IV. Choix des solution idéales

• Critères de choix et leur pondération

A ce niveau un choix de solution s’impose. L’étude a permis d’analyser sous tous les angles
que ce soient les solutions adoptées par d’autres entreprises ou bien d’autres organisations.

Le choix ne doit pas s’écarter de la problématique dans un premier temps. Si on souhaite faire
le choix le plus optimal alors dans ce cas-là il faut se référer au but et a l’objectif de cette
recherche.
En soi la problématique est un constat mais l’objectif est un besoin qu’il faut satisfaire.

La priorité de SLIB est la sécurité, ça sera le critère en tête de liste et celui sur lequel on se
basera pour prendre une décision

Pour finaliser notre choix nous allons réaliser une matrice de décision pondérée. Pour une
prise de décision précise c’est la méthode la plus utilisée, maintenant il reste plus qu’à
déterminer les critères les plus importants en ajoutant leurs pondérations.

Pondération et critères :

Les critères à prendre en considération pour que cette étude soit en corrélation avec les
objectifs visés sont :

- Sécurité avec une pondération de : 5

- La durée de développement avec une pondération de : 3
- Le Coût avec une pondération de : 2
- Le déploiement avec une pondération de : 3

32
 • Matrice de décision

Sécurité Déploiement Durée de Le Coût Score

5 3 développement 2
3

Configuration
OpenID Connect 2x5 2x3 2x3 1x2 24
dans l’API

Api Key
1x5 2x3 1x3 1x1 15

Un connecteur
personnaliser Power 4x5 3x3 3x3 2x2 42
BI

Figure 21 : Matrice de décision pondérée

A présent nous sommes capables d’identifier la solution la plus optimale, et celle qui couvrira
l’ensemble de la problématique. Le connecteur personnalisé de Power Bi semble être la
solution à garder.

33
V. Déploiement et analyse des résultats

1) Validation de la solution
• Vérification du cadre d’applications et de la réussite de la solution retenue

Pour SLIB, il est essentiel que la solution que nous avons choisie soit soigneusement examinée
et validée avant d'être déployée. Cela implique une évaluation approfondie de plusieurs
aspects tels que la performance, la sécurité, la compatibilité avec nos autres systèmes, la
facilité d'utilisation et la pertinence pour nos objectifs. Nous comprenons que ce processus de
validation et de déploiement peut prendre du temps et nécessiter l'implication de plusieurs
personnes au sein de notre entreprise. Cependant, nous sommes convaincus que cette approche
est primordiale pour minimiser les risques d'interruptions et de problèmes potentiels pour nos
utilisateurs.

2) Perspectives
• Pistes d’amélioration de la/les solution(s)

Bien que l'utilisation d'OAuth2 soit une option appropriée pour la gestion des permissions,
l'intégration d'OpenID Connect peut présenter un certain nombre d'avantages pour la gestion
des identités. L'intégration d'OpenID Connect permet d'accéder à un système de gestion des
identités plus fiables, qui peut gérer les rôles et les privilèges. Nous pouvons également utiliser
des protocoles d'authentification plus robustes pour garantir que seules les personnes
autorisées ont accès à nos ressources protégées. En outre, OpenID Connect est conçu pour être
facilement extensible, ce qui nous permet d'ajouter de nouvelles fonctionnalités au fur et à
mesure de l'évolution de nos besoins.

34
VI. Conclusion

En conclusion, ce rapport a abordé le défi de l'interface de Power BI avec une API Rest
disposant d'une authentification forte, dans le contexte d'un projet de reporting SLA développé
par SLIB.

À travers notre analyse de la situation existante et de la recherche d'état de l'art, nous avons
identifié plusieurs solutions potentielles et des critères de sélection pour choisir la solution
optimale. En fin de compte, nous avons choisi la meilleure solution.

Ce rapport a démontré l'importance de relever les défis liés à l'interface avec les API disposant
d'une authentification forte, car cela peut avoir un impact significatif sur les performances des
projets de reporting. J’espère que ce rapport servira de référence utile pour SLIB et d'autres
organisations confrontées à des défis similaires.

35
VII. Bibliographie
https://www.uptrends.fr/qu-est-ce-que/rest-api [1]
https://www.redhat.com/fr/topics/api/what-is-a-rest-api [1]
https://blog.hubspot.fr/website/api-rest [1]
https://www.astera.com/fr/type/blog/rest-api-definition/ [1]
https://pure.unamur.be/ws/portalfiles/portal/37082986/2017_SoumailaR_memoire.pdf [1]
http://abcdrfc.online.fr/rfc-vf/pdf/rfc4401.pdf [1]
https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir/ [1]

https://jussiroine.com/2019/02/building-a-custom-connector-for-power-bi-that-supports-
oauth2-to-visualize-my-wellness-data/
https://docs.progress.com/de-DE/bundle/datadirect-hybrid-data-pipeline-
46/page/Configuring-a-Power-BI-custom-connector-for-OAuth-2.0.html
https://learn.microsoft.com/en-us/power-query/install-sdk
https://radacad.com/power-bi-custom-connector-connect-to-any-data-sources-hello-world
https://community.powerbi.com/t5/Desktop/To-Enable-custom-connector-in-Power-bi-
desktop/m-p/916374
https://www.google.com/search?q=power+bi+custom+connector&rlz=1C1GCEU_frFR1023
FR1023&oq=power+bi+custom+connector+&aqs=chrome..69i57j35i39j0i512j0i22i30l2j69i
61j69i60l2.7014j0j4&sourceid=chrome&ie=UTF-
8#fpstate=ive&vld=cid:ab72796f,vid:eul2fBbtmEs

https://www.ibm.com/docs/en/cloud-paks/cp-applications/4.2?topic=providers-red-hat-
single-sign-rhsso
https://github.com/redhat-developer/redhat-sso-quickstarts
https://www.miniorange.com/power-bi-single-sign-on-(sso)

https://quarkus.io/guides/security-openid-connect
https://quarkus.io/guides/security-keycloak-authorization
https://www.ilex-international.com/fr/federation-identite/oauth2-vs-openid-connect
https://oa.dnc.global/-fr-.html?page=unarticle&id_article=5

https://asana.com/fr/resources/decision-matrix-examples

36
VIII. Glossaire

SLA: Service level agreement

HTTP: Hyper Text Transfer Protocol

HTTPS : Hyper Text Transfer Protocol Secure

IdP : Identity Proider

JSON : Javascript Objet Notation

REST : Representational State Transfer

XML : Extensible Markup Language

37