Vous êtes sur la page 1sur 20

Chap 3:Etude sur les bonnes pratiques

Introduction
L'intégration des applications devient de plus en plus cruciale car peu importe à quel
point vous souhaitez effectuer tout votre travail à l'aide d'une seule application, c'est
presque impossible.Il existe plusieurs applications, répondant à des besoins et à des
rôles spécifiques au sein des entreprises.
Ce chapitre va nous permettre d'aborder les différentes solutions d'intégration
d'applications,la fédération d'identité et l'authentification unique.
3.1 Technique d'intégration
3.1.1 Les Middlewares
Un middleware est une interface permettant la mise en relation de plusieurs
applications hétérogènes. Il agit comme une passerelle afin de faciliter l’échange de
données entre deux systèmes distincts.
Il existe trois principaux types de middleware :

3.1.1.1 MOM
Dans un MOM (Message Oriented Middleware), les applications informatiques
communiquent par échange de messages d'une manière similaire au courrier
électronique : une application informatique émet un message qui est alors transmis à
l'application destinataire par le middleware pendant que l'application émettrice
effectue d'autres traitements (asynchronisme).
Le contenu du message est formaté par l'émetteur selon une convention pré-établie
puis analysé automatiquement par l'application destinataire conformément à cette
convention. Le format de données XML est souvent utilisé pour les messages.

3.1.1.2 ORB
Le middleware ORB(Object Request Broker) le principe d’appel de fonctions
distantes pour acheminer le service sollicité par le client vers le serveur. La fonction
distante est alors exécutée, et le résultat du service livré au client. C'est un mode de
fonctionnement synchrone, serveur et client agissant dans la même unité de temps.

3.1.1.3 MOT
Un MOT(Transaction Oriented Middleware) est un environnement réparti qui prend
en charge l'execution d'une application et la verification de son bon fonctionnement
en intégrant des mécanismes transactionnels. En plus des aspects purement
transactionnels, ils offrent un outil de gestion optimisé et partagé des ressources, un
outil de communication et un outil d'administration et de supervision.
Les MOT permettent au programmeur de ne pas s'occuper des problèmes de
simultanéités d'accès, de défaillance du système, de ruptures de connexions. Ils
fournissent le moteur pour faire tourner les applications au dessus des OS et du
matériel. Ils assurent une cohérence transactionnelles et facilite le découpage des
applications en services.
MOMs et ORBs restent des solutions très techniques ; ils permettent certes à la fois la
propagation des données et l'intégration des traitements, mais la sémantique des
échanges y reste fondamentalement point-à-point : le client doit connaître le format
du message qu'il adresse aux systèmes tiers ; ce couplage fonctionnel des systèmes
devient rapidement un cauchemar pour la maintenance et l'exploitation, en particulier
s'il est étendu à l'ensemble du SI ; enfin, la question de l'interopérabilité n'est pas
définitivement résolue, en particulier lorsque le système cible est très fermé.

3.1.2 Enterprise application integration EAI


Pour contourner les limites des middlewares les entreprises se tournent vers
l’Enterprise Application Integration (EAI). Cette plate-forme permet de réunir les
applications existantes d’une entreprise au sein d'un même espace, afin de les faire
communiquer entre elles.Un EAI permet en effet de se connecter à tous les types de
sources de données, de les extraire facilement, mais aussi de les structurer et de les
transférer d'un espace de stockage à un autre.
Les solutions EAI propose deux architectuires :
3.1.2.1 Architecture Point-to-Point
Le modèle point à point implique que chaque application a été personnalisée pour
pouvoir communiquer avec les autres applications et éléments de votre
environnement informatique. Chaque ressource doit donc être personnalisée en
fonction de toutes les ressources auxquelles elle se connecte. Il s'agit d'une tâche
fastidieuse et le modèle est par conséquent fortement sujet aux erreurs. Pour ne rien
simplifier, la maintenance du modèle se complexifie à chaque mise à jour de
l'infrastructure et des applications.
Figure 3.1:Architectute Pont-To-Point
3.1.2.2 Architecture Hub-and-Spoke
Le modèle en étoile résout ce problème avec un point de connexion central (le cœur)
qui relie toutes les applications et les services. Les rayons qui relient le cœur aux
applications et aux services peuvent faire l'objet d'une maintenance individuelle.
Ainsi, vous pouvez concevoir des applications plus spécialisées et réserver les tâches
d'intégration au cœur et aux rayons. Le principal désavantage de cette approche réside
dans la centralisation du cœur, car il devient le point unique de défaillance du
système et des communications au sein de votre infrastructure. Dans un modèle en
étoile, toutes les intégrations dépendent, par définition, du bon fonctionnement du
cœur.

Figure 3.2:Architecture en étoile


3.1.3 Entreprise Service Bus ESB

3.1.3.1 Définition et Architecture


ESB signifie Entreprise Service Bus. C'est est une nouvelle génération d’intégration
d’application, considérée en quelques sortes comme l’héritière de l’EAI. Un ESB est
construit sur des standards ouverts tels que le protocole XML pour la description des
messages(requête et réponse) et les services web pour l’échange de données.
À la différence de l'EAI, l'ESB n’intervient pas directement dans les applications du
système mais via des modules de web services au sein de chacune d'entre elles.
L'ensemble de ces modules de service est ensuite dirigé et partagé vers un flux central
où l'échange est assuré : le Bus applicatif.
Les déploiements de nouveaux outils et composants dans le système d'information est
ainsi facilité grâce à cette méthode.
Il est couramment utilisé dans les principes d'intégration d'applications d'entreprise
(EAI) ou d'architecture orientée services (SOA).

Figure 3.3:Architecture ESB


3.1.3.2 Principe
L'ESB en tant que médiateur entre les clients et les fournisseurs de services s'appuie
sur les principes suivants :
1.Découplage

L'une des choses les plus importantes que vous puissiez faire via ESB est de
dissocier les clients des fournisseurs de services.
2.Conversion de protocole de transport

ESB vous donne la possibilité d'accepter un protocole d'entrée et de


communiquer avec un autre fournisseur de services sur un protocole différent.
3.Amélioration des messages

ESB vous permet d'isoler le client et d'apporter quelques modifications de base


au message.
Par exemple, modifier le format de date du message entrant ou ajouter des
données d'information aux messages.
4.Transformation des messages

ESB vous permet de transformer un message entrant en plusieurs formats et


structures sortants.
Par exemple, XML vers JSON, objets XML vers Java.
5.Routage

ESB a la capacité de rediriger une demande client vers un fournisseur de


services particulier en fonction de critères de routage déterministes ou
variables.
6.Sécurité

ESB protège les services contre les accès non autorisés.


7.Chorégraphie de processus et orchestration de services

ESB gère les flux de processus et les services commerciaux complexes pour
effectuer une opération commerciale.
La chorégraphie des processus concerne les services métier, tandis que
l'orchestration des services est la capacité de gérer la coordination de leurs
implémentations réelles. Il est également capable d'abstraire les services métier
des services réellement mis en œuvre.
8.Gestion des transactions
ESB offre la possibilité de fournir une seule unité de travail pour une demande
commerciale, fournissant un cadre pour la coordination de plusieurs systèmes
disparates.

3.1.4 SOA

3.1.4.1 Definition
Contrairement à l'EAI qui consiste à lier des applications d'entreprise pour qu'elles
puissent communiquer entre elles (au moyen d'un moteur de raisonnement intelligent)
et effectuer des transferts de données « par lots », l'architecture orientée services
(SOA) assure des transferts de données « transactionnels », avec aucun logiciel tiers
requis. La SOA est différente de l'approche EAI en ce sens qu'elle ne dépend pas
d'une solution tierce.
le SOA repose sur les web services qui utilisent des langages standardisés. XML
(Extensible Markup Language), langage incontournable et universel pour les
descriptions efficaces des données, SOAP Service Oriented Architecture Protocol
comme protocole d'échanges des messages au format XML dans une logique de RPC
(Remote Procedure Call) et WSDL (Web Services Description Language), pour ne
citer que les principaux.
Le fonctionnement est ici un peu différent : nous avons été habitués au « Request and
Reply » (envoi d'une requête et réception de la réponse) alors qu'ici le principe est
« Publish and Subscribe » (les informations sont publiées et si on veut les recevoir, on
s'y abonne).La publication est dynamique : si jamais il y a de l'information à
transmettre, elle est publiée et tout le monde peut souscrire à ce service à n'importe
quel moment.
3.1.4.2 Principe
SOA repose sur les principes suivants :
• Contrat de service standardisé
Les services adhèrent à un accord de communication standard, tel que défini
collectivement par un ou plusieurs documents de description de service au sein d'un
ensemble donné de services.
• Autonomie de référence de service (un aspect du couplage lâche)
La relation entre les services est minimisée au point qu'ils sont seulement conscients
de leur existence.
• Transparence de l'emplacement de service (un aspect du couplage
lâche)
Les services peuvent être appelés de n'importe où dans le réseau où ils se trouvent,
peu importe où ils sont présents.
• Longévité du service
Les services doivent être conçus pour durer longtemps. Dans la mesure du possible,
les services doivent éviter de forcer les consommateurs à changer s'ils n'ont pas
besoin de nouvelles fonctionnalités. Si vous appelez un service aujourd'hui, vous
devriez pouvoir appeler le même service demain.
• L'abstraction des services
Les services agissent comme des boîtes noires, c'est-à-dire que leur logique interne
est cachée aux consommateurs.
• Autonomie de service
Les services sont indépendants et contrôlent les fonctionnalités qu'ils encapsulent, du
point de vue de la conception et de l'exécution.
• Apatridie de service
Les services sont sans état, c'est-à-dire qu'ils renvoient la valeur demandée ou
donnent une exception, minimisant ainsi l'utilisation des ressources.
• Granularité du service
Un principe pour garantir que les services ont une taille et une portée adéquates. La
fonctionnalité fournie par le service à l'utilisateur doit être pertinente.
• Normalisation des services
Les services sont décomposés ou consolidés (normalisés) pour minimiser la
redondance. Dans certains, cela peut ne pas être fait. Ce sont les cas où l'optimisation
des performances, l'accès et l'agrégation sont requis.
• La composabilité du service
Les services peuvent être utilisés pour composer d'autres services.
• Découverte de services
Les services sont complétés par des métadonnées de communication grâce auxquelles
ils peuvent être efficacement découverts et interprétés.
• Réutilisabilité des services
Logic est divisé en différents services, pour favoriser la réutilisation du code.
• Encapsulation de services
De nombreux services qui n'étaient pas initialement prévus dans le cadre de la SOA,
peuvent être encapsulés ou devenir une partie de la SOA.

3.2 Niveau d'intégration


3.2.1 L'intégration par les données :
C’est l’ensemble des techniques utilisées pour transférer les données entre les data
stores (où on stocke les données). sans avoir besoin d’introduire des changements sur
la logique des applications de l’entreprise.Ce qui peut être explicité comme étant le
fait d’extraire les informations d’un emplacement pour le mettre à la disposition d’un
autre qui a besoin de ces informations, tout en actualisant la base de données.Ce type
d’intégration est utilisé dans le cas où les applications à intégrer n’ont pas une
interface des utilisateurs et des APIs
3.2.2 L'intégration par les interfaces :
Cette approche est aussi appelée screen-scrapping qui permet de relier la logique
d’intégration dans l’interface des utilisateurs . L’intégration à ce niveau se fait par le
développement d’une interface commune (partagée) pour exposer les différentes
applications isolées en intra et inter-entreprises.
Il peut aussi extraire et échanger des données avec des applications distantes.
3.2.3 L’intégration les traitements :
L’intégration à ce niveau permet à des applications de partager les fonctionnalités
offertes par d’autres applications hétérogènes et indépendantes et cela par
l’invocation des services qu’elles exposent . Le mécanisme le plus simple permettant
de réaliser ce type d’intégration est l’utilisation des APIs (Application Programming
Interface), ou encore plus récemment les web services .
3.2.4 Intégration par les processus :
C’est la forme la plus complexe de l’intégration. Elle sert à rendre valable une
application dans le contexte d’une autre sans la dupliquer. Elle permet aussi de
construire de nouveaux processus métier à base des applications et progiciels(logiciel
applicatif) existants. Ceci crée de nouvelles opportunités pour l’entreprise à moindre
coût. Les données circulant dans la nouvelle organisation sont accédées et maintenues
selon une logique de métier (business logic) qui a des règles et une sécurité de
données. Ces données ne sont plus simples mais des objets métier (BOD : Business
Object Document, ex bon de commande) qui portent déjà un sens . Grâce à cette
forme d’intégration, les nouveaux processus métier qui les manipulent sont crées.
3.3 Authentification unique et la Fédération d'identité
Pour protéger l’accès aux services digitaux, il est nécessaire d’utiliser des identifiants
propres à chacun.La multiplication des applications au quotidien dans le cadre privé
et professionnel nous oblige à mémoriser toujours plus d’identifiants et de mots de
passe. utilisent les mêmes mots de passe ou des mots simples à retenir. Ces pratiques nous
rendent pourtant extrêmement vulnérables aux attaques.
C’est pour résoudre ces problèmes, que sont arrivées les solutions de Single Sign
On et de fédération d’identités.
Le Single Sign On (SSO) propose une solution à ce problème de prolifération des
mots de passe, avec une authentification unique de l’utilisateur. Cette authentification
se propage aux applications auxquelles l’utilisateur souhaite accéder grâce à la
fédération d’identité.
3.3.1 La Centralisation
Dans le cadre de la mise en place d'une fédération d’identité, une grande quantité
d’informations relatives aux acteurs sont manipulées. Ces informations doivent être
stockées dans une base d'informations afin d'en assurer la cohérence, la sécurité,
l’accessibilité et la centralisation.
Ainsi la base d'information étant beaucoup plus sollicitée en lecture, nous avons porte
notre choix sur les annuaires LDAP qui sont réputés être performants pour les accès
en lecture.
3.3.1.1 Annaire
Un annuaire électronique peut être vu comme une base de données spécialisée, dont
la fonction première est de retourner un ou plusieurs attributs d'un objet grâce à des
fonctions de recherche multicritères.
Les objets peuvent être de nature très diverse. Par exemple, un objet de l’annuaire
peut représenter une personne et les attributs de cet objet seront alors son nom, son
prénom, son numéro de téléphone, etc. Un annuaire électronique va centraliser des
informations et les rendre disponibles, via le réseau, à des applications, des systèmes
d’exploitation ou des utilisateurs.
3.3.1.2 Différnce entre Annuaire et Base de Données
Bien qu’un annuaire soit comparable à une base de données pour un grand nombre de
fonctionnalités, il en diffère en de nombreux points.
• Un annuaire est très performant en consultation (c’est-à-dire en lecture ou en
recherche). Par contre, un annuaire n’est pas très adapté pour des mises à jour
fréquentes (écriture). Les données contenues dans un annuaire sont en effet beaucoup
plus pérennes, et il est donc totalement inutile d’optimiser les fonctions de mise à
jour.
• Une base de données doit, par contre, généralement supporter
des applications qui la remettent constamment à jour. Cela signifie que la
fonctionnalité écriture dans une base de données est importante et doit par conséquent
être optimisée.
• Un annuaire LDAP organise les données de manière arborescente,tandis que
les bases de données le font au sein de tableaux à deux dimensions.
3.3.1.3 LDAP
3.3.1.3.1 Présentation
LDAP (Lightweight Directory Access Protocol, ou Protocole d'accès aux annuaires
léger) est un protocole standard permettant de gérer des annuaires, c'est-à-dire
d'accéder à des bases d'informations sur les utilisateurs d’un réseau par
l’intermédiaire du protocole TCP/IP.
Les bases d'informations sont généralement relatives à des utilisateurs, mais elles sont
parfois utilisées à d’autres fins comme pour gérer du matériel dans une entreprise.
LDAP est un protocole client-serveur et offre quatre modèles prédéfinis. L’objectif de
cette modélisation est de favoriser le partage et de simplifier la gestion des
informations concernant des personnes, et plus généralement toutes les ressources de
l’entreprise, ainsi que des droits d’accès des utilisateurs sur ces ressources.
Les modèles LDAP représentent les services que propose le serveur au client.Ainsi
on distingue :
• Le modèle de nommage définit comment l'information est stockée et
organisée
• Le modèle fonctionnel définit les services fournis par l'annuaire (recherche,
ajout, ...)
• Le modèle d'information définit le type d'informations stockées

• Le modèle de sécurité définit les droits d'accès aux ressources

3.3.1.3.2 Structure
Les données LDAP sont structurées dans une arborescence hiérarchique. Chaque
nœud de l'arbre correspond à une entrée de l'annuaire ou Directory Service Entry
(DSE) et au sommet de cette arbre, appelé Directory Information Tree (DIT), se
trouve la racine ou suffixe.
Les entrées correspondent à des objets abstraits ou issus du monde réel, comme une
personne, une imprimante, ou des paramètres de configuration. Elles contiennent un
certain nombre de champs appelés attributs dans lesquelles sont stockées des valeurs.
Chaque serveur possède une entrée spéciale, appelée root Directory Specific Entry
(rootDSE) qui contient la description de l'arbre et de son contenu.
Un objet est constitué d'un ensemble de paires clés/valeurs appelées attributs
permettant de définir de façon unique les caractéristiques de l'objet à stocker. Par
analogie avec la terminologie objet on parle ainsi de classe d'objet pour désigner la
structure d'un objet, c'est-à-dire l'ensemble des attributs qu'il doit comporter. De cette
façon un objet est un ensemble d'attributs avec des valeurs particulières.
LDAP utilise le format LDAP Data Interchange Format (LDIF) qui permet de
représenter les données LDAP sous format texte standardisé, il est utilisé pour
afficher ou modifier les données de la base.

Dc : domain component
Ou : organizational units
Cn : common name
Uid : user identifier
Figure 3.4:Exemple de DIT
3.3.2 La Fédération d'identité
Dans les entreprises les employées utilisent de nombreuses applications pour
éffectuer les tâches et doivent s'authentifier à chaque fois.La fédération d'identité
permet alors aux utilisatueurs d'accéder à toutes les applications du Système
informatique après s'être authentifiés une seule fois.En effet elle permet de propager
les informations d'authentifications vers les autres applications pour éviter à
l'utilisateur de saisir à nouveau son login et son mot de passe.Elle repose sur une
relation de confiance entre le founisseur de service(SP) et fournisseur d'identité(IdP).
3.3.2.1 Principe
Dans la fédération d'identité, un IdP se porte garant de l'identité des utilisateurs et un
SP fournit des services aux utilisateurs. Lorsqu'un utilisateur souhaite accéder à un
service d'un SP, le SP délègue l'authentification à l'IdP. C'est ce qu'on appelle la
fédération.Pour que la fédération d'identité ait lieu, le SP doit faire confiance à la
capacité d'authentification de l'IdP.
Supposons qu'un utilisateur souhaite accéder à une application :
1.L'utilisateur accède à l'application du SP.
2.Le SP exige que l'utilisateur soit authentifié auprès de l'IdP (le SP peut avoir des
mécanismes pour vérifier si l'utilisateur est actuellement authentifié auprès de l'IdP à
l'aide des données de session). L'utilisateur non authentifié est redirigé vers la page de
connexion de l'IdP.
3.L'utilisateur s'authentifie auprès de l'IdP (en saisissant les identifiants de
connexion).L’IdP vérifie au niveau de l’annuaire si les informations sont correctes et
récupère les informations additionnelles associées à son identité.
4.Si les informations d'identification de l'utilisateur sont correctement validées,
l'utilisateur est authentifié et reçoit un jeton d'accès(la validité et l’identité)
5.le fournisseur de service évalue le jeton et autorise l’accès de l’utilisateur.
Le figure ci-dessous vous aidera à comprendre facilement le flux.
Figure 3.5:Principe de fonctionnement de la Fédération d'identité
3.3.2.2 Lien de confiance
Outre la gestion technique assurée par les logiciels de fédération, il faut que les
fournisseurs d'identité et les ressources se fassent mutuellement "confiance".
Pour se faire mutuellement confiance un fournisseur d'identité et une ressource
peuvent s'engager à chacun respecter des règles (par exemple le fournisseur d'identité
peut s'engager à maintenir des informations à jour sur ses utilisateurs). Mais si chaque
paire de fournisseur d'identité-ressource doit le faire, le nombre d'engagements à
maintenir ainsi entre les multiples acteurs d'une communauté sera énorme.
Une fédération d'identité évite ce problème en regroupant des fournisseurs d'identité
et des ressources qui s'engagent, au moment de leur inscription, à respecter un
ensemble minimal de règles qui permettent d'assurer la confiance. Ainsi un
fournisseur d'identité ou une ressource qui s'inscrit dans une fédération n'a pas à
formaliser avec chacun des autres participants des relations de confiance, car il sait
que ces autres participants se sont engager à respecter des qui permettent d'assurer la
confiance.
Au sein d’un cercle de confiance, des règles existent pour assurer la protection des
données personnelles des utilisateurs qui peuvent être communiquées entre
fournisseurs.
3.3.2.3 SAML
Le SAML(Security assertion markup language) est un protocole ouvert et standardisé
basé sur le langage XML pour échanger des informations d’authentification et
d’autorisation entre des entités ou domaines de sécurité.
Il sert principalement à établir une authentification unique (SSO) entre un fournisseur
d'identités (IdP) et un prestataire de services (SP). Lorsqu'un IdP (un employeur, par
exemple) et un fournisseur de services implémentent le protocole SAML, ils peuvent
facilement authentifier les utilisateurs accrédités chez l’IdP pour qu'ils puissent
utiliser les services.
3.3.2.4 OAUTH
OAuth est un protocole libre qui permet d'autoriser un site web, un logiciel ou une
application (dite « consommateur ») à utiliser l'API sécurisée d'un autre site web (dit
« fournisseur ») pour le compte d'un utilisateur. OAuth n'est pas un protocole
d'authentification, mais de « délégation d'autorisation ».
OAuth permet aux utilisateurs de donner, au site ou logiciel « consommateur »,
l'accès à ses informations personnelles qu'il a stocké sur le site fournisseur de service
ou de données, ceci tout en protégeant le pseudonyme et le mot de passe des
utilisateurs.
3.3.2.5 OPENID
OpenID est un système d’authentification décentralisé qui permet l’authentification
unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier
auprès de plusieurs sites (devant prendre en charge cette technologie) sans avoir à
retenir un identifiant pour chacun d’eux mais en utilisant à chaque fois un unique
identifiant OpenID. Il permet aussi d’éviter de remplir à chaque fois un nouveau
formulaire en réutilisant les informations déjà disponibles.Les opérations sont
réalisées via des web services REST et les données sont échangées au format JSON.
Le protocole définit notamment des mécanismes optionnels de signature et de
chiffrement des données, ce qui n’était jusqu’alors pas possile dans les autres
protocoles.De manière similaire aux assertions SAML, ces jetons peuvent être signés
et chiffrés
OpenID a été conçu pour répondre aux limites de OAuth2 dans le domaine de
l’authentification forte.
3.3.2.6 Shibboleth
Shibboleth est développé depuis 2001 par Internet2 et désigne à la fois une norme et
un produit, il repose sur un mécanisme de propagation d'identités. Son objectif est
double :
• d'une part il permet, lors de la connexion à un service enregistré dans la
fédération, de déléguer l'authentification à l'établissement d'origine de
l'utilisateur.
• d'autre part il contribue à obtenir certains attributs (données annuaire) de
l'utilisateur, afin de gérer le contrôle d'accès ou personnaliser les contenus.
Shibboleth s'appuie en général sur un système CAS et offre donc également les
fonctionnalités de SSO standards (fenêtre d'authentification unique, plus besoin de
retaper son mot de passe lorsque l'utilisateur passe d'un service à l'autre).
3.3.3 L'Authentification Unique
L'authentification unique, souvent désigné par le sigle anglais SSO (de single sign-
on) est une méthode permettant à un utilisateur d'accéder à de multiples services,
sites web et application ne procédant qu'à une seule authentification.Une solution
d'authentification unique peut simplifier la gestion des noms d'utilisateur et mots de
passe à la fois pour les utilisateurs et les administrateurs.
3.3.3.1 Principe
Les utilisateurs n'ont plus besoin d'archiver des différents jeux d'identifiants et
peuvent se contenter de mémoriser un seul mot de passe plus complexe.
La procédure de connexion se déroule généralement comme suit :
1. Un utilisateur navigue jusqu'à l'application ou le site Web auquel il veut
accéder, c'est-à-dire le fournisseur de services.
2. Le fournisseur de services envoie un jeton contenant certaines informations à
propos de l'utilisateur (son adresse e-mail, par exemple) au système SSO, c'est-
à-dire le fournisseur d'identités, dans le cadre d'une demande d'authentification
de l'utilisateur.
3. Le fournisseur d'identités contrôle d'abord si l'utilisateur s'est déjà authentifié,
auquel cas il lui octroie l'accès à l'application du fournisseur de services et
passe directement à l'étape 5.
4. Si l'utilisateur ne s'est pas connecté, il sera invité à le faire en renseignant les
identifiants requis par le fournisseur d'identités. Il peut s'agir simplement d'un
nom d'utilisateur et d'un mot de passe, mais peut inclure d'autres formes
d'authentification comme un mot de passe à usage unique (OTP).
5. Une fois que le fournisseur d'identités valide les identifiants renseignés, il
renverra un jeton au fournisseur de services pour confirmer la réussite de
l'authentification.
6. Ce jeton est transmis au fournisseur de services par le biais du navigateur de
l'utilisateur.
7. Ce jeton que reçoit le fournisseur de services est validé en vertu de la relation
de confiance qui a été établie entre le fournisseur de services et le fournisseur
d'identités au moment de la configuration initiale.
8. L'utilisateur se voit octroyer l'accès au fournisseur de services.
Figure 3.6:Procédure d'authentification
Si l'utilisateur tente d'accéder à un autre site Web, il faudra alors qu'une même
relation de confiance soit configurée entre ce nouveau site Web et la solution SSO,
puis la procédure d'authentification se déroulera en suivant les mêmes étapes.
3.3.3.2 Les différents types d’authentification unique
3.3.3.2.1 Approche fédérative
Dans ce mécanisme, chaque service gère une partie des données d'un utilisateur
(l'utilisateur peut donc disposer de plusieurs comptes),
mais partage les informations dont il dispose sur l'utilisateur avec les services
partenaires. Ce mécanisme a été développé pour répondre à un besoin de gestion
décentralisée des utilisateurs, où chaque service partenaire désire conserver la
maîtrise de sa propre politique de sécurité.
3.3.3.2.2 Approche centralisé
Le principe de base est ici de disposer d'une base de données globale et centralisée de
tous les utilisateurs ou d'un annuaire. Cela permet également de centraliser la gestion
de la politique de sécurité
3.3.3.2.3 Approche coopérative
Le mécanisme coopératif, dont les systèmes Shibboleth et CAS sont les principaux
représentants, part du principe que chaque utilisateur dépend d'une des entités
partenaires. Ainsi,lorsqu'il cherche à accéder à un service du réseau, l'utilisateur est
authentifié par le partenaire dont il dépend. Comme dans l'approche fédérative,
cependant, chaque service du réseau gère indépendamment sa propre politique de
sécurité.
3.3.3.3 Les Méthode d'authentification SSO
3.3.3.3.1 RADIUS
RADIUS (Remote Authentication Dial-In User Service) est un protocole client-
serveur permettant de centraliser des données d’authentification.
Le protocole RADIUS repose principalement sur un serveur (le serveur RADIUS),
relié à une base d'identification (base de données, annuaire LDAP, etc.) et un client
RADIUS, appelé NAS (Network Access Server), faisant office d'intermédiaire entre
l'utilisateur final et le serveur. L'ensemble des transactions entre le client RADIUS et
le serveur RADIUS est chiffrée et authentifiée grâce à un secret partagé.
Il est à noter que le serveur RADIUS peut faire office de proxy, c'est-à-dire
transmettre les requêtes du client à d'autres serveurs RADIUS.
Une séquence d’identification pourra donc se dérouler de la façon suivante
1. Le NAS demande au client de s’identifier:le client fournit son identifiant au NAS.
2. Le NAS achemine la demande au serveur RADIUS afin d’identifier (ou autoriser,
ou comptabiliser) le client ;
3. Le serveur RADIUS consulte la base de données hébergeant ces informations, par
exemple au travers du protocole d’annuaire LDAP.
4.Le serveur RADIUS retourne ainsi une des quatre réponses suivantes :
✔ ACCEPT : l'identification a réussi ;
✔ REJECT : l'identification a échoué ;
✔ CHALLENGE : le serveur RADIUS souhaite des informations
supplémentaires de la part de l'utilisateur et propose un " défi " (en
anglais " challenge ") ;
✔ CHANGE PASSWORD : le serveur RADIUS demande à l'utilisateur
un nouveau mot de passe
5. Le NAS peut alors authentifier le client grâce à la réponse obtenue du serveur
RADIUS.La figure ci_dessous illustre la procédure d'authentification avec RADIUS :

Figure 3.7:Mécanisme d’authentification Radius


3.3.3.3.2 KERBEROS
Kerberos est un protocole d'authentification réseau qui repose sur un mécanisme de
clés secrètes (chiffrement symétrique) et l'utilisation de tickets. L’utilisateur
s’authentifie sur le KDC puis utilise un ticket pour s’authentifier sur chaque service
demandé.Un KDC se compose d’un AS qui authentifie un utilisateur, et d’un serveur
d’octroi de tickets (TGS).
Chaque entité du réseau (client ou serveur) possède une clé secrète qui n’est connue
que de elle-même et du KDC. La connaissance de cette clé implique l’authenticité de
l’entité. Pour la communication entre deux entités du réseau, le KDC génère une clé
de session, appelée ticket Kerberos ou ticket de service.
Les étapes suivantes décrit le processus’authentification :
1. Le client demande au AS des informations d’identification pour un serveur
spécifique.
2. Le KDC vérifie les données d’identification et renvoie un TGT chiffré et une clé de
session.
3.Le client communique ensuite avec le TGS, en utilisant le TGT qu’il a reçu de l’AS
pour prouver son identité, et demande un service.
4.Si le client est admissible au service, le TGS émet un ticket Kerberos au client.
5.Le client contacte ensuite le serveur hébergeant le service (appelé le serveur de
service), en utilisant le ticket Kerberos pour prouver qu’il est autorisé à recevoir le
service. Le ticket Kerberos a une durée de vie configurable.
6.Le client s’authentifie avec l’AS une seule fois. S’il contacte le serveur physique
plusieurs fois, il réutilise le ticket AS.
La figure ci_dessous illustre le mécanisme d’authentification avec kerberos:

Figure 3.8:Authentification avec Kerberos


3.3.3.3.3 CAS
Le CAS(Central Authentication Service) est un système d'authentification unique
(SSO) pour le web développé par l'Université Yale . On s'authentifie sur un site Web,
et on est alors authentifié sur tous les sites Web qui utilisent le même serveur CAS. Il
évite de s'authentifier à chaque fois qu'on accède à une application en mettant en
place un système de ticket.
Le principe de fonctionnement du CAS est décrit comme suit :
1- Le client web tente une connexion vers une application web à partir d’une requête
initiale en
http. L’application web redirige la requête vers une page d’authentification du serveur
CAS. Le
client peut accéder directement en https au CAS (1’) .
2- Le serveur CAS réalise l’authentification grâce à LDAP (login + mot de passe)
3- Le CAS génère un ticket ST (Service Ticket) au client. Ce dernier envoie les
paramètres de
connexion à l’application web et passe en paramètre le ticket ST.
4- L’application web accède directement au CAS en http ou en https et passe en
paramètre l’ID de service (l’ID de service est l’URL du service).
5- Le CAS génère un ticket TGC (Ticket Granting Cookies). Le CAS envoie le TGC
à l’application
web. C'est un cookie de session qui est transmis par le serveur CAS au navigateur du
client lors de
la phase de login.
6- Le CAS valide le ticket ST et retourne l’UID de l’utilisateur. En ce moment
l’utilisateur est authentifié et peut maintenant accéder à la page
Figure 3.9:Authentificaion avec CAS
3.4 Exemple d’EAI:France Telecom
France Telecom choisit webMethods spécialiste des solutions logicielles
d’intégration, pour répondre à l’ensemble de ses attentes concernant ses projets EAI
de partage des informations via des applications informatiques différentes. "Le
groupe a souhaité se doter d’outils performants pour ouvrir son système
d’information à ses clients et partenaires", explique Lucien Ducorney, directeur du
SICoR (système d’information commercial et ressources) de France Télécom. Un
second objectif consistait à intégrer des outils progiciels pour développer l’efficacité
des processus internes et de la relation commerciale.
3.4.1 L’entreprise Webmethods
webMethods était une société de logiciels d'entreprise, acquise par Software AG ,
spécialisée dans l'intégration d'applications, l'intégration de processus métier et
l'intégration de partenaires B2B. Fondée en 1996, la société vendait aux organisations
des systèmes permettant d'utiliser des services Web pour connecter des applications
logicielles sur Internet.. En 2007, WebMethods a été rachetée par Software AG est
devenue une filiale de cette entreprise.Software AG a conservé le nom webMethods
et l'utilise comme marque pour identifier une suite logicielle englobant l'amélioration
des processus, l'activation SOA, la modernisation informatique et l'intégration des
entreprises et des partenaires.
3.4.2 Service Webmethods
WebMethods est avant tout une plateforme d’intégration d’application d’entreprise
(en anglais EAI pour enterprise application integration). Elle consiste à faire
communiquer entre elles plusieurs applications hétérogènes. C’est-à-dire écrites dans
des langages différents .
Elle assure notamment la médiation entre ces différentes applications. Les
applications et bases de données deviennent personnalisables, qu’elles soient
installées sur site ou dans le cloud, elles sont interopérables. Les informations se
partagent de manière simple et efficace. De plus, les processus automatisé
fluidifient les flux de données.
La plateforme WebMethods permet de transporter des données de la source vers
la cible, de transformer les données avant l’envoi, de gérer le flux de messages
entre la source et la cible et d’assurer la connexion entre les différentes
applications. Les données sont traitées de manière à être accessibles en temps
réel, et demeurent disponibles aux nouvelles applications.
L’un des grands avantages de WebMethods, c’est le gain de temps. En effet,
plus besoin d’effectuer des développements supplémentaires et une
maintenance compliquée en cas d’ajout d’une nouvelle application.
Conclusion
Dans ce chapitre nous avons eu à étudier les différentes techniques
d’intégration.En suite nous avons une étude sur la propagation d’identité avant
de spécifier les méthodes d’authentification unique.
L’objet du chapitre suivant est d’étudier les technologie Web Services