Skip to content.

Boost Industrie et Services

Sections
Personal tools
You are here: Home » Projets » Aéronautique » Librairie » Gestion des identités

Gestion des identités

documents présents sur le CD

Avertissement :


Le présent document a utilisé la trame d’un document relatif à la sécurité des Web services en général - récemment produit par le NIST ( Guide to Secure Web Services - Anoop Singhal, Theodore Winograd, Karen Scarfone Publications du NIST Août 2007.  Nom du fichier sur le CD ROM Gestion des identités : NIST_SecureWebServicesSP800-95 ) - et s’est efforcé d’en orienter les termes pour prendre en compte les questions intéressant plus spécialement les projets TIC PME.

TIC PME et la Gestion des identités


1. Introduction


Les projets de développement des échanges électroniques se multiplient et certains atteignent une dimension continentale voire mondiale à l’exemple des échanges électroniques du commerce international.
La multiplication des partenaires associés dans des échanges électroniques rend de plus en plus nécessaire de s’assurer de leur identité, à la fois pour des raisons liées aux risques de sécurité et pour des raisons tenant à la confidentialité de certaines données, notamment celles relatives à la conception des produits.

De plus, nous assistons à une mutation progressive des systèmes e-business.
Partant de systèmes EDI à base de messages échangés via des Réseaux dits à valeur ajoutée (celle-ci consistant souvent à exécuter des tâches subalternes comme convertir des protocoles de communication ou des modifications de formats), le e-business B2B tend à se complexifier et les architectures techniques utilisées deviennent plus standardisées mais plus diversifiées.

Par un Web service, une entreprise peut exposer une partie de son système d’information, par exemple son catalogue ou l’état de ses stocks. Dans un tel cas, la gestion des identités peut être assez simple.

Mais le B2B qui assure le plus d’avantages comparatif à une entreprise tend de plus en plus à exploiter les systèmes d’information internes dans le cadre d’architectures orientées services. TIC PME renvoie à ce propos d’une part aux travaux du groupe thématique Architectures techniques et d’autre part aux annonces des offreurs de solutions de gestion de production et d’ERP qui tendent désormais à intégrer nativement les standards sectoriels (Chimie CIDX, Pétrole PIDX, Composants électroniques Rosettanet etc..).
Des bancs de tests se mettent en place associant un nombre important d’éditeurs de logiciels dont les solutions deviennent nativement capables, sans « traduction » de générer ou recevoir et traiter des e-Documents ce qui facilite
•    l’interopérabilité de solutions variées, d’éditeurs de logiciels de taille variable
•    le déploiement de systèmes comportant davantage de documents associés dans des scénarios d’échanges plus complexes
•    et finalement le développement de réels échanges de machine à machine, d’application à application.

Ces solutions logiciels devenant de plus en plus aptes de utiliser des Web services, soit sur le plan interne, soit dans le cadre d’échanges inter entreprises, ne peuvent dans ce dernier cas le faire sans prendre les plus extrêmes précautions relativement aux individus et aux applications habilités à réaliser des échanges mettant en jeu les systèmes d’information des entreprises et donc des informations stratégiques dont l’accès doit être soigneusement protégé.

La gestion des identités a donc pour objet d’assurer par des moyens appropriés qu’à mesure que les systèmes d’information d’une entreprise deviennent aptes à échanges des informations avec d’autres systèmes d’information, ceux des partenaires en affaires, en même temps l’entreprise n’expose ses systèmes d’information qu’à la connaissance de partenaires dûment autorisés à la faire.

La gestion des identités est donc un aspect de la sécurité des systèmes d’information en général, et des Web services en particulier.

Mais qu’entend-on au juste par Web services ?

Il n’est pas dans le propos de cette introduction d’entrer trop avant dans la définition de ces types Web services qui sont destinés aux échanges B2B.

Disons simplement qu’il y a une gamme de Web services, allant de la simple exposition d’un catalogue de produits ou d’états de stocks jusqu’à la situation caractérisée par un grand nombre de partenaires amont (fournisseurs), aval (clients) auxquels s’ajoutent les sous-traitants et les prestataires de services de tous types (logistiques, administrations, banques) comme dans le cas d’entreprises telles que ST Microelectronics  ou Nokia.

Les Web services peuvent être utilisés essentiellement à usage interne (auquel cas leur sécurisation et la gestion des identités est un problème interne) mais ils peuvent aussi être rendus accessibles aux partenaires et alors la gestion des identités devient cruciale.

Signalons enfin que les travaux ebXML ont spécialement traité de l’utilisation de Web services pour gérer des échanges B2B et que les organismes de standardisation recherchent le plus possible à mettre en facteur commun les solutions à base de Web services au sens B2B et celles couvrant un spectre plus large de Web services.

 

2. Les différentes facettes des Web services


2.1. La Découverte de Web Services (Web Services Discovery)


La découverte de Web service suppose que des Web services (service de fixation des taux) soient déclarés dans le Registre (flèche N° 1).
Le service de prêts ayant besoin de ce service accèdera au Registre UDDI (flèche N° 2) qui lui notifiera l’existence d’un tel service et ses caractéristiques, y incluant le moyen d’y accéder (flèche N° 3).

2.2 Web Service «Messaging»




1.    Le service de prêts envoie un message (requête SOAP) au service des crédits pour obtenir une vérification de l’état des crédits d’un postulant
2.    Le service des crédits envoie un message (réponse SOAP) au service des prêts donnant le résultat de la vérification
3.    Le résultat étant positif, le service des prêts adresse au service de fixation des taux un message (requête SOAP) demandant de faire une compilation des taux possibles tels que proposés par la banque
4.    Le service des taux envoie un message (réponse SOAP) notifiant ces taux au service des prêts qui dispose des informations nécessaires pour agir.

De la même façon, on aurait pu solliciter un système de réservation de transport puis un système de réservation d’hôtellerie et dans un deuxième temps réserver sur les deux systèmes, sachant toutefois que dans ce cas là il y a un impact sur les deux systèmes de réservation dont l’état est modifié par les deux réservations.

La gestion des réservations peut nécessiter une gestion des identités, car le traitement de l’information peut être dépendant de la personnalité du requérant, ce qui n’est pas le cas d’un système délivrant une simple information fournie identiquement à tout requérant.


2.3 Web Portals




 
Les portails Web permettent à un utilisateur d’avoir accès au résultat d’une requête soumise via le portail à une application, qui utilise les arguments de la requête pour effectuer un traitement, en confie le résultat au portail qui notifie le résultat à l’utilisateur. A partir de cet exemple, des variantes peuvent être envisagées. L’utilisateur peut être une application, il peut y avoir des arguments précisant quel est l’identité du requérant etc. Le portail Web devient alors plus complet.

On distingue alors des Web services ayant différents rôles :

•    Web service demandeur : il initie la transaction et s’assure qu’elle satisfait certains critères exigés par le Web service fournisseur, chargé de traiter la transaction
•    Web service fournisseur traite la transaction et apporte la réponse sollicités. Il dicte cependant ses exigences en matière d’authentification, d’autorisation, de cryptage et de non répudiation et vérifie que les arguments présentés sont satisfaisants. Ces exigences peuvent être notifiées par un registre UDDI.
•    Web services intermédiaires : c’est un Web service assurant certains traitements dans une chaîne existant entre un requérant et une application.

La figure suivante illustre les rôles assumés par les Web services.




3. Eléments de Sécurité des Web services


Ces éléments ne sont pas propres aux Web services et l’on retrouve les éléments de sécurité auxquels nous sommes habitués :
•    Identification and Authentification : La vérification de l’identité d’un utilisateur, d’un processus ou d’un équipement est souvent un pré requis de l’autorisation d’accès à une ressource d’un système d’information.
•    Autorisation. C’est la permission d’utiliser une ressource accordée directement ou indirectement par une application ou l’administrateur d’un système.
•    Intégrité. C’est la garantie qu’une donnée n’a pas été altérée illégalement pendant son transit, son traitement ou son stockage.
•    Non-répudiation. Assurance que l’émetteur d’une information reçoit une preuve de délivrance et que le receveur de l’information est certain de l’identité de l’émetteur de telle sorte qu’aucun des deux ne puisse répudier la transaction effectuée.
•    Confidentialité. Préservation de l’information au bénéfice de ceux qui sont habilités à y avoir accès (vie privée, propriété de l’information, non divulgation).
•    Protection des données personnelles et confidentielles.

4. Quelques mots au sujet d’ebXML.


ebXML a été développé pour donner un nouvel élan aux échanges électroniques B2B de type EDI en tirant parti des possibilités offertes par les technologies émergentes (Internet, Web, XML). Considéré comme trop complexe face à des besoins pouvant être satisfaits par des Services Web élémentaires, ebXML est en revanche bien adapté au cas de systèmes B2B évolués, d’autant plus que des implémentations partielles d’ebXML sont envisageables.
ebXML est d’ailleurs un Web service particulier, spécialement conçu pour les applications B2B et les organismes de standardisation font des efforts notables pour que les différents types de Web services partegant le plus grand nombre possible de spécifications.

5. Sécurité des Web services : La pile de Standards





6. Focale sur la Gestion des Identités


La gestion des identités pour les Architectures orientées services (SOA) englobe le spectre entier des évènements, des informations et des documents au moyen desquels l’identité d’une entité est vérifiée, l’identité des documents constatée et les accréditations sont attribués à l’entité. Elle couvre aussi le moyen d’identifier les entités à leur point d’entrée dans une architecture orientée services.
Dans une SOA, l’identité d’une entité est à l’origine des autorisations et de la confiance.
Un système de Gestion des Identités (Identity Management System [IDMS]), tel que celui décrit dans la figure qui suit est responsable de la vérification de l’identité des entités, de leur enregistrement et de l’émission à leur intention des identifiants digitaux.


Une fois qu’une entité s’est vue notifier un identifiant digital, cet identifiant peut être utilisé au sein d’une organisation pour associer une autre information à cette entité telle qu’un rôle ou des attributs d’autorisations.
L’identifiant peut aussi devenir partie d’une accréditation qui autorise l’entité à avoir accès à différentes ressources dans la SOA.
Une fois enregistrée, une entité doit fournir une portion suffisante de ses accréditations pour être authentifiée.
De nouveau, différentes organisations ont différentes politiques s’agissant de savoir ce qui représente des accréditations suffisantes pour une authentification.
De nombreux sites de e-commerce se contentent de Nom d’utilisateur et de mot de passe ; d’autres exigent un certificat X. 509.
Une fois que l’identité de l’entité a été authentifiée, le point de décision du système (Policy decision point PDP) ou de la ressource à laquelle l’entité désire avoir accès doit déterminer si l’entité une dûment authentifiée est également autorisée à bénéficier de cet accès à cette ressource là.
Pour donner cette autorisation, le PDP s’en remet à la gestion des privilèges et des attributs.
La gestion des privilèges enclenche les politiques gouvernant l’accès des entités. La décision politique d’autoriser ou de refuser l’accès peut être fondée sur un simple attribut de l’entité tel que son rôle ou bien elle peut exiger une combinaison fine d’attributs tels que la localisation physique de l’entité, son rôle actif courant dans le système, son statut de situation régulière.
La gestion des attributs utilise l’identification digitale de l’entité pour localiser et retrouver ces attributs requis par le politique de gestion des privilèges.

7. Architectures de Gestion des Identités


Il en existe trois principales :

•    Gestion isolée des identités
C’est l’architecture la plus fréquemment rencontrée dans les applications exposées sur Internet. Le fournisseur de services agit à la fois en tant que fournisseur d’accréditations et d’identités. Cela simplifie la gestion d’un service unique et permet de se passer des services d’un tiers de confiance (Trusted third party ou TTP).
En contrepartie, dans une telle gestion isolée des identités, chaque service doit connaître toutes les accréditations et les identifiants de tous les requérants. Dans une architecture orientée services importante, administrer chaque fournisseur de services peut devenir difficile à gérer voire ingérable. C’est notamment le cas des systèmes d’échanges électroniques B2B impliquant de nombreux partenaires dans une filière.
•    Gestion fédérée des identités / Federated identity management.
Lorsque la gestion des identités est fédérée, un groupe de fournisseurs s’entend pour reconnaître les identifiants d’utilisateurs des uns et des autres. Chaque fournisseur de service agit en tant que fournisseur d’accréditations et d’identifiants pour un sous ensemble de requérants. En produisant des assertions (e.g., assertions d’authentifications et attributs associés de SAML), un fournisseur de services peut fournir à d’autres fournisseurs de services les informations relatives à un requérant sans demander à ce dernier de s’authentifier une seconde fois.
Cela simplifie la gestion des identités et des accréditations pour l’architecture orientée services – SOA - dans son ensemble mais exige des services individuels qu’ils soient mutuellement avertis de leurs assertions de confiance.
Dans une SOA d’entreprise unique, il peut être facile aux fournisseurs de se faire une confiance mutuelle, mais cela pose plus de problèmes lorsque les fournisseurs de services appartiennent à des organisations différentes.
Un requérant Dans une fédération d’identités, il est important de mettre en place une organisation (une police) adaptée aux types de données qui transitent dans l’ensemble systémique de l’Architecture orientée services.
Gestion centralisée des identités / Centralized identity management. Dans la gestion centralisée des identités, les fournisseurs se reposent sur un tiers de confiance (TTP) qui procure les identifications et les accréditations aux requérants.. La gestion centralisée des identités est semblable à la gestion fédérée des identités en ce sens que les fournisseurs d’identités et d’accréditations fournissent des assertions directement aux fournisseurs de services qui permettent aux requérants d’avoir un accès aux services sans devoir s’authentifier une seconde fois.
Dans cette architecture, les fournisseurs particulier de services ont seulement besoin de connaître le fournisseur de l’identité d’un requérant.
Dans les architectures orientées services SOA multi organisations, ces organisations peuvent souhaiter faire davantage confiance aux fournisseurs d’identité d’une autre organisation qu’à ce que fournirait un service individuel.
En revanche la gestion centralisée des identités concentre les risques de faille sur un point unique.

8. Les régles (lois) de l’Identité


En Mai 2005, Kim Cameron, spécialiste des questions relatives à la gestion des identités chez Microsoft, a rédigé les Lois de l’identité (The Laws of Identity) à partir du fruit de ses recherches en vue de définir un metasystème de gestion des identités. Les informations qui suivent ne font que refléter les vues personnelles de Kim Cameron, auxquelles une relative légitimité est cependant reconnue par les experts du domaine.

Sept « lois » ou bonnes pratiques ont été définies :

•    Contrôle et consentement de l’utilisateur.
Le système de gestion des identités ne doit pas révéler des informations sans le consentement de l’utilisateur concerné par cette révélation. Cf CNIL.
•    Divulgation minimale pour un usage particulier.
Le système de gestion des identités ne doit révéler que l’information indispensable, réduite au maximum, dans le cadre d’une utilisation particulière.
•    Utilisation justifiée (Justifiable Parties).
Un système de gestion des identités ne doit révéler des informations qu’aux parties qui en justifient l’emploi.
•    Gestion dirigée de l’identité (Directed Identity).
Un système de gestion des identités doit être capable d’être soit multi  ou omni directionnel, donc capable de partager avec toute tierce partie, soit uni directionnel les identifications n’étant partagées qu’avec une seule tierce partie.
•    Pluralisme des Opérateurs et des Technologies.
Un système de gestion des identités  doit supporter de multiples technologies de gestion des identités et de multiples fournisseurs d’identités.
•    Human Integration.
Un système de gestion des identités doit définir un agent humain utilisateur comme un agent accepté par le système établi.
•    Expérience sérieuse en regard de contextes variés.
Un système de gestion des identités doit garantir aux utilisateurs une expérience confirmée et autoriser l’utilisation de diverses technologies et de divers fournisseurs

9. Gestion des Identités, eBusiness B2B , eDesign


La gestion des identités en général a un domaine d’application particulier et important avec le développement croissant de systèmes d’échanges B2B à vocation inter sectorielle voire internationale.
Il en va de même dans le cas des échanges de données techniques (e-Design, conception collaborative  d’objets complexes).
Les aspects suivants devront être étudiés avec une volonté de traiter spécialement des sujets propres au B2B (dont la chaîne d’approvisionnement ou Supply chain) ainsi que ceux de e-Design.

•    Confiance dans les services Trust services.
•    Authentification et validation des services.
•    Services de transformation des formats d’identité et des attributs associés. Il est souvent nécessaire de substituer des informations d’identification et leurs attributs en leur équivalent dans un système local.
•    Conversion d’un système (versions) et entre systèmes
•    Services d’autorisation. Souvent implémentés localement pour des services individuels, les services peuvent traiter les accréditations soumises par le requérant, invoquer la police de sécurité pertinente et déterminer si le requérant est autorisé à effectuer l’action demandée.
Les systèmes de gestion des identités peuvent fournir ces services abstraits à l’aide de différentes configurations certaines étant des Web services explicites, d’autres étant procurées implicitement. A supposer qu’une organisation choisisse d’implémenter sa propre architecture de gestion des identités, elle devrait déterminer quels sont les services dont elle a besoin et les implémenter en conséquence.



Last modified 2007-09-06 01:04 PM
« November 2017 »
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
 
 

Powered by Plone

This site conforms to the following standards: