SP5 Sécurité Lot 5.1 Analyse des besoins et de l existant

Transcription

1 Projet ANR-Verso 2008 UBIS «User centric»: ubiquité et Intégration de Services SP5 Sécurité Lot 5.1 Analyse des besoins et de l existant Auteurs : A. Hammami et N. SIMONI Participants :. Version : V1 Date : 4/ / 39

2 Historique du Document Version Date Modifications V0 3/2010 A. Hammami V1 4/2010 N. Simoni 2 / 39

3 Table des matières 1. INTRODUCTION Contexte NGN Projet UBIS LES COMPOSANTS DE SECURITE L identification L authentification L autorisation... 9 Autorisation d ouverture de session :... 9 Autorisation de type Rôle/Ressource/Service (Application) : Audit : Traçabilité BESOINS ET PROBLEMATIQUES POSES PAR UBIS L hétérogénéité La mobilité User Centric ANALYSE DE L EXISTANT : SINGLE SIGN ON (SSO) Principes et objectifs Les différentes architectures Approche centralisée Approche Fédérative Quelques produits SSO Open ID Kerberos CAS (Central Authentication Service) Open SSO Fonctionnement : CONCLUSION ANNEXE Expérimentation : Fédération avec SAML Simulation de l authentification par le service d identité OpenSSO / 39

4 Table des illustrations Figure 2. Mobilité de la session Figure 3. Principe de propagation de session Figure 4. SSO avec délégation d'authentification Figure 5. SSO Client /Serveur Figure 6. SSO Reverse Proxy Figure 7. La normalisation Figure 8. Principe de la fédération Figure 9. Relation de confiance Figure 10. Processus d'authentification sur Open ID Figure 11. Modèle de fonctionnement du protocole Kerberos Figure 12. Exemple de la réalisation de service CAS Figure 13. Architecture Open SSO Figure 14. Le service d identité IdSvcsClient dans NetBeans IDE Figure 15. Création de groupes y compris deux utilisateurs et une politique Figure 16. Processus d authentification dans le service d identité IdSvcsClient / 39

5 1. Introduction Le sous-projet 5 est consacré à la sécurité et ce premier livrable a pour objectif de faire l analyse des besoins et de l existant. Nous l introduisons en rappelant le contexte NGN ( 1.1) et surtout en décrivant un scénario UBIS (1.2) pour situer les composants de service «sécurité» parmi les autres composant de service UBIS Contexte NGN Actuellement, l environnement NGN (Next Generation Networks) et les services NGS (Next Generation Service) sont en train de devenir un domaine populaire de recherche en télécommunication. Next Generation Network (NGN) est donc une nouvelle architecture de réseaux de communication. Le principe est d utiliser les technologies de transport en mode paquet, réservé jusqu alors pour les données, pour transporter l ensemble des services de télécommunications. De plus, on sépare les interfaces des différentes couches du réseau de communication (transport, commande et applications), pour permettre une évolutivité plus importante du réseau La motivation globale est de faciliter l intégration des usages afin que l utilisateur ait un «service tout compris» et de permettre l intégration des offres de tous les acteurs du marché. L utilisateur d aujourd hui désire avoir l accès à tout type de services sans interruption de session et avec un accès sécurisé. Le contexte qui nous intéresse est celui qui associe la convergence des problématiques de mobilité, d hétérogénéité et des besoins centrés sur l utilisateur 1.2. Projet UBIS Le projet UBIS a pour objectif de faciliter l intégration des usages dans le contexte de mobilité et d ubiquité tel qu il existe aujourd hui et tel qu il se développera demain dans les réseaux du futur. Des limitations importantes inhérentes aux architectures des réseaux actuels imposent de penser autrement la mise à disposition des contenus. En effet, l approche «user centric» impacte la continuité de service, la personnalisation, la QoS de bout en bout, et demande l omniprésence des services sans oublier le transorganisationnel. Pour mettre en œuvre sa vision, le projet UBIS propose un «NGN middleware» omniprésent, dénommé «Serviceware» pour favoriser la fourniture de contenus. Il sera constitué de composants de service mutualisables répartis (SE : Service Element) selon un déploiement intelligent. Prenons pour illustrer le cas d usage suivant : Un utilisateur, Alice, emploie son ordinateur portable dans son bureau, le SE4 qui est en fait un composant applicatif, par exemple l affichage, du côté terminal est en train de fonctionner. Supposant qu elle souhaite également recevoir les s (SE3bis) et SMS (SE3) à travers un même terminal, la première application «User-Centric» est alors construite par une LS0 (Logique de Service) : LS0= SE1 (authentification) + SE2 (autorisation) + SE3bis1+ SE31+SE5 (0) 5 / 39

6 Dans son bureau, le PAN (Personal Area Network) d Alice représente tous les équipements qui lui appartiennent : PANBureau = {laptop, PDA}. Overlay Serviceware SE3bis1 SE31 SE3bis2 SE2-Autho SE3bis3 SE1-Authen SE32 SE4 SP Media Signaling SP: Service provider SE: Server Element AN: Access Network SL: Service Logic NGN Middleware IMS Core SE 1 SE2 Authentication Authorization AN1 IP AN3 SE3bis SE3 SE4 SMS SMS vocal SE5 AN2 SE5 SE6 SE7 affichage SE6 SL0 SL1 SL2 SE6 SE6 SE7 SL3 User mobility Terminal mobility office house Heterogeneous network (access and core network ) One session user centric 18:30h 19:30h Figure 1. Cas d'utilisation UBIS Il est 18H30, Alice sort de son bureau et rentre chez elle en voiture. Durant le trajet, elle ne peut pas utiliser l ordinateur portable, d après son PAN au bureau c est son PDA qui est à l état disponible qu elle va utiliser. Le SE6 est l équivalent de SE5, donc le PDA est choisi pour continuer la session d application d Alice. La session répond à la mobilité de l utilisateur et un changement de SE5 à SE6 peut se faire, une LS1 est l application actuelle : LS1= SE1+SE2+SE3bis1+SE31+SE6 (1) En même temps, un PANVoiture = {PDA} est alors automatiquement construit. Puisqu elle ne peut pas voir ses pendant son trajet en voiture, une modification sur la LS2 est souhaitée par les préférences de l utilisateur : elle souhaite recevoir ses SMS en vocal. La session actuelle inclut automatiquement le SE4 qui est SMSvocal. Puisque pendant le déplacement d Alice, le fournisseur de réseaux mobiles est plus capable d offrir le service à travers la 3G (AN2) grâce à sa couverture plus fine que le WiFi, le SE3bis1 est remplacé automatiquement par SE3bis2. Le réseau support (VPCN) s autogère au niveau du fournisseur des réseaux mobiles pour offrir une meilleure connectivité. Grâce au «NGN Sessionware» [20], la session des services est toujours sans couture avec la LS2 : LS2= SE1+SE2+SE3bis2 +SE31+SE6 (2) Quand Alice arrive chez elle, son PANMaison = {PDA, Ordinateur fixe} indique qu elle a son ordinateur fixe disponible. Grâce à la connexion ADSL (AN3), le fournisseur de ce type de réseau permet l utilisateur d avoir plus de possibilité au niveau d un service dédié sur les différentes plates-formes. L arrivée à la maison notifie également un changement au niveau de la Logique de Service. Alice n a plus besoin du service de SMSVocal car elle peut voir les messages elle-même maintenant. Grâce à son PANMaison, l ordinateur fixe est choisi car il a une meilleure qualité d affichage (SE7). La modification se fait non seulement au niveau du terminal mais aussi au niveau du transport et du 6 / 39

7 service car les anciens composants ne conviennent plus pour la QoS de bout en bout demandé par la session «User Centric». Nous obtenons la session actuelle: LS3= SE1+SE2+ SE3bis3 +SE31+SE7 (3) Dans ce scénario, nous nous apercevons que les composants de sécurité (Authentification et autorisation, ) sont des services de base pour l établissement de VPSN. S il n y a pas un VPSN, on ne peut pas réaliser une continué de service «sans coupure» et avoir une QoS de bout en bout par la composition de SE. 2. Les composants de sécurité En fait, nous allons nous intéresser aux quatre composants qui constituent le socle de la sécurité, à savoir : L identification ( 2.1), l authentification ( 2.2), l autorisation ( 2.3) et l audit ( 2.4) L identification Elle représente le moyen dont dispose la personne pour décliner son identité. Le compte, login ou code_user alloué à l utilisateur est un élément d identification. Une identification s appuie sur une simple déclaration comme la réception ou la lecture d un code d identification (identifiant, n de série, code barre, ). Ce code d identification n est pas supposé secret. C est une donnée publique L authentification C'est la fonction qui consiste à vérifier et à confirmer que l'entité qui s'est identifiée est bien qui elle prétend être. C'est la fonction remplie par l'utilisation d'un mot de passe. Ce sont donc ces deux fonctions que l'on regroupe sous le vocable «Authentification».. On peut distinguer deux types d'authentification : l'authentification d'un tiers et l'authentification de la source des données. L'authentification d'un tiers consiste pour ce dernier à prouver son identité. L'authentification de la source des données sert à prouver que les données reçues viennent bien d'un tel émetteur déclaré. Il existe une différence toute simple entre identification et authentification : c est la preuve. L authentification s appuie sur un élément de preuve comme un secret partagé ou un secret asymétrique. L authentification permet de s assurer avec un niveau de confiance raisonnable de l identité de l utilisateur. Sur la plupart des réseaux, le mécanisme d'authentification utilise une paire code d'identification/mot de passe. Cependant, en raison de la vulnérabilité constamment associée à l'utilisation des mots de passe, il est souvent recommandé de recourir à des mécanismes plus robustes tels que l'authentification par des certificats, des clés publiques ou à travers des centres de distribution des clés. Pour s authentifier, un utilisateur fournit en général au moins 2 éléments : son identifiant qui permet son identification. Un ou plusieurs éléments permettant d assurer l authentification ellemême. Nous retrouvons ainsi ces éléments sous des formes diverses. Voici les plus largement utilisés : Type L identifiant et le mot de passe L identifiant et le mot de passe (One Time Description L identifiant et le mot de passe sont le couple d authentification le plus connu. Simple, robuste, voire même rustique, son plus gros défaut est que le niveau de sécurité dépend directement de la complexité du mot de passe. Des mots de passes simples sont faibles, et des mots de passes trop complexes conduisent les utilisateurs à mettre en œuvre des stratégies de contournement pour les gérer. L OTP permet de sécuriser l utilisation du mot de passe sur le réseau. En effet avec un système OTP, l utilisateur possède un calculateur 7 / 39

8 Password) Les certificats PKI sur carte à puce ou clef USB Clef «Confidentiel Défense» spécialisé qui lui fournit à la demande un mot de passe. Ce mot de passe est valide pendant une durée limitée seulement, et pour une seule utilisation. Cette solution est en général mise en œuvre pour le processus d authentification initiale pour les accès externes via IP/VPN Les certificats X.509 mettent en œuvre une technologie avancée de chiffrement qui permet de chiffrer ou signer des messages sans avoir à partager de secret. L identifiant est un certificat public qui est signé et donc garanti par une autorité de certification reconnue. L utilisateur doit fournir un secret pour pouvoir utiliser les différents éléments cryptographiques : «le code PIN de sa carte ou de sa clef USB». Cette solution est en général mise en œuvre pour le processus d authentification initiale ou pour les connexions aux applications Web ou de messagerie. Il s agit d une déclinaison particulière de l exemple précédent. C est en général une clef multifonctions : stockage de certificat X.509, stockage de données, ressource cryptographique etc L identifiant et le mot de passe sur une carte à puce Le stockage de l identifiant et du mot de passe sur une carte à puce permet de compléter la sécurisation du processus d authentification. Le mot de passe peut ainsi être très complexe et changé régulièrement de manière automatique et aléatoire. Sans la carte, et sans son code PIN, il n y a plus d accès au mot de passe. Cette solution est généralement mise en œuvre pour le processus d authentification initiale Biométrie L identification sans contact L authentification par biométrie s appuie sur la vérification d un élément du corps de l utilisateur (le plus souvent l empreinte digitale). Elle peut s appuyer sur un serveur central, sur le poste ou sur une carte à puce pour stocker les données biométriques de l utilisateur. Cette solution est en général mise en œuvre pour le processus d authentification initiale et/ou pour protéger l accès à des applications très sensibles Le RFID est une technologie qui aujourd hui se déploie dans les projets d Identification/Authentification. Une puce RFID est encastrée dans un badge et porte un numéro d identification. Ce numéro est ensuite associé à un utilisateur dans un système informatique. A la base c est une technologie d identification qui peut, en étant couplée à un mot de passe fourni par l utilisateur par exemple, être utilisé dans des procédures d authentification. Il existe 2 déclinaisons de cette technologie : Le RFID passif ou HID, qui suppose que la carte ne possède pas d alimentation propre. La carte est alimentée lors de la lecture par un champ électromagnétique généré par le lecteur. Ce système est communément utilisé pour le contrôle d accès physique par badge ou le paiement au restaurant d entreprise. La détection d une carte HID se fait à quelque centimètre. Le RFID actif s appuie sur les protocoles de communication RFID mais associe à la carte une alimentation propre. Cette alimentation permet une détection de la carte à plus longue portée (par exemple dès l entrée dans une salle ou un bureau). L intérêt principal du RFID actif est de permettre un constat d absence pour les postes de travail dans des zones accessibles au public Authentification multi-facteurs 8 / 39

9 Un facteur d authentification est un élément que l on sait (code secret), que l on possède (support physique) ou que l on est (biométrie). Dès que plusieurs facteurs d authentification entrent en jeu, nous parlons d authentification multi-facteurs. La multiplication du nombre de facteurs d authentification augmente le niveau de sécurité général, mais pose les problèmes suivants : Le cycle de vie de chaque facteur doit être géré : réinitialisation des mots de passe et codes PIN, distribution des cartes à puce,, L ergonomie d utilisation peut devenir trop contraignante pour les utilisateurs, Les coûts des périphériques (cartes à puce, lecteurs, capteurs biométriques) sont additionnés. De plus, la charge du help-desk va s accroître pour gérer l ensemble de ces méthodes (déblocage des mots de passe et codes PIN, distribution des cartes, formation des utilisateurs à la biométrie, ). Le jeton Une fois l authentification initiale de l utilisateur établie, il faut la transmettre aux applications cibles. L une des techniques utilisée est le «jeton» d authentification. Ce «jeton» est un ensemble de données contenant les éléments prouvant l identité de l utilisateur qui le présente à l application. L application cible doit pouvoir récupérer ce jeton, disponible sur le poste de travail, puis s adresser à un serveur spécialisé qui lui confirmera la validité du jeton ainsi que l identité associée. Les jetons les plus répandus sont aujourd hui les jetons Kerberos et les jetons SAML. Les jetons de type Kerberos : Ces jetons, par exemple, sont mis en œuvre dans les environnements Windows. Les jetons de type SAML (aussi appelée assertion SAML) : Ces jetons sont mis en œuvre dans des architectures SOA/J2EE/Web Services L autorisation Après la phase d authentification des utilisateurs, le système pourra autoriser ces utilisateurs sur le service auquel ils tentent d accéder par le contrôle de leurs droits d accès. Le service d autorisation est chargé d évaluer les droits effectifs sur la base des informations (identité et preuves d authenticité) fournies par le service d authentification. L'autorisation a comme rôle d'empêcher la divulgation non autorisée de l'information ou des données en contrôlant l'accès à celles-ci. Pour cela, il repose sur l'identification et l'authentification des utilisateurs, sans quoi elles sont inefficaces. La plupart des protocoles de sécurité offrent une telle fonction, habituellement sous forme d'une liste de contrôle d'accès (LCA). Les listes LCA énumèrent les personnes, les groupes de personnes ou les processus qui sont autorisés à accéder à certains fichiers ou répertoires. Pour cela et afin d'assurer la confidentialité de l'information, la mise en œuvre des «LCAs» nécessite une gestion attentive et précise. Une méthode pour rendre ce service plus dynamique serait d'utiliser des certificats de rôles ou ce qu'on appelle des certificats d'attribut. Ces derniers ne nécessitent pas une protection physique puisqu'ils sont générés pour une durée de vie très courte. L autorisation est donnée cas par cas à un utilisateur, par service, en fonction des droits associés au rôle (ou par ressource en fonction des privilèges). Les modes d autorisation supportés peuvent être classés de la manière suivante : Autorisation d ouverture de session : Le système de gestion des identités permet l accès ou non (ouverture de session) à l infrastructure d accès à l ensemble de services supportés. L évaluation se fait en fonction de l utilisateur, du périmètre temporel géographique, et de la typologie de sa tentative d accès. Des paramètres des connexions (timer de déconnexion après inactivité, durée max de connexion) spécifiques seront contrôlés en fonction de l utilisateur. Autorisation de type Rôle/Ressource/Service (Application) : Autorisation de type simple qui permet l accès ou non au service (en fonction du rôle de l utilisateur, du périmètre temporel, périmètre géographique et du mode d authentification de sa tentative d accès). Les ressources du service cible sont modélisées dans le référentiel et c est le système de gestion des identités qui permet ou non l accès à ces ressources (filtrage des 9 / 39

10 URLs, des pages web statiques ou dynamiques). Dans le cas d application capables d appliquer le modèle RBAC (comme les rôles J2EE) le système de gestion des identités positionne les rôles et les droits effectifs sont évalués par l application elle même. Figure 2. Mode d'autorisation Rôle/Ressource/Service Autorisation externe Les systèmes externes partenaires peuvent autoriser l accès à leurs ressources tout en déléguant au SI d entreprise l authentification de la personne et le processus de détermination du rôle actif de la session en cours. Le système de l entreprise prend en charge l authentification de la personne et la recherche de rôle actif de service demandée. Ce rôle et l identité sont communiqués au système externe par un jeton via un canal sécurisé Les modalités et les mécanismes précis peuvent varier en fonction du système du partenaire. Ces mécanismes feront souvent appel aux solutions de fédération des identités 2.4. Audit : Traçabilité La traçabilité est la fonction de sécurité qui mémorise l origine d un message, d un événement, d une information ou d une donnée. Elle permet par exemple, de retrouver l adresse à partir de laquelle ces données ont été envoyées. Elle consiste à enregistrer des informations relatives aux contrôles d accès. Ces principes sont résumés sous le terme anglo-saxon d infrastructure AAA comme «Authentication, Authorization, Accounting». 10 / 39

11 Figure 3. Gestion des Accès Pour assurer la sécurisation du SI, une politique rigoureuse de gestion des accès doit donc être mise en place. La traçabilité est le troisième volet de contrôle d accès. Sans une journalisation des événements, ça sera impossible de faire le moindre audit et de localiser et quantifier les tentatives d intrusion. Pour éviter que les informations pertinentes soit noyées sous ce flot continu, le RSSI apportera un soin particulier au réglage des outils d audit. Concernant la gestion des accès, donnons quelques exemples de paramètres judicieux à collecter : Les échecs d ouvertures de session (nombre élevé de tentatives de connections de la part d un user peut indiquer une usurpation de son compte par une personne malveillante) Les heures d ouvertures et de fermeture de sessions Les échecs d accès aux services (de même, un nombre de tentative accès à un même service peut révéler des essais de récupération des données) L audit est une mission d évaluation de conformité par rapport a un ensemble de règles de sécurité, norme ou à une politique de sécurité précise ; Si aucun référentiel n est défini au cours du projet, la mission d audit n a que peu de sens. Les objectifs de l audit sont multiples : Valider des mesures de sécurité mises en œuvre ; Valider des processus d alertes et de réaction face à des attaques, des incidents Réagir à une attaque Se faire une bonne idée du niveau de sécurité du SI Tester la mise en place effective de la politique de sécurité de système d information Tester un nouvel équipement Evaluer l'évolution de la sécurité (implique un audit périodique) L audit sert, avant tout à valider l ensemble des mesures sécuritaires définies. Il ne doit pas s arrêter au niveau système ou réseau. Il doit couvrir aussi les aspects applicatifs et organisationnels. Cette évaluation doit se baser sur une grille d analyse où chaque caractéristique à valider doit être aisément qualifiable (mesurable) et contrôlable. L analyse doit être réalisée de manière pragmatique avec des pondérations sur les différents critères dépendants du projet. 11 / 39

12 En effet, la mission d audit dresse un bilan qui consiste à mesurer le niveau d application de règles sur le système par rapport aux règles qui devraient être effectivement appliquées. Il convient de noter que les études basées sur les interviews introduisent un biais dans les résultats puisqu elles reposent sur les intentions ou la compréhension des personnes auditées sur certaines problématiques. Les audits techniques s intéressent uniquement aux problématiques de configurations des équipements ou des applications, les aspects procédures et organisationnels sont rarement prise en compte ; Enfin, le niveau de sécurité d un système est dynamique : Il peut fortement évoluer en fonction d une simple mise à jour de système d exploitation ou d un logiciel, par exemple. Il en ressort qu un résultat d audit peut être contredit par le moindre changement technique ou organisationnel. Pour autant, l audit est le seul moyen pour valider les aspects sécuritaires d un système et des préconisations de modifications des architectures, des applications été des procédures organisationnelles permettant d améliorer le niveau global de sécurité du système. Dans tous les cas, il a pour but de vérifier la sécurité. Dans le cycle de sécurisation, la vérification intervient après la réalisation d'une action. Par exemple, lors de la mise en place d'un nouveau composant dans le SI, il est bon de tester sa sécurité après avoir intégré le composant dans un environnement de test, et avant sa mise en œuvre effective. Le résultat est le rapport d'audit qui contient la liste exhaustive des vulnérabilités recensées par l'auditeur sur le système analysé. Il contient également une liste de recommandations permettant de supprimer les vulnérabilités trouvées. L'audit ne doit pas être confondu avec l'analyse de risques. Il ne permet que de trouver les vulnérabilités, mais pas de déterminer si celles-ci sont tolérables. Au contraire, l'analyse de risque permet de dire quels risques sont pris en compte, ou acceptés pour le SI. L'auditeur (le prestataire) dresse donc des recommandations, que l'audité (le client) suivra, ou ne suivra pas. Le client déterminera si il suivra les recommandations ou non, en se référant à la politique de sécurité. Les tests d intrusion Les tests d'intrusion sont une pratique d'audit technique. On peut diviser les tests d'intrusion en trois catégories principales : les tests boîte blanche, les tests boîte grise et les tests dits boîte noire. Un test boîte noire signifie que la personne effectuant le test se situe dans des conditions réelles d'une intrusion : le test est effectué de l'extérieur, et l'auditeur dispose d'un minimum d'informations sur le système d'information. Ce genre de tests débute donc par l'identification de la cible : Collecte d'informations publiques : pages web, informations sur les employés, entreprise ayant un lien de confiance avec la cible. Identification des points de présence sur internet. Ecoute du réseau. Lors de la réalisation de tests boîte grise, l'auditeur dispose de quelques informations concernant le système audité. En général, on lui fournit un compte utilisateur. Ceci lui permet de se placer dans la peau d'un "utilisateur normal". Les tests boîte blanche débutent avec toutes ces informations à disposition. Ensuite commence la recherche des vulnérabilités, à l'aide de différents tests techniques, comme par exemple la recherche des ports ouverts, la version des applications... La dernière phase est l'exploitation des vulnérabilités. Des effets indésirables pouvant survenir (Déni de service par exemple), le côté pratique de cette phase n'est pas systématique. Elle consiste à déterminer les moyens à mettre en œuvre pour compromettre le système à l'aide des vulnérabilités découvertes. Selon les moyens à 12 / 39

13 mettre en œuvre, le client pourra décider que le risque associé à la vulnérabilité décelée est négligeable (probabilité d'exploitation faible) ou au contraire à prendre en compte. Pour prouver la faisabilité de l'exploitation, les auditeurs créent des programmes qui exploitent la vulnérabilité, appelés exploits. Les relevés de configuration Il s'agit d'analyser, profondément, les composants du système d'information. Les configurations sont inspectées dans les moindres détails. Suite à cette observation, la liste des vulnérabilités est dégagée en comparant le relevé à des configurations réputées sécurisées, et à des ensembles de failles connues. Tout peut être inspecté, allant de l'architecture du SI aux applications, en passant par les hôtes (clients et serveurs). Par exemple sur un serveur, on va analyser : le chargeur de démarrage, les mécanismes d'authentification (robustesse des mots de passe, utilisation d'authentification forte...), le système de fichiers (droits d'accès, utilisation de chiffrement...), les services la journalisation, la configuration réseau,... L audit de code Il existe des bases de vulnérabilités très fiables pour les applications répandues. Néanmoins, pour des applications moins utilisées, ou codées par l'entreprise elle-même, il peut être nécessaire d'analyser leur sécurité. Si les sources de l'application sont disponibles, il faut lire et comprendre le code source, pour déceler les problèmes qui peuvent exister. Notamment, les débordements de tampon (buffer over flow), les bugs de format, ou pour une application web, les vulnérabilités menant à des injections SQL... L'audit de code est une pratique très fastidieuse et longue. De plus, elle ne permet pas généralement, de dresser une liste exhaustive des vulnérabilités du code en raison de la complexité, Fuzzing Pour les applications boite noire, où le code n'est pas disponible, il existe un audit à l'analyse de code, qui est le fuzzing. Cette technique consiste à analyser le comportement d'une application en injectant en entrée des données plus ou moins aléatoires, avec des valeurs limites. Contrairement à l'audit de code qui est une analyse structurelle, le fuzzing est une analyse comportementale d'une application. 13 / 39

14 3. Besoins et problématiques posés par UBIS Comme nous l avons analysé dans les autres sous-projets, UBIS se trouve à l intersection des problèmes d hétérogénéité ( 3.1), de mobilité ( 3.2) et de l approche User Centric ( 3.3). Nous voulons lever les verrous posés par la simultanéité de ces trois champs au niveau de la sécurité L hétérogénéité Le principal problème est l hétérogénéité de toutes ces ressources qui vont devoir collaborer pour fournir un service global. Or ce que nous voulons c est une QoS de bout en bout, à laquelle participe chaque composant. C est pourquoi, la vision UBIS est d avoir une perception homogène de toutes ces ressources à travers un modèle de QoS qui représente le comportement et les caractéristiques du service demandé. Le modèle s appliquera à tout objet du système, que cela soit un équipement, un réseau d accès ou un composant de service. En fait, le modèle de QoS utilisé dans UBIS est une réponse à l hétérogénéité du contexte NGN/NGS. Du point de vue de la sécurité, c est donc au niveau du suivi de cette QoS et de l analyse des dysfonctionnements de comportement qu il faudra repérer les impacts de ce nouveau contexte. Soit P1 cette première problématique : Audit de la QoS 3.2. La mobilité Pouvoir se déplacer au gré de ses besoins ou de ses envies est aujourd'hui tellement simple, que la location physique n est plus la contrainte majeure pour les utilisateurs modernes. Grâce à une grande couverture et à la diversité des technologies sur les offres d accès, les utilisateurs peuvent avoir leurs services n importe où. Mais dans le contexte de NGN où l hétérogénéité est omniprésente le maintien de la communication et du service d un utilisateur qui se déplace est de plus en plus complexe. Les communications personnelles induisent des mobilités essentiellement d ordre spatial comme la «mobilité du terminal», la «mobilité de l utilisateur» et la «mobilité du réseau». La «mobilité de terminal» implique la continuité de la connexion. Lorsque l utilisateur passe d un terminal à un autre, cela relève de la «mobilité de l utilisateur», nous devons alors résoudre les adaptations pour préserver la personnalisation. La «mobilité du réseau» concerne le déplacement de l infrastructure du support de transport. Ces trois types de mobilité sont relatifs à des aspects de connectivité. On peut dire que la mobilité du terminal ne pose pas trop de problème du point de vue de la sécurité car l utilisateur est confondu avec son terminal, il est identifié à travers ce terminal. Il n en est pas de même avec la mobilité de l utilisateur. En effet l utilisateur change de terminal mais pas de service! Qu en est il de son authentification? De la transparence de sa mobilité? Soit P2 cette deuxième problématique : mobilité de l utilisateur (changement de terminal). Dans le monde réel, il faut également considérer les aspects de service. Avec l évolution de fourniture de service, un même service demandé par l utilisateur peut être offert par plusieurs fournisseurs et supporté par différentes plates-formes de service. Quand l utilisateur se déplace, comment fait-il son choix pour avoir la meilleure adéquation à ses besoins? Nous avons dénommé ce quatrième type de mobilité : la «mobilité de service». Cette «mobilité de service» induit en fait une autre mobilité d ordre temporel que nous avons dénommé «mobilité de session». 14 / 39

15 Figure 1. Mobilité de la session Prenons le cas d une vidéo à la demande(vod). Le service (simplifié) est rendu avec les composants de service (voir la figure) : agent client (SE4), transcodeur (SE3), cache (SE2), diffuseur(se1). La première route(1) est trouvée, en fonction de la logique de service, des capacités des composants de service et des capacités des bus de services (supportés par un réseau d acheminement). L utilisateur se déplace (mobilité du terminal), donc nouveau point d accès, la route(2) est modifiée. Si la QOS n est plus respectée, une route (3) avec des composants de services fonctionnellement équivalents sera empruntée. Nous venons de décrire la mobilité de session. L automatisation des processus favorisera la continuité de service. Mais cette mobilité n a-t-elle aussi un impact sur la sécurité? L utilisateur doit-il s authentifier à chaque service sollicité? Comment l autorisation peut elle être validée pour chaque service demandé, mais de façon transparente vis-à-vis de l utilisateur? Et si nous faisons notre «marché» auprès de différents fournisseurs, comment assurer la continuité de la sécurité? En effet, pour assurer une continuité de service et de sécurité, avec la chaîne des mobilités spatiales, le système doit gérer dynamiquement la session de l utilisateur et son unicité de bout en bout («seamless, sans couture») en temps réel. En plus de la continuité de service, on doit garantir la sécurité d accès aux services afin d avoir une session sécurisée. Ce qui nous amène à étudier l impact de la mobilité de session sur la sécurité. Soit P3 la problématique du transorganisationnel (plusieurs fournisseurs de service). Soit P4 la problématique de l authentification unique pour tous les composants de services sollicités. Soit P5 la problématique de l autorisation quand le service global repose sur une composition d élément de service. Soit P6 la problématique de la session mobile et dynamique dans un contexte où tout est service composable User Centric L utilisateur d aujourd hui, et plus encore celui de demain, est nomade. Il réclame l accès à n importe quel service sans aucune barrière technique, temporelle, économique ou géographique, afin d obtenir toujours la meilleure session, en adéquation avec son contexte et/ou ses préférences. Ces besoins «user-centric» introduisent une nouvelle perception du paysage des télécommunications. L industrie de télécommunications doit proposer des nouvelles solutions, afin 15 / 39

16 de répondre à ces besoins de : «anywhere, anytime, anyhow, every services, everyone», en assurant la continuité de service sans coupure et sans couture tout en étant sécurisé. Soit P7 la problématique de la spécification des mécanismes de sécurité. Eux mêmes deviennent des services que l on peut composer selon ses besoins de lieu et de temps (spatial et temporel) et ses préférences. Avant d apporter une réponse «UBIS» à toutes ces questions, regardons dans le chapitre suivant, ce que couvre l existant et quels sont les mécanismes mis en œuvre. 4. Analyse de l existant : Single Sign On (SSO) A la question, «L utilisateur peut-il s authentifier une seule fois pour l ensemble des services sollicités lors de sa session?» une réponse semble existée en SSO. Pour bien comprendre la pertinence et la couverture de cette technique, nous allons étudier le principe ( 4.1), les structures d ensemble, c'est-à-dire les architectures possibles ( 4.2) et les différents produits proposés ( 4.3) Principes et objectifs Le Single Sign-On (SSO) est une technique qui consiste à soumettre l utilisateur à une procédure d authentification unique par rapport aux différents services accessibles, applications ou fonctions protégées du système. Mais SSO peut aussi prononcer les autorisations ou interdictions d accès de l utilisateur à l ensemble des services, suivre l activité et tracer les opérations effectuées. Ce service unifié concerne : En premier lieu l identification et l authentification de l utilisateur par rapport aux services du système d information ; Dans un grand nombre de cas, le contrôle d accès à chaque service, sous forme d une autorisation dont la validité est limitée à une session de travail Dans certaines implémentations, le contrôle d accès logique aux objets et aux fonctions des services accédés La gestion des éléments d identification et d authentification, des autorisations et s il y a eu lieu des droits d accès, qui devient alors centralisée ; L enregistrement des traces d accès et leur exploitation Le service de SSO est simplificateur pour l utilisateur qui gagne en temps d accès et en gestion des éléments d identification et d authentification, puisqu il ne gère plus un couple identifiant /authentifiant par application cible mais, un seul couple, qu il joue une seule fois pour accéder à tous les services. Le SSO est encore plus intéressant pour l administration de la sécurité car il permet de centraliser les services de sécurité d identification, d authentification et d autorisation et de conserver si nécessaire une partie de la gestion des droits au niveau des applications, afin de prendre en compte des besoins particuliers de ces applications ou des difficultés de modification de mécanismes de contrôle d accès logique existants. Le SSO ne réalise aucune fonction de sécurité supplémentaire par rapport à une architecture classique car il ne fait que substituer des mécanismes. 16 / 39

17 Pourtant le gain apporté en sécurité est important grâce à l acceptation du dispositif par les utilisateurs et à la simplification de la gestion des accès et de l exploitation des traces. La mise en place d un procédé d authentification forte est plus facile dans une solution SSO que dans chacune des applications. Plusieurs autres raisons militent en faveur d un recours plus fréquent au SSO : La limitation du nombre d éléments secrets à gérer par utilisateur ; La réduction des risques de capture d éléments secrets sur les réseaux empruntés ; L impact sur la cohérence des services du système d information et celle des moyens de sécurité utilisés ; La possibilité de mettre plus facilement en place une politique générale de gestion des habilitations, c'est-à-dire de gestion des privilèges des utilisateurs par leurs droits d accès ; La création des points d accès sécurisés et centralisés, en termes de réseaux mais aussi de services, qui constituent des points de passages plus faciles à contrôler. Le principe de SSO consiste à mettre en œuvre un mécanisme qui propage les sessions d une application A à une application B lorsque l utilisateur désire accéder aux applications. Ce mécanisme est mis en œuvre grâce à des solutions d architectures spécifiques basées sur des moteurs SSO. Figure 2. Principe de propagation de session Le fonctionnement du SSO est basé sur la gestion par le moteur de SSO d une session utilisateur globale au système d information. Les applications qui bénéficient du service de SSO interrogent ce tiers pour savoir si l utilisateur qui tente d accéder est déjà authentifié de manière globale. Si c est le cas, elles ne lui demandent plus de se ré-authentifier. En plus de la propagation des sessions, le moteur de SSO prend en charge l authentification initiale des utilisateurs qui est appelé l authentification primaire pour désigner l authentification prise en charge par le moteur de SSO. L authentification applicative est appelée authentification secondaire car l authentification par SSO a déjà la main. 17 / 39

18 4.2. Les différentes architectures Figure 3. SSO avec délégation d'authentification Les approches possibles sont la centralisée ( 4.2.1) et la fédératrice ( 4.2.2) qui prend en compte le fait que nous pouvons avoir différents fournisseurs Approche centralisée Le principe est de disposer d'une base de données globale et de centralisée tous les utilisateurs au travers d un annuaire. Elle unifie la gestion des authentifications et des autorisations. Cela permet également de centraliser la gestion de la politique de sécurité SSO client/serveur Le principe du SSO client/serveur repose sur le moteur de SSO qui centralise les authentifications, les habilitations et les traces des accès utilisateurs. Pour cela, il est nécessaire de déployer sur les applications des agents SSO, sortes de plug-ins permettant de ces dernières de dialoguer avec le moteur de SSO. Les agents permettent de rerouter l utilisateur vers le moteur de SSO si celui-ci n est pas authentifié d une manière globale, puis de collecter ses habilitations pour le compte de l application. Si l utilisateur est authentifié auprès du moteur de SSO, l agent se contente de collecter ses habilitations pour les transmettre à l application. 18 / 39

19 Figure 4. SSO Client /Serveur Le moteur de SSO utilise un référentiel pour stocker l annuaire des identifiants primaire et les habilitations correspondantes. Ce référentiel peut être un annuaire LDAP ou une base de données relationnelles. Le SSO client/ serveur est dans les faits l approche la plus courante dans le cadre d applications hébergés sur un réseau interne ou intranet. Les avantages de cette architecture, sont les suivants : Elle permet une grande souplesse dans la gestion des habilitations, centralisées par le moteur de SSO Son intégration est rapide car basée sur les plug-ins ne nécessitant pas de développement Les tickets de sécurité sont chiffrés, signés et offrent un haut niveau de sécurité Le moteur de SSO n est sollicité qu au moment des sessions applicatives, il n est pas surchargé de requêtes. En revanche, elle est intrusive au niveau des applications, ces dernières doivent supprimer leur mode d authentification préexistant et intégrer les agents SSO. Enfin, les serveurs applicatifs sont accédés directement par les utilisateurs sans passer par aucune passerelle de sécurité SSO reverse proxy Dans cette architecture, le moteur SSO constitue une passerelle de sécurité qui permet de filtrer les flux accédants au système d information. Ainsi les applications ne sont pas accédées directement et leur emplacement réel peut être masqué grâce à des méthodes d URL rewriting. L URL rewriting consiste à réécrire l adresse de l application à la manière d un proxy. Le SSO reverse proxy s appuie sur une mise en cache des identifiants/mots de passe secondaires dans une base de correspondance. Ainsi, à chaque identifiant primaire, il associe une série d identifiants/mots de passe secondaires. Ces dernières informations sont chiffrées au travers d un algorithme à clef secrète. 19 / 39

20 Après avoir mené à bien l authentification primaire, le moteur de SSO présente à l utilisateur une page HTML contenant la liste des applications auxquelles il est habilité à accéder, puis lorsque ce dernier clique sur le lien correspondant à une application le moteur remplit à sa place le formulaire d authentification applicative et valide. Les données d authentification secondaire sont envoyées à l application cible en HTTPS. Enfin, le moteur renvoie à l utilisateur les pages des applications à travers l URL rewriting. Figure 5. SSO Reverse Proxy Ce mode n est pas intrusif puisque aucune modification n est nécessaire sur les applications. En revanche, il ne permet pas une grande finesse dans la gestion des habilitations. Par ailleurs, la duplication des identifiants/mots de passe secondaires pose des problèmes de synchronisation et de sécurité (même s ils sont chiffrés). Enfin le moteur de SSO est fortement sollicité, puisqu il prend en charge toutes les requêtes utilisateurs. Il doit donc être dimensionné pour bien supporter les montées en charge Approche Fédérative Dans cette approche, le système Liberty Alliance est le principal exemple, 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. La fédération consiste à faire communiquer plusieurs systèmes de gestion des identités, afin d éviter de constituer une solution centralisée, tout en assurant des services d authentification unique, d échanges d attributs et de droits utilisateurs entre les différents sites auxquels ils ont accès. Cette approche a été développée 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é. La fédération d'identité est un concept né du rapprochement de besoins commerciaux et de technologies permettant d'élaborer des échanges entre réseaux et domaines différents de façon sécurisée et fiable. Nous allons recenser les normes et protocoles en vigueur ( ) et montrer un schéma de principe ( ). 20 / 39

21 Normes et protocoles de fédération A l heure actuelle les solutions sont concentrées sur les technologies web mais des travaux sont en cours pour étendre leurs champs d application. Le digramme suivant présente la multiplicité des différentes initiatives et la convergence de tous ces travaux vers la normalisation autour de SAML 2.0. Figure 6. La normalisation SAML SAML (Security Assertion Markup Language) a été normalisé par l'oasis, conçu pour l'échange sécurisé d'informations d'identités. Il s agit d un ensemble de spécifications qui définit comment des services peuvent échanger des assertions de sécurité (authentification, autorisation, attributs), indépendamment des technologies utilisées par chacun de ces services. SAML s appuie sur des standards préexistants (XML, SSL, etc.) et a été conçu avec suffisamment d abstraction pour rendre interopérables des systèmes hétérogènes et s articuler au mieux avec d autres mécanismes de gestion d identités. SAML définit deux briques essentielles pour sécuriser les échanges Le SP (Service Provider), fournisseur de service, protège l'accès aux applications. Il refuse tout accès sans authentification préalable et redirige l'utilisateur non authentifié vers son fournisseur d'identité. IdP (Identity Provider), fournisseur d'identité, s'occupe d'authentifier l'utilisateur ainsi que de récupérer des informations additionnelles associées à son identité. SAML est constitué de différents protocoles, qui correspondent aux différents usages gérés par ce standard. Un protocole SAML décrit de façon abstraite la manière avec laquelle deux entités interagissent, généralement sous la forme d une séquence de requêtes et de réponses. Un «protocol binding» est la traduction d un tel protocole abstrait en un protocole de communication implémenté informatiquement, par exemple sous la forme de services Web SOAP (Simple Object Access Protocol protocole RPC : Remote Procedure Call). SAML est très abstrait pour assurer l interopérabilité entre les systèmes. Il existe différents «profils SAML» qui restreignent, ou étendent, la variabilité d un protocole. SAML ne répond pas à toutes les questions de la gestion des identités. Il ne définit pas, par exemple, de protocole SSO ou de sémantique d attributs standard. Il s appuie sur des standards pré-existants (XML, TLS, etc.) et a été conçu avec suffisamment d abstraction pour rendre interopérable des systèmes hétérogènes. SAML est déjà implémenté dans de nombreux produits, et est utilisé par trois autres normes, Liberty Alliance, Shibboleth et WS-Federation. 21 / 39

22 Liberty Alliance [LA] est une série de spécifications définies par le consortium éponyme fondé en 2001 et qui regroupe un grand nombre d acteurs issus d industries diverses : informatique, télécom, gouvernement, etc. Liberty Alliance repose sur SAML et l enrichit par de nouvelles fonctions. Liberty Alliance est découpé en différentes parties, les frameworks. Le premier, IDFF 1.2 (Identity Federation Framework), définit la fédération de comptes, la délégation d authentification, ainsi que la propagation de fin de session. Il permet essentiellement de réaliser un SSO étendu, par exemple entre un organisme et ses partenaires offrant des services aux utilisateurs de cet organisme. ID-WSF (Identity-based Web Services Framework) permet la propagation d attributs utilisateurs, la recherche de services d identité, etc. De nombreux produits implémentent des parties plus ou moins grandes des spécifications Liberty Alliance, et des déploiements significatifs ont déjà eu lieu, concernant des millions d utilisateurs [LA adoption]. Shibboleth [Shib] est une spécification et un produit open source développés par Internet2, un consortium d universités américaines. Il s appuie sur SAML. Shibboleth 1.x et IDFF 1.2 qui ont convergé pour constituer SAML 2.0. Shibboleth est très utilisé dans les communautés de l enseignement supérieur américaines et européennes. WS-Federation est la spécification de Microsoft pour la fédération d identités. Elle reprend SAML pour le format des assertions, mais pas pour les protocoles d échange. Elle fait partie des spécifications WS-* qui traitent de la sécurisation des services web. Plusieurs produits implémentant Liberty Alliance ont annoncé leur compatibilité avec WS-Federation. ADFS (Active Directory Service) enrichit Active Directory pour lui apporter des fonctionnalités de fédération d identités Les concepts de la fédération La fédération vise principalement le partage d'information d'identification entre systèmes et platesformes d'identification hétérogènes. Un système basé sur une identité fédérée permets aux utilisateurs de se connecter en utilisant un seul identifiant et mot de passe (ou un autre moyen d'authentification) au lieu d'en avoir un pour chaque service. Les approches de centralisation et de fédération sont parfaitement complémentaires : la gestion des identités centralisée est une première étape de rationalisation des informations au sein de l entreprise/organisme la fédération des identités répond aux besoins d intégration des services d identités entre différentes organisations (métiers, partenaires, fournisseurs, clients, etc.). Le principal objectif de la fédération d identité est de faciliter les échanges entre partenaires sans avoir à dupliquer les référentiels utilisateurs et donc en faisant de la délégation de gestion des utilisateurs sur la base de confiance 22 / 39

23 Figure 7. Principe de la fédération Lorsqu un utilisateur A accède à un service A1, l authentification est basée sur le fournisseur d identité A interne. Lorsqu un utilisateur B externe à l entreprise A accède à un service A2 l authentification est basée sur le fournisseur d identité B de son entreprise Lorsqu un utilisateur B accède à un service A2 externe à son entreprise et un service B1 interne à son entreprise, les deux services s appuient sur le fournisseur d identité de son entreprise. L utilisateur B bénéficie ainsi de Single Sign On entre deux services émanant de deux structures différentes Les solutions de fédération d identités s appuient sur quelques concepts tels que : L identité fédérée C est un ensemble d attributs fédérés, c est-à-dire d informations relatives à l identité provenant de différentes sources et pouvant être mises en commun. Elle apporte des gains fonctionnels : - pour l utilisateur : la possibilité de partager son identité entre les différents systèmes - pour l entreprise : la possibilité de s associer avec d autres partenaires au sein d une fédération, afin que les identités d un domaine puissent donner accès aux services d un autre domaine sans être obligé de mettre en œuvre une gestion lourde (et souvent pratiquement impossible) de gestion des identités des utilisateurs de chaque partenaire. La répartition des responsabilités La propagation d identités et la fédération inter partenaires s appuient sur une organisation tri partite : 23 / 39

24 - Un fournisseur d identité (Identity Provider ou IDP) : chargé d authentifier l utilisateur et de gérer son identité (enregistrement, provisioning, gestion de comptes et de mots de passe) - Un fournisseur de services (Service Provider ou SP) : chargé de lui fournir des services en fonction de ses habilitations sur la base des informations fournies par le fournisseur d identités à qui il fait confiance - Un utilisateur Confiance entre les partenaires. Tous les mécanismes de fédération d identités se basent sur le principe fondamental d existence d une relation de confiance entre les partenaires qui ont décidé de collaborer. Il est primordial que ces relations de confiance soient établies et gérés sur trois niveaux : - Métier où seront définis les services concernés par la fédération, les engagements de qualité de service et les conditions de mise en œuvre. En particulier le fournisseur de service pourra exiger une garantie de fiabilité et de niveau d authentification de la part du fournisseur d identité - Légal où seront formalisées et contractualisées les exigences métier et définis les moyens et les procédures de résolution de cas de litiges - Technique où seront définis les moyens techniques de mise en œuvre des liens sécurisés entre les sites, les formats de jetons de sécurité et les processus de validation de l authenticité des informations échangées Figure 8. Relation de confiance 4.3. Quelques produits SSO Nous ne pouvons être exhaustif, nous avons retenu Open ID ( 4.3.1), Kerberos ( 4.3.2), CAS ( 4.3.3) et Open SSO ( 4.3.4) Open ID OpenID est un système d authentification décentralisé qui permet l authentification unique, ainsi que le partage d attributs. Chaque utilisateur est identifié par une URI, qu il acquiert auprès de son fournisseur d identité OpenID. Le modèle OpenID se base sur des liens de confiance préalablement établis entre les fournisseurs de services (sites web utilisant OpenID) et les 24 / 39

25 fournisseurs d identité (OpenID providers). En conséquence, il permet à un utilisateur de s authentifier auprès de plusieurs sites (devant prendre en charge cette technologie) sans avoir à enregistrer séparément une identité de ces sites mais en utilisant à chaque fois une identité OpenID unique. Figure 9. Processus d'authentification sur Open ID Dans le processus d authentification sur OpenID (Voire Figure ci-dessus), toutes les requêtes et toutes les réponses utilisent les méthodes GET/POST de HTTP ou une redirection de HTTP. Globalement, il y a septs étapes dans ce processus : Site Web (Relying Party ) demande identité OpenID de l utilisateur A la suite de demande, l utilisateur envoie son identité OpenID au site web. La forme d identité est soit URI/URL via http ou https (par exemple : soit XRI (par exemple xri://authority/path? query#fragment). Normalisation Du fait que l identité offerte est en forme imprévisible, un processus de normalisation est nécessaire qui permet au site web d obtenir une identité URL standard. Découverte Dans cette étape, le site web recherche les informations nécessaires pour initialisation de requête. Le protocole d analyse utilisé et le document acquis dépendent d identité normalisée dans l étape précédente. Une association entre le site et le fournisseur OpenID (Optionnel) C est l établissement d un tunnel sécurisé à partir d une association entre le site et le fournisseur OpenID afin de vérifier les messages suivantes et de réduire à la fois la communication d aller et retour. Simplement, on utilise un algorithme Diffie-Hellman pour générer une clé partagé qui signe les messages. Cette association est optionnelle mais recommandée pour la raison de sécurité. Requête d authentification par le site web La requête d authentification par le site web est redirigée vers le fournisseur OpenID. Cette redirection permet au fournisseur OpenID de lire le cookie de navigateur d utilisateur et de ne révéler aucune information au site web. Dans cette étape et l étape 7, le protocole PAPE (OpenID Provider Authentication Policy Extension 1.0) est utilisé. Cette extension du protocole 25 / 39

26 d authentification fournit un mécanisme par lequel le site web peut demander les politiques d authentification notamment être appliquée par le fournisseur lorsqu il authentifie un utilisateur. Cette extension fournit également un mécanisme par lequel le fournisseur OpenID informe au site web quel politique d authentification est utilisé. Action d authentification entre utilisateur et fournisseur OpenID Une authentification réalisée entre utilisateur et fournisseur OpenID à partir des politiques demandés dans la requête. En théorie, le fournisseur supporte tout type d authentification. Réponse d authentification par le fournisseur OpenID À la suite d authentification, le fournisseur OpenID donne une réponse positive ou négative au site web dans lequel indiquent les politiques d authentification utilisé Kerberos Kerberos est un protocole d'authentification réseau créé au Massachusetts Institute of Technology (MIT). Kerberos est différent des autres méthodes d'authentification basées sur la combinaison nom d'utilisateur/mot de passe, au lieu d'authentifier chaque utilisateur auprès de chaque service réseau, il utilise un cryptage symétrique et un tiers de confiance connu sous le nom de Centre de distribution de tickets (KDC : Key Distribution Center) afin d'authentifier les utilisateurs auprès d'un ensemble de services réseau. Il y a deux types de tickets dans Kerberos : TGT (Ticket Grating Ticket) : le ticket d autorisation qui est donné à l utilisateur à la suite d avoir une authentification réussie. Ce TGT expire après un certain laps de temps (généralement dix heures) et il est stocké dans le cache de certificat d identité de l ordinateur client. TGS (Ticket Grating Service) : le ticket de service spécifique qui permet à l utilisateur d accéder au service qu il demande. Dans ce ticket, il y a l information de service ainsi que celle d utilisateur (@IP, etc.).le modèle de fonctionnement du protocole est montré dans la Figure 19. Quand l utilisateur veut visiter le service1, il va envoyer une requête pour demander SGT1. Après une authentification réussie et une autorisation réussie d après KDC, l utilisateur obtient un TGT et un SGT1. Si l utilisateur veut visiter un autre service 2, il ne fait pas une réauthentification si TGT est encore valable. Cela permet de réaliser une authentification unique. Figure 10. Modèle de fonctionnement du protocole Kerberos 26 / 39

27 Du fait que Kerberos utilise un système de tickets au lieu de mots de passe en texte clair, cela renforce la sécurité du système et empêche que des personnes non autorisées interceptent les mots de passe des utilisateurs CAS (Central Authentication Service) CAS est un système d'authentification unique (SSO) pour le web développé par l'université Yale, partenaire majeur dans le développement de uportal. Ce logiciel est implanté dans plusieurs universités et organismes dans le monde. Le principe de CAS combine la notion de ticket dans Kerberos et identité sous forme URL dans OpenID. Pour réaliser le service CAS, une collaboration entre un serveur central d authentification (CAS-Server) et un client CAS (CAS-Client) engagé dans de différents systèmes de service est nécessaire. Dans le CAS1.0, le CAS-Server offrit trois interfaces pour l authentification (URL de web service) : URL de connexion du client: comme URL de validation du client : comme URL de déconnexion du client : comme À la côté de CAS-Client, CAS fournit toute gamme de support de la langue, celui utilisé pour la langue java est un paquet casclient.jar. La version actuelle de package casclient.jar est 2.1.1, dans lequel il y a trois formes de validation : Filter utilisé pour Java Servlets : edu.yale.its.tp.cas.client.filter.casfilte CAS Tag Library utilisé pour le page JSP Java API Object : ServiceTicketValidator / ProxyTicketValidator La figure ci-dessous nous montre un exemple de réalisation de service CAS1.0 : Comment un client accède au web service BIZ d après une authentification de serveur CAS. Figure 11. Exemple de la réalisation de service CAS 1.0 (1) L utilisateur accède au page principal de service BIZ : 27 / 39

28 Le CASFilter déployé dans le système BIZ vérifie l enregistrement de l utilisateur. S il est déjà enregistré, le service BIZ autorise l utilisateur d accéder au service. Si non, il redirige l utilisateur vers le page de connexion de serveur CAS par un URL : dans lequel il y a un paramètre service qui indique L adresse de destination de l utilisateur. (2) Le serveur CAS authentifie l utilisateur en vérifiant la combinaison nom d'utilisateur/mot de passe donnée par l utilisateur. Après l authentification réussite, il génère un ticket et l ajoute dans la fin d URL redirent : (3) À partir de ticket, l utilisateur utilise l UR L redirent : pour accéder à nouveaux au service BIZ. (4) Le CASFilter filtre la requête et récupère le ticket. CASFilter demande au serveur CAS pour vérifier le ticket par l URL redirigeant :http//casserver/cas/servlet/validate?service= &ticket=casticket. À partir de la réponse tournée par le serveur CAS, le CASFilter autorise l utilisateur d accéder au page ou redirige l utilisateur vers pour l authentification Open SSO Sun OpenSSO fournit une solution d authentification unique. L'utilisateur ne tape son mot de passe qu'une seule fois par session. La solution SSO s'occupe de le renseigner dans toutes les applications du système d'information. OpenSSO fournit les bases pour l'intégration de divers applications Web fonctionnant sur un grand nombre de référentiels d'identités différents, installé sur différentes plates-formes, telle que des serveurs Web et des serveurs d'application. OpenSSO fonctionne sur un échange de cookie entre l application et le serveur d authentification. Ce cookie de session va permettre de récupérer auprès du serveur d authentification le jeton SSO (SSOToken). OpenSSO est conçu pour fournir des services de sécurité pour les applications Java, Web et orienté services. 28 / 39

29 Figure 12. Architecture Open SSO OpenSSO permet de couvrir de nombreux besoins de notre environnement et offre de multiples possibilités d évolution et d intégration. Parmi les fonctionnalités les plus marquantes, citons : Authentification, autorisations et journalisation A ce niveau, nous avons la possibilité d associer à un utilisateur un ensemble de services par rapport à ses fonctions (rôles) ou à son appartenance à une entité (organisation), ainsi qu un mode d authentification. Il est fourni avec un grand nombre de modules d authentification déjà intégrés comme LDAP, aussi Active Directory, Certificats, JDBC, MSISDN5, Radius, SAML (2.0), SecurId et la possibilité de les chaîner. Le système SSO permet de gérer les accès à des applications autant qu'à des pages Web avec une grande finesse d administration et un héritage fort. Les systèmes de SSO sont basés sur un modèle client/serveur dont la partie cliente est généralement incluse dans l application (mode intrusif). Il est possible d éviter cette intrusion dans les applications de type Web par l utilisation d un module complémentaire au serveur qui héberge l application. La suite JES ( Java Entreprise Sun) dans laquelle se trouve OpenSSO offre un ensemble d outils de statistiques et de suivi d utilisation des services. Il est possible de suivre les taux de fréquentation, le nombre de sessions actives, les temps de réponses moyens du portail, etc. mais aussi, les créations de sessions, les appels SSO, les politiques d accès Administration fine et dynamique Une gestion hiérarchique des entités et des utilisateurs est possible grâce au mécanisme de délégation. La notion de rôle avec priorités permet de proposer très finement des services aux utilisateurs selon leur appartenance à une entité, à une fonction, à un groupe Côté gestion du système une console d administration permet de gérer les différents paramètres, les identités, et d administrer les différentes briques de la suite logicielle comme le portail. Haute disponibilité 29 / 39

30 La possibilité de rendre l ensemble des briques hautement disponibles avec tolérance de panne. La récupération de session est assurée par Message Queue sui n a pas été retenue pour l instant. Fonctionnement : OpenSSO manipule un arbre d organisations (composantes) avec, pour chacune, des services, des utilisateurs, des rôles et des politiques. Pour authentifier l utilisateur et pouvoir proposer ses propriétés à une application cliente, Access Manager utilise un cookie dénommé iplanetdirectorypro. Ce cookie va permettre de récupérer le SSOToken, un objet Java contenant des attributs de l utilisateur (identifiant, rôles, organisation ). Authentification unique Le principe de l authentification unique est le suivant : - Un «agent» est installé sur le serveur d'application à protéger. Son but est d'intercepter la requête du client et de dialoguer avec Access Manager pour vérifier si l'utilisateur a le droit d'accéder à la ressource qu'il demande et de répondre en conséquence au client. - Sur Access Manager est définie une liste de «politiques». Ces politiques décrivent les droits d'accès aux ressources en fonction du statut de l'utilisateur, de ses rôles, de son rattachement. Politique Une politique est composée de règles (une url à protéger, un service, un profil d utilisateur, un Web Service ), de sujets (des utilisateurs, les membres d un rôle, un groupe LDAP, les membres d une organisation ) et de conditions (la méthode d authentification utilisée, l adresse IP du client, l heure ). Aucune action n est nécessaire sur l application protégée, le pilotage de la politique de sécurité se fait au niveau d Access Manager. Access Manager décide si, selon l url demandée, il autorise ou non l utilisateur connecté à y accéder. Ni l agent, ni l application ne gèrent les droits de l utilisateur. Ce mode est non intrusif. 5. Conclusion En conclusion, l utilisateur d aujourd hui se déplace, change d environnement (d accès réseau), change de terminal, désire une continuité de service sans couture. Afin de répondre à ces besoins, le concept «user centric» vise à rendre tout le système au service de l utilisateur et propose une session unique et sécurisée pour les différents services. Pour se faire il faut mettre en œuvre des composants de sécurité permettant à l utilisateur d avoir un accès sécurisé et sans couture à l ensemble de ses services. En s appuyant sur le cas d utilisation UBIS qui représente les différentes situations (hétérogénéité, mobilité et User Centric) que nous voulons couvrir, nous nous sommes posé les premières questions et identifié les problématiques suivantes : - P1 : Audit de la QoS. - P2 : mobilité de l utilisateur (changement de terminal). - P3 : le transorganisationnel (plusieurs fournisseurs de service). - P4 : l authentification unique pour tous les composants de services sollicités. - P5 : l autorisation quand le service global repose sur une composition d élément de service. - P6 : la session mobile et dynamique dans un contexte où tout est service composable. - P7 : la spécification des mécanismes de sécurité. Eux mêmes deviennent des services que l on peut composer selon ses besoins de lieu et de temps (spatial et temporel) et ses préférences. Pour y répondre nous avons d abord étudié les solutions existantes. C est ainsi que nous avons analysé les mécanismes de Single Sign On, qui permet une propagation de session et une authentification unique pour l ensemble des services sollicités. Ce qui répond dans un premier temps à la problématique P4. 30 / 39

31 Ensuite, nous avons abordé les approches de centralisation et de fédération qui sont parfaitement complémentaires : la gestion des identités centralisée est une première étape de rationalisation des informations au sein de l entreprise/organisme et la fédération des identités répond aux besoins d intégration des services d identités entre différentes organisations (métiers, partenaires, fournisseurs, clients, etc.). Ce qui répond à la problématique P3 Enfin, nous avons déployé quelques produits SSO pour évaluer la pertinence des réponses d aujourd hui. La phase d expérimentation nous permettra d apporter nos conclusions. Notre prochaine étape est de répondre en priorité à la problématique P7, c'est-à-dire à la spécification des composants de services de sécurité. Des réponses à P1 d une part (Audit) et à P2, P5 et P6 d autre part sont déjà à l étude. 31 / 39

32 6. ANNEXE Expérimentation : Fédération avec SAML2 En déployant Open SSO et Federation Manager, on va tester la fédération avec SAMl2 dont on a définit précédemment (IV.2.1.1).Tout d abord on a deux serveurs idp et sp, on va créer deux instances respectivement idp et sp. On va commencer par la création d une instance idp en tant que fournisseur d identité hébergé. Cette page permet de configurer une instance de serveur OpenSSO en tant que fournisseur d'identités. On va fournir un nom au fournisseur, cercle de confiance (COT), les métadonnées du fournisseur. Un cercle de confiance est un groupe de fournisseurs d'identités et de fournisseurs de services se faisant mutuellement confiance. Ils représentent les limites au sein desquelles toutes les communications de fédération sont effectuées. Les métadonnées représentent la configuration nécessaire pour exécuter des protocoles de fédération (SAMLv2, par exemple), ainsi que le mécanisme pour communiquer cette configuration à d'autres entités (des fournisseurs de services, par exemple) dans un cercle de confiance. Les métadonnées sont générées si on n'en possède pas. 32 / 39

33 Pareil on va créer une instance sp en tant que fournisseur de services et on va suivre les mêmes instructions effectuées pour instancier et configurer idp 33 / 39

34 Ensuite on va enregistrer les fournisseurs distants d identité distants et affecter l url des métadonnées. et les fournisseurs de services 34 / 39

35 On va tester la fédération en déployant un use Case tels que GreatAir est un fournisseur de service de réservation de vol hébergé sur le serveur idp qui est en relation de confiance avec un autre fournisseur de services BestCars. On voulait réserver une voiture auprès BestCars à partir GreatAir. Redirection vers le fournisseur d identité GreatAir (idp) pour s authentifier d une manière unique afin de réserver une voiture de BestCars. 35 / 39