Contrôle d accès basé sur les rôles et négociation dans un environnement multi cercles de confiance

Dimension: px
Commencer à balayer dès la page:

Download "Contrôle d accès basé sur les rôles et négociation dans un environnement multi cercles de confiance"

Transcription

1 Contrôle d accès basé sur les rôles et négociation dans un environnement multi cercles de confiance Auteur : François Tachoires, v1.0, 06/06/2008 Encadrants EADS : Augustin De Miscault, Marie Nuadi Encadrants Telecom Bretagne : Frédéric et Nora Cuppens Rapport de stage du master recherche informatique de l université de Rennes I Mots-clés : contrôle d accès, rôle, XACML, SAML, inter-cot, fédération des identités, B2B, négociation de politiques de sécurité 1/48

2 RESUME INTRODUCTION CONTEXTE DU TRAVAIL PROJET FC² ENQUETE JUDICIAIRE : EXEMPLE D APPLICATION GENERALITES SUR LA FEDERATION DES IDENTITES CONTROLE D ACCES ENTRE CERCLES DE CONFIANCE L EXISTANT ET SES LIMITES Problème 1 : Gestion des authentifications et du contrôle d accès centralisé Problème 2 : Le contrôle d accès basé sur les rôles Problème 3 : L échange des rôles des utilisateurs Problème 4 : La transmission de l authentification OBJECTIFS SPECIFICATIONS Exigences Fonctionnalités STANDARDS PERTINENTS POUR REPONDRE AUX SPECIFICATIONS UN ROLE DYNAMIQUE VIA LES ATTRIBUTS UNE SOLUTION DE CONTROLE D ACCES MULTI-CERCLES BASEE SUR SAML ET XACML FORMAT DES ATTRIBUTS ECHANGES Les attributs SAML Les attributs XACML XACML Attribute profile Cas 1 : rôle sans attributs sensibles Cas 2 : rôle avec attributs sensibles SOLUTION PROPOSEE POUR LE CONTROLE D ACCES Architecture globale Fédération pour la phase d authentification Phase d autorisation Architecture détaillée côté SP WSC Architecture détaillée côté IDP WSP XACML en détail dans le cas Enquête Judiciaire DEPLOIEMENTS POSSIBLES Cas 1 un module intégralement externe Cas 2 des agents PEP distribués sur les SP avec un PDP central partagé Cas 3 des agents PEP distribués sur les SP avec plusieurs PDP distribués Cas 4 des agents PEP+PDP localisés sur les SP UNE SOLUTION INNOVANTE BASEE SUR LA NEGOCIATION DE POLITIQUES LES INTERETS DE LA NEGOCIATION L ARCHITECTURE ET LES ECHANGES GENERAUX EXEMPLE THEORIQUE DE NEGOCIATION AVEC TRUSTBUILDER COMPARAISON DES DEUX SOLUTIONS AXES FUTURS DE TRAVAIL DEPLOIEMENT POUR PREUVE DE CONCEPT LIMITES L administration des politiques de sécurité Utilisation d un rôle entre différents cercles de confiance CONCLUSION /48

3 GLOSSAIRE BIBLIOGRAPHIE TABLE DES FIGURES ANNEXES FEDERATION DES IDENTITES : SAML 2.0 ET LIBERTY ALLIANCE L AUTORISATION : LE STANDARD XACML Description de XACML Un exemple simple Le profil RBAC pour XACML /48

4 Résumé Les problématiques de SSO et de contrôle d accès aux applications d une entreprise sont bien connues et généralement résolues grâce à des annuaires internes. Cependant, donner des accès à des utilisateurs hors domaine, dans le cadre de partenariats inter-entreprises par exemple, est effectué le plus souvent manuellement par les administrateurs. Ce rapport présente deux solutions de contrôle d accès dans un environnement multi-cercles de confiance. La première est basée sur des standards ouverts pour échanger les informations d'authentification et de rôle des utilisateurs. Les standards étudiés sont SAML pour la fédération, et le transport d informations d authentification, de rôle et d autorisation, et XACML pour exprimer les politiques de contrôle d accès. La deuxième est une solution innovante qui repose sur des échanges de politiques entre deux modules de négociation. Un niveau de confiance bilatéral est atteint avec suite à un échange progressif d affirmations signées, et alors une autorisation d accès peut être donnée. 4/48

5 1. Introduction Aujourd hui, un internaute n a pas la possibilité de gérer simplement et efficacement son identité : il manque clairement une abstraction de l identité sur Internet. Tout internaute doit créer de multiples comptes sur chaque service qu il utilise, avec autant de mots de passe associés, et à la clé une ergonomie faible. Pour répondre à cette problématique, différents standards ont émergé, comme Liberty Alliance, Shibboleth, OpenID, Higgins, Cardspace et SAML 2.0. Ces standards définissent des architectures et des protocoles pour fédérer des identités entre les domaines, pour faire bénéficier à l internaute du SSO (Single-Sign On). Les problématiques de SSO au sein d une même entreprise sont souvent résolues à l aide d outils dits de E-SSO. Ces outils permettent de réaliser, de manière transparente pour l utilisateur, une authentification auprès des différentes applications auxquelles il a accès. Cependant les différentes solutions propriétaires ne sont pas interopérables et ne permettent donc pas de faire du SSO multi-domaines. Dans le cadre de partenariats entre deux entreprises, un utilisateur dont l identité est connue par son entreprise souhaite accéder à un service hébergé par l autre entreprise. Le contrôle d accès multi-domaines B2B est administré manuellement à l heure actuelle. Des accès particuliers sont ajoutés pour les personnes externes à l organisation. La transmission sécurisée des informations sur le rôle de l utilisateur permettrait de gérer ses droits d accès externes, suite à des accords entre les entreprises. L utilisation de standards compréhensibles par n importe quelle entreprise est un point clé pour résoudre cette problématique. Dans ce rapport nous allons discuter de cette utilisation des standards de fédération et de contrôle d accès pour donner des permissions spécifiques dans le cadre d échanges B2B, en basant la prise de décision sur un rôle joué par l utilisateur au sein de son entreprise. Dans un premier temps, nous décrivons le contexte dans lequel le travail a été réalisé, puis nous développons les limites de l existant et les objectifs du travail réalisé. Les standards pertinents et les formats des attributs échangés sont présentés, nous détaillons ensuite deux solutions possibles, l une basée sur l architecture XACML et l autre sur des principes de négociation de politiques de sécurité. Finalement nous évoquons les axes futurs de travail et concluons. 5/48

6 2. Contexte du travail 2.1. Projet FC² Le projet FC² se propose de concevoir une plate-forme complète permettant le développement sécurisé de nouveaux services électroniques basés sur la gestion transparente et fédérée d identités et s organisant autour de trois concepts principaux : 1) Définition et mise en œuvre de modèles d architectures de fédération d identité interopérables (Liberty Alliance, Microsoft/Cardspace, SAML, OpenID etc.) ; 2) Mise en place d une infrastructure dédiée pour les fournisseurs de service ; 3) Fourniture de services d authentification forte et de gestion de la vie privée. L enjeu du projet est multiple et vise les objectifs clés suivants : Garantir un haut niveau de prévention contre les attaques sur l identité numérique et lutter efficacement contre les divers types de fraude associés ; contribuer au développement efficace de nouveaux services basés sur l identité numérique, y compris dans une dimension multi sectorielle ; donner à l utilisateur final une plate-forme personnelle autorisant un meilleur confort et une plus grande facilité d utilisation vis à vis des systèmes transactionnels en ligne (ergonomie confiance - universalité d emploi) Enquête Judiciaire : exemple d application Nous nous intéressons plus particulièrement à un cas d usage B2B particulier, le cas «Enquête Judiciaire». Tout au long de ce rapport, c est cet exemple qui sera le plus utilisé pour illustrer nos propos. Il ne s agit, bien sûr, que d un exemple qui est comparable à d autres situations classiques dans le milieu industriel, où l administrateur d un service a besoin de donner des accès à des utilisateurs externes. Un cercle de confiance (ou CoT pour Circle of Trust) contient un ensemble d entités fournissant des services et/ou des identités entre lesquels une relation de confiance existe et donc auxquels l utilisateur peut accéder librement après une authentification unique. Dans ce cas d usage, un enquêteur du CoT gouvernemental souhaite accéder à un service sur le CoT Telecom, pour les besoins de son enquête (exemple : connaître la liste des numéros appelés par un suspect). L objectif est le suivant : on souhaite que le CoT gouvernemental puisse partager avec le CoT Telecom les informations sur l authentification ainsi que les attributs prouvant que l utilisateur est un enquêteur, afin que ce dernier puisse accéder au service Telecom. Le CoT Telecom n aurait ainsi pas à gérer manuellement l identité de l enquêteur pour donner l accès à son service, il ferait confiance aux informations fournies par le CoT gouvernemental sur l enquêteur. La figure 1 illustre ce cas : 6/48

7 Figure 1 : Cas enquête judiciaire 2.3. Généralités sur la fédération des identités Une fédération d identités est constituée des acteurs principaux suivants : un fournisseur d identité (IDP), un ou plusieurs fournisseurs de services (SP), et des utilisateurs. Pour simplifier l expérience de l utilisateur, il est souhaitable qu il puisse se connecter à plusieurs services, au cours d une même session, après une seule authentification. Ainsi, si un utilisateur possède plusieurs comptes sur différents services, le système va lui permettre de les fédérer, c est-à-dire de les relier, afin de pouvoir bénéficier du SSO. Le standard pour s échanger des informations sur l authentification d un utilisateur est SAML [2] dont les spécifications du consortium OASIS en sont à la version 2.0 (voir en annexe pour plus d informations). Concrètement, à l heure actuelle, l identité de l utilisateur est disséminée sur Internet. Pour accéder au moindre service (forum, réseau social, e-commerce ) l utilisateur doit créer un compte de type identifiant/mot de passe. Il doit mettre lui-même à jour ses informations personnelles (nom, date de naissance, , adresse ) dans les formulaires à remplir. Fédérer ses comptes lui permet donc, au cours d une même session, de se connecter à plusieurs services sans s authentifier à nouveau plus éventuellement transférer des informations personnelles (attributs). 7/48

8 3. Contrôle d accès entre cercles de confiance 3.1. L existant et ses limites Vérifier que les utilisateurs ont des droits ou privilèges suffisants avant de leur donner l accès à une ressource est constamment réalisé. C est la base de la sécurité de tout système d information. La bonne gestion des droits d accès des utilisateurs est donc une problématique classique sur tous les SI. Or, étant donné l explosion du nombre de services proposés par les SI, la gestion de ces droits d accès est devenue lourde à gérer pour les administrateurs. Quant aux utilisateurs, ils se sentent perdus devant l hétérogénéité des systèmes d authentification et d autorisation. Par exemple, ils travaillent fréquemment avec plusieurs couples identifiant/mot de passe. Généralement l administrateur définit les règles d accès par application. Il définit dans un premier temps une politique de sécurité, puis l intègre à son application dans un deuxième temps. Définir une politique consiste à lister des règles qui précisent les actions autorisées en fonction d un ensemble de conditions (voir figure 2). Dans le cas général, l administrateur utilise des politiques dites fermées, où l accès est par défaut interdit, puis définit les exceptions via ces politiques. Par exemple, un serveur web Apache permet de protéger les accès à un site web à l aide du fichier.htaccess, dans lequel on trouve la liste des utilisateurs qui sont autorisés à accéder à un endroit précis d un site web. Tous les autres utilisateurs se voient refuser l accès. Figure 2 : Contrôle d accès classique Cette solution très répandue pose principalement quatre problèmes : o Problème 1 : L administrateur configure pour chaque application une politique de sécurité dans un langage particulier, souvent de bas niveau ; o Problème 2 : L administrateur configure les accès pour chaque utilisateur ou doit gérer manuellement des groupes d utilisateurs ; o Problème 3 : L administrateur de l application doit gérer les données sur l utilisateur. Par exemple, si un employé qui avait des accès à trois services particuliers quitte l entreprise, il faudra supprimer ses droits sur chacun des services ; o Problème 4 : L utilisateur possède autant de méthodes d authentification (identifiant/mot de passe) que d applications auxquelles il accède. Il est difficile, lorsqu une organisation fournit beaucoup de services, de garder une cohérence et d avoir une vue d ensemble sur les droits d accès aux différents services offerts. La gestion de l ensemble devient compliquée pour l administrateur et est source d erreur. 8/48

9 Problème 1 : Gestion des authentifications et du contrôle d accès centralisé Faire du contrôle d accès signifie prendre une décision d autorisation en fonction de deux types principaux de données : l authentification de l utilisateur, des attributs (sur la ressource, le contexte et l utilisateur), voir figure 4. Le contexte actuel est que chaque service a son langage pour définir des règles pour protéger l accès à ses ressources. Ces politiques ne sont donc pas réutilisables d un service à un autre. De même chaque service propose son système d authentification. C est ce que schématise le côté gauche de la figure 3. Figure 3 : contrôle d accès classique vs contrôle d accès centralisé De ces constatations on remarque qu il serait souhaitable de simplifier les méthodes de contrôle d accès aux services afin d en faciliter l administration et donc au final d améliorer la sécurité de l ensemble. L objectif est de pouvoir externaliser une partie du contrôle d accès d un certain nombre de services, afin de maintenir la cohérence de la politique de sécurité globale de l organisation. Lors de l ajout d un service par exemple, l administrateur pourrait ainsi réutiliser certaines politiques d un autre service déjà existant. Il serait notamment intéressant de pouvoir utiliser à nouveau différents rôles communs au système, au lieu de redéfinir des groupes spécifiques à chaque application. L emploi de standards est nécessaire pour apporter une réponse à ce problème, dans le cas où l on veut avoir l opportunité d échanger des informations de politiques de contrôle d accès avec d autres entreprises. Il faut un standard qui propose l échange de données sur l authentification des utilisateurs (le service fait alors confiance à un ou plusieurs fournisseurs d identité) et un autre qui définit un langage de politique de contrôle d accès indépendamment des spécificités de la ressource protégée Problème 2 : Le contrôle d accès basé sur les rôles Dans un contexte de contrôle d accès sur des ressources réparties sur un ou plusieurs réseaux, l abstraction au niveau des rôles semble intéressante. Les droits d accès sont définis pour un 9/48

10 ensemble d utilisateurs jouant le même rôle dans l organisation. En effet pour un certain nombre d application l information d identité (nom d utilisateur etc.) est moins importante pour le contrôle d accès que le rôle dans l organisation. Dans la majorité des cas, le contrôle d accès type RBAC (Role-Based Access Control), se révèle être une abstraction intéressante pour gérer les accès aux ressources. Pour l administrateur elle permet d éviter de configurer les accès pour chaque utilisateur. Dans le cas d usage «Enquête Judiciaire» par exemple, un agent de la police avec le rôle enquêteur a accès à l application Telecom d enquête judiciaire, alors qu un agent de police sans ce rôle n y aura pas accès. RBAC a vraiment un intérêt particulier dans ce cas si l affectation des rôles aux utilisateurs peut être automatisé Problème 3 : L échange des rôles des utilisateurs Un agent de police ne conserve pas forcément le rôle enquêteur tout au long de sa carrière. Cette information est connue par l organisation qui l emploie, elle doit donc être gérée par celle-ci. Pour assurer un contrôle d accès efficace sur le service Enquête Judiciaire du CoT Telecom, il est souhaitable que le cercle Telecom n ait pas à gérer ce type d informations. Créer un compte par enquêteur sur le service, et mettre à jour manuellement les droits en fonction des arrivées/départs d enquêteurs est une solution trop lourde pour l administrateur du service Telecom. De plus, cela ne relève pas de sa responsabilité. On souhaite donc que le service Telecom «Enquête Judiciaire» puisse prendre des décisions de contrôle d accès en fonction d une information de rôle d utilisateur transmise par le cercle gouvernemental, via un attribut role par exemple, qui assure le maintien et la validité de ces informations. profils informations d'authentification + informations de profil Serveur d'authentification Enquêteur accès autorisé Service Enquête Judiciaire Figure 4 : Accès via rôle entre deux CoTs Problème 4 : La transmission de l authentification Les solutions de SSO et de fédération des identités visent à résoudre le problème de la multiplication des couples identifiant/mot de passe à saisir et à retenir par l utilisateur. Leur surnombre implique des oublis de mot de passe, l utilisation de mots de passe faibles ou identiques. Tout cela nuit à la sécurité. Du point de vue de l utilisateur, le SSO améliore l ergonomie puisqu il peut accéder à un ensemble de services après une seule authentification, qui peut être plus forte qu un login/password habituel. La sécurité globale du système s en trouve améliorée, puisqu une meilleure gestion des identités et de leurs droits associés est assurée. Il faut cependant noter qu un vol d identité peut alors avoir des conséquences plus graves, puisqu elle donne accès à plusieurs services. Grâce à la transmission des informations d authentification, l utilisateur n a pas à se ré authentifier sur le service d enquête judiciaire. 10/48

11 3.2. Objectifs La fédération des identités est d abord un concept destiné à améliorer l expérience de l internaute. Il semble intéressant tout de même d utiliser ces standards dans le cadre d échanges B2B. L objectif général est donc de réaliser du contrôle d accès B2B grâce aux informations sur l identité échangées via un standard de fédération d identités. Les contraintes en B2B sont différentes : dans ce cadre-là, l employé d une entreprise a confiance en elle pour stocker et gérer des données personnelles sur son identité. Nous allons parler de «module de contrôle d accès» pour nous référer à la fonctionnalité supplémentaire proposée. Voici les caractéristiques clés que doit apporter le module de contrôle d accès à un ou plusieurs services disponibles dans un cercle de confiance. Amélioration de l expérience utilisateur : Accéder à des services hors de son domaine après une authentification unique sur son domaine (éventuellement une ré authentification si souhaité) Bénéficier de privilèges sur un domaine B grâce à son rôle certifié par son domaine A. Amélioration de l expérience administrateur : Ouvrir l accès aux applications à des utilisateurs externes au domaine et au CoT sans en perdre le contrôle ; Ne pas avoir à créer un compte individuel pour un utilisateur externe ; Déléguer l administration de l identité, du rôle et des attributs des utilisateurs externes à l organisation à l administrateur des organisations partenaires ; Centraliser les politiques d un ensemble de services aux exigences de sécurité proches, et ainsi en faciliter la vision et l administration ; Exprimer une politique de sécurité fine quelle que soit la ressource à protéger à l aide d un langage standard ; Garder un contrôle fin sur la diffusion du rôle ou des attributs afin de respecter la vie privée des utilisateurs, et protéger ces informations potentiellement sensibles ; Garder des traces sur les connexions et les requêtes, lors de l utilisation de services sensibles Spécifications Exigences Quelques définitions pour le contrôle d accès Un module de gestion de contrôle d accès a différentes tâches à exécuter, qui sont confiées à divers éléments. Avant d aller plus loin, voici donc quelques définitions de formalisation de ces différents éléments, indispensables à la compréhension de la suite du document : PEP, Policy Enforcement Point : élément chargé de mettre en œuvre le contrôle d accès. Il applique les décisions de politiques en réponse aux requêtes des utilisateurs qui veulent accéder à une ressource sur le réseau ; PDP, Policy Decision Point : élément chargé de prendre une décision (Permit ou Deny) à l aide d un ensemble d informations (politiques, identité de l utilisateur, ressource, contexte). Il est consulté par le PEP ; PAP, Policy Administration Point : élément permettant à l administrateur de gérer les politiques de sécurité. Il fournira les politiques au PDP quand celui-ci les lui demandera ; PIP, Policy Information Point : élément chargé de récupérer d autres informations utiles à la prise de décision (sur l utilisateur, la ressource, l environnement ). 11/48

12 Ces termes de PEP et PDP sont apparus dans la RFC 2748 qui définit le protocole COPS. A noter que nous parlerons également d IDP (fournisseur d identité), de SP (fournisseur de service) et d AP (fournisseur d attributs). Un attribut est un couple (nom, valeur) qui représente une information sur une caractéristique d un sujet, une ressource ou un environnement. Par exemple l attribut fonction= agent de la police judiciaire pourra être utilisé dans le cas Enquête Judiciaire. Un attribut peut être multi-valué. Dans ce cas-là c est un n-uplet (nom, valeur1, valeur2,, valeur(n-1)). Un rôle permet de représenter une fonction d un sujet au sein d une organisation. Une politique d accès rassemble une ou plusieurs règles définissant quelle action peut faire tel ou tel sujet sur une ressource, dans tel contexte. Une règle est composée de conditions, d actions et éventuellement d obligations. Par exemple, sous la condition que l utilisateur (qui demande l accès) possède le rôle enquêteur, l action est d autoriser l accès, avec obligation de garder une trace dans un fichier de log. Les exigences de l utilisateur L utilisateur a un compte sur l IDP gouvernemental dans le cas Enquête Judiciaire, mais n a pas de compte sur l IDP Telecom. L IDP Telecom est capable de valider l authentification de l utilisateur sur l IDP gouvernemental. L authentification fonctionne de la manière suivante : l utilisateur bénéficie du SSO lors d accès à de multiples services, sur de multiples CoTs : 1. Il s authentifie sur l IDP de son CoT (IDP1) ; 2. Il accède au SP1 qui l authentifie de manière transparente grâce à l IDP1 ; 3. Il accède à un deuxième SP2, sur un autre CoT, qui l authentifie encore de manière transparente. Le schéma ci-dessous présente cette cinématique : compte utilisateur A IDP1 1 IDP2 SP1 2 3 SP2 Utilisateur A Figure 5 : un cas d'usage de SSO multi-cots Sur cette figure, les flèches fines entre SP et IDP, et entre IDP et IDP, représentent le partage des informations d authentification et d attributs, qui est effectué de manière transparente pour l utilisateur. Différentes méthodes d authentification sont envisageables. Suivant les méthodes utilisées, le poste client peut devoir disposer d éléments supplémentaires (par exemple un lecteur de carte à puce). Un SP peut exiger un niveau d authentification particulier et à ce moment-là l utilisateur doit se ré authentifier sur l IDP avec la méthode d authentification adéquate. Les sessions sont 12/48

13 généralement gérées via l utilisation de cookie sur le navigateur client. Pour pouvoir bénéficier du SSO et du SLO l utilisateur doit donc accepter ces cookies. La politique d utilisation de ces éventuels cookies doit tenir compte du vol de cookie ou du «cookie hijacking». Comme un cookie permet à l utilisateur qui le possède de s authentifier sur n importe quel SP, le vol de cookie par un attaquant peut avoir des conséquences graves. Si le cookie n est pas chiffré et volé, l attaquant peut récupérer des informations confidentielles sur l identité de l utilisateur, et ses attributs. Cependant, même si ce cookie est chiffré, et s il est utilisé lors d une connexion via un canal non sécurisé (HTTP par exemple), il peut être sniffé et rejoué par un attaquant, qui pourra voler la session de l utilisateur et accéder à tous ses services avec ses privilèges. Figure 6 : cookie hijacking Le cookie doit être chiffré et le risque de rejeu doit être diminué (via des timestamps par exemple). L utilisateur ne possède pas de compte sur le SP. Dans le cas Enquête Judicaire, l enquêteur n a pas non plus de compte sur l IDP Telecom. Les exigences de l administrateur On distingue deux administrateurs : l administrateur d un SP l administrateur de l IDP L administrateur d un SP L administrateur d un SP peut avoir plusieurs SP à gérer. Le rôle de l administrateur d un SP est de gérer finement les accès au service qu il met en place. L administrateur d un SP est à la fois administrateur des SP dont il a la charge et administrateur du point du module de contrôle d accès où les politiques sont définies. L administrateur sur le module de contrôle d accès crée, modifie, supprime : des règles définissant les rôles des utilisateurs de son cercle de confiance, des politiques de contrôle d accès en définissant des règles qui s appliquent aux rôles. administrateur définit une politique de sécurité pour son système d'information active des agents de sécurité sur les SP crée les politiques d'accès a une vision d'ensemble sur les accès à son système a des logs sur l'ensemble des accès Figure 7 : cas d'utilisation du point de vue d un administrateur SP PEPs PAP L administrateur de SP doit pouvoir retrouver les actions utilisateurs et leurs auteurs. Il doit donc avoir à disposition des traces précises sur les accès au service. Ceux-ci doivent être journalisés, avec un lien permettant de remonter à l identité de l utilisateur. Ces traces contiendront par exemple des informations de date, heure, identité de l utilisateur, requête effectuée, ressource concernée Il ne gère pas les attributs des utilisateurs extérieurs au CoT. Il ne gère pas l ajout ou la suppression de comptes destinés à des personnes extérieures à l organisation. L administrateur d un IDP L administrateur d un système d informations, qui gère les différentes identités de son système, souhaite avoir une vue générale sur ses identités. Il souhaite ne pas avoir à gérer les identités de 13/48

14 personnes externes à l organisation, mais plutôt collaborer avec les fournisseurs d identité des autres organisations. Il souhaite avoir une vue d ensemble sur les politiques d accès aux services hébergés sur son système et pouvoir générer des rapports sur les statistiques de ces accès. Cette administration d ensemble peut être facilitée par l existence de rôles au sein de son système, qui représentent l abstraction d utilisateurs. Il souhaite partager des informations sur les attributs de ces utilisateurs, de manière contrôlée (respect de la vie privée des utilisateurs, confidentialité de certains attributs), avec des fournisseurs de service de confiance avec qui des accords auront été passés. Les exigences en termes de sécurité des ressources Quand on parle de contrôle d accès, il s agit tout d abord d identifier les ressources que l on souhaite protéger. Dans le cadre qui nous intéresse, elles sont de plusieurs types : Les données liées à un service proposé. On se limite a des ressources disponibles depuis un serveur web. Les informations personnelles des utilisateurs. Il s agit d assurer aux utilisateurs que leurs données personnelles (attributs) sont en sécurité. Même si Liberty Alliance assure que les informations concernant les utilisateurs sont toujours transmises avec l autorisation de l utilisateur, on peut craindre certains abus de la part de fournisseurs de service peu scrupuleux (par exemple un SP pourrait demander plus d attributs qu il n en a réellement besoin), et il apparaît donc nécessaire de protéger les accès à ces ressources. On souhaiterait que seuls les attributs nécessaires et suffisants pour l accès à un service soient transmis. Les politiques de sécurité liées à un service. On peut également imaginer que ces politiques doivent être protégées au même titre par exemple que l annuaire des utilisateurs. La connaissance de la politique de sécurité liée à un service peut aider un attaquant à la contourner, en l étudiant et en exploitant des vulnérabilités. Il faudra assurer donc que l élément qui réclame des politiques est de confiance. Les cookies et informations de sessions. Afin de garder en mémoire un contexte de sécurité après une authentification réussie à un service, fournisseur et utilisateur doivent stocker en local et se transmettre un certain nombre d informations liées à une session (heure, validité, contexte de sécurité, informations propre à l application.). Il faut empêcher l usurpation d identité. Les exigences pour les informations d authentification Le module de contrôle d accès devra être capable d analyser les informations contenues dans ce jeton d authentification, et d exprimer ses conditions suivant ces exigences en termes de contrôle des accès. C est-à-dire qu il pourra exiger que ce jeton d authentification soit délivré et certifié (signature) par un IDP particulier, il devra pouvoir en vérifier la validité (date et heure, émetteur et destinataire corrects ). SAML préconise l utilisation de standards pour cela (XML-Signature, TLS/SSL) Utilisateur demande d'accès + jeton d'authentification 1. Vérification du jeton 2. Analyse de la requête 3. Décision Figure 8 : gestion du jeton d'authentification 14/48

15 Suivant l analyse de la requête avec les informations du jeton d authentification, plus d autres informations que peut obtenir le module, une décision sera prise. Cette décision pourra être : Accès autorisé Accès refusé Redirection pour l obtention d un autre jeton d authentification (ayant un autre niveau d authentification ou provenant d une autre source Erreur (avec message descriptif éventuel) SAML ne préconise pas d authentification particulière mais permet simplement de transporter dans ces jetons le contexte d authentification. Le module, pourra formuler des exigences sur ce contexte afin de contrôler l accès aux ressources. Les exigences pour la diffusion des attributs Pour prendre une décision d accès, le module peut avoir besoin, en plus des informations autour de l authentification de l utilisateur, d informations le caractérisant. Il doit donc être capable de récupérer les attributs auprès des fournisseurs d attributs de l utilisateur via les protocoles SAML adéquats. Un attribut est une affirmation (clé=valeur). Par exemple, pour l utilisateur Jean Dupont aura les attributs suivants : Nom= Dupont Prenom= Jean = Il est important de noter que, dans un usage multi CoTs plus particulièrement, il est indispensable de connaître l émetteur de ces attributs. Ceux-ci doivent donc être signés par l autorité émettrice, car certains attributs pourront avoir la même clé sur différents CoTs, et donc une signification différente. Par exemple, Jean Dupont peut avoir un attribut role= ingénieur sur le fournisseur d attributs de son employeur, et un attribut role= trésorier sur le fournisseur d attributs d une association dont il fait partie. Prendre des décisions d accès via des attributs signifie donc que ces attributs sont certifiés par l émetteur. L intégrité doit pouvoir être également vérifiée. La confidentialité lors de la diffusion des attributs est un critère important, indispensable pour protéger non seulement la vie privée de l utilisateur mais souvent aussi son entreprise pour qui ces informations sont sensibles. Il faut noter aussi que la demande d attributs elle aussi doit respecter ces critères de signature, d intégrité et de confidentialité. En effet, le fournisseur d attributs doit être sûr de l origine de la source qui requiert des attributs sur un utilisateur ; il peut être également important dans certains cas que la requête soit confidentielle car elle est directement liée à une politique de contrôle d accès spécifique. Par exemple, dans le cas Enquête Judiciaire, il pourra être considéré comme sensible l information que l accès au service nécessite l attribut habilitation de l utilisateur. Les spécifications SAML et WS-Security permettent de répondre à ces critères. Fournisseur d'attributs confidentialité, intégrité, signature Demande d'attributs Envoi des attributs demandés valide Utilisateur Figure 9 : gestion de l'échange des attributs module de contrôle d'accès 15/48

16 La validation de l utilisateur n est pas obligatoire, elle peut être évitée si le fournisseur d attributs assure un contrôle fort sur les requêtes d attributs (autorisation de diffusion de certains attributs à un ensemble limité de SPs). Ce contrôle fort peut être assuré par un module de négociation ou via des politiques de contrôle d accès fines appliquées aux attributs Fonctionnalités Voici à droite le schéma fonctionnel général du module de contrôle d accès 1. requête d accès à une ressource 2. opérations pour prendre une décision d autorisation d accès 2.1 authentifier l utilisateur (via un service d authentification externe) 2.2 récupérer les politiques d accès à la ressource demandée 2.3 récupérer les attributs de l utilisateur nécessaires à la décision 2.4 prendre une décision avec les informations recueillies 2.5 garder une trace de la décision 3. transmission de la requête (cas où la requête est acceptée) 4. opérations pour prendre une décision sur le flux sortant (optionnel, dans le cadre de la protection avant la diffusion de documents sensibles par exemple) 4.1 vérification du contexte 4.2 contrôle d accès supplémentaire (prise de décision en fonction d éléments recueillis) 5. transmission de la ressource Ce module protège donc les accès d un SP. Ce SP peut être de différentes formes, et c est pourquoi le module de contrôle d accès devra en pratique s adapter aux SPs. Cela signifie aussi que ce SP peut être un AP, et donc qu à ce moment on contrôle la diffusion des attributs des utilisateurs, qui sont une ressource comme une autre. Le module de contrôle d accès doit être placé en coupure devant les fournisseurs de service, afin de pouvoir traiter les requêtes, c est-à-dire vérifier qu elles sont légitimes (utilisateur authentifié ayant des privilèges suffisants par rapport à une action sur une ressource demandée). La contrainte est donc, au sein d un cercle de confiance, d être compatible avec les protocoles de SSO utilisés. Le module de contrôle d accès devra être compatible avec les profils de SSO, c està-dire être capable d interpréter correctement les messages SAML échangés entre les différentes autorités de cercles de confiance. 1 AuthN 2 AuthZ 3 Gestion accréditations Gestion de l'authentification : profils SSO SP1 + comptes fonctionnels Gestion de l'autorisation : contrôle d'accès sur le rôle module de contrôle d'accès SP2 + comptes fonctionnels Gestion des sessions ouvertes Gestion du traçage SP3 + comptes fonctionnels Figure 11 : fonctionnalités principales du module Figure 10 : fonctionnement haut niveau du module 16/48

17 Le module de contrôle d accès devra être capable de gérer 3 phases : l authentification, l autorisation (contrôle d accès via des règles sur des rôles) et la session avec le SP, ceci pour le compte de un ou plusieurs SP Standards pertinents pour répondre aux spécifications Les contraintes posées pour la résolution du cas d étude B2B imposent principalement que deux cercles de confiance puissent échanger des informations sur l authentification et les attributs d un utilisateur. Le premier standard qui s impose naturellement est SAML 2.0. Il définit des protocoles pour échanger ces informations-là, et son format de jetons a été adopté par les principaux groupes de travail de Fédération des Identités. Plus d informations générales sur SAML sont disponibles en annexe ; dans la suite de ce rapport nous détaillerons les éléments clés de SAML permettant de résoudre notre problématique de B2B. Le deuxième standard indispensable est XACML. Après un examen de l état de l art, on remarque que c est un standard permettant de définir des politiques de contrôle d accès fines, ainsi qu une architecture d utilisation de ces politiques, avec un lien fort avec SAML. Ce dernier permet de transporter les informations utiles à la prise de décision, lors de l examen d une requête d accès. De même, le lecteur intéressé peut trouver plus de détails sur les principes de XACML en annexe. SAML 2.0 profile of XACML et Core and hierarchical role based access control (RBAC) profile of XACML v2.0 sont deux specifications de OASIS particulièrement reliées à notre problématique. La première étend SAML pour pouvoir transporter des requêtes XACML, la deuxième propose une solution pour implémenter des politiques RBAC avec XACML Un rôle dynamique via les attributs Dans RBAC, en général, les rôles sont définis manuellement. Cela pose évidemment un certain nombre de problèmes d administration. Un concept commun entre les différents systèmes de fédération d identités est celui d attributs. Dans ce cadre-là on souhaiterait pouvoir prendre des décisions de contrôle d accès en s échangeant les attributs entre différents cercles de confiance, via des protocoles standard. Dans [8] est défini un modèle de politique de contrôle d accès basé sur les attributs (ABAC). Voici le modèle basique : (1) S, R et E sont des sujets, ressources et environnements respectivement ; (2) SA k (1 k K), RA m (1 m M), et EA n (1 n N) sont les attributs pré-définis pour les sujets, ressources et environnements respectivement ; (3) ATTR(s), ATTR(r) et ATTR(e) sont des relations d affectation d attributs pour un sujet s, une ressource r et un environnement e, respectivement : ATTR(s) SA 1 x SA 2 x x SA K ATTR(r) RA 1 x RA 2 x x RA M ATTR(e) EA 1 x EA 2 x x EA N (4) Dans sa forme la plus générale, une règle de politique décide si un sujet peut accéder à une ressource r dans un environnement e. C est une fonction booléenne sur les différents attributs ; si le résultat est évalué à true, l accès est autorisé, sinon l accès est refusé. Rule: can_access(s,r,e) f(attr(s), ATTR(r), ATTR(e)) 17/48

18 L intérêt de ce modèle par rapport à RBAC est qu il permet d utiliser implicitement la notion de rôle et de les affecter dynamiquement. L effet immédiat est que la complexification d une politique de sécurité entraîne avec RBAC une explosion du nombre de rôles, alors qu avec un modèle de contrôle d accès grain fin comme ABAC cela reste tout à fait gérable. Voici un exemple pour illustrer cela : Une organisation doit contrôler l accès à des documents selon la politique suivante. Sensibilité du document Habilitation du sujet S (secret) Habilité S C (confidentiel) Habilité C ou plus P (public) Tout le monde Dans le modèle RBAC, trois rôles sont créés : HabilitéSecret, HabilitéConfidentiel, HabilitéPublic. Trois règles exprimant les permissions accordées à chaque rôle sont également créées. On spécifie donc que les utilisateurs ayant le rôle HabilitéSecret peuvent voir les documents secrets, confidentiels et publics. Ceux ayant le rôle HabilitéConfidentiel peuvent voir les documents confidentiels et publics, enfin ceux ayant le rôle HabilitéPublic peuvent uniquement voir les documents publics. Enfin les sujets sont manuellement affectés à l un des trois rôles. Avec ABAC, il n est pas nécessaire d expliciter la notion de rôle, mais simplement d exprimer dans une règle les droits d accès des sujets s sur un document d avec un environnement e (ici non pris en compte) : Rule1: can_access(s,d,e) (Habilitation(s)=S ET Sensibilité(d) Є {P,C,S}) OU (Habilitation(s)=C ET Sensibilité(d) Є {P,C}) OU (Habilitation(s)=P ET Sensibilité(d) Є {P}) Pour exprimer des règles fines de contrôle d accès, plusieurs attributs sont souvent mis en jeu. C est là qu ABAC se montre plus adaptable que RBAC. Par exemple, si on veut exprimer que le document, en plus de sa qualification, appartient à un domaine particulier, le domaine A ou le domaine B et que seuls les sujets du département A (respectivement B) peuvent accéder aux documents du domaine A (respectivement B), on remarque que le nombre de rôles est multiplié par deux. Roles RBAC HabilitéSecretA HabilitéSecretB HabilitéConfidentielA HabilitéConfidentielB HabilitéPublicA HabilitéPublicB Permissions RBAC Peut voir un document secret du domaine A Peut voir un document secret du domaine B Peut voir un document confidentiel du domaine A Peut voir un document confidentiel du domaine B Peut voir un document public du domaine A Peut voir un document public du domaine B Avec ABAC il suffit d ajouter une règle à la première, et de combiner les deux : Rule2: can_access(s,d,e) (Domaine(d)=A ET Departement(s)=A) OU (Domaine(d)=B ET Departement(s)=B) Rule3: can_access(s,d,e) Rule1 ET Rule2 18/48

19 4. Une solution de contrôle d accès multi-cercles basée sur SAML et XACML 4.1. Format des attributs échangés Les attributs SAML Un attribut SAML est principalement constitué d un nom Name et d une valeur AttributeValue. Par exemple : <saml:attribute Name="role"> <saml:attributevalue> enqueteur </saml:attributevalue> </saml:attribute> Il est possible qu un attribut ait plusieurs valeurs. On peut spécifier également le format de l attribut (par défaut l attribut est de format unspecified. Si un attribut est multi-valué, toutes ces valeurs doivent avoir le même format. Voici les formats disponibles : urn:oasis:names:tc:saml:2.0:attrname-format:unspecified urn:oasis:names:tc:saml:2.0:attrname-format:uri urn:oasis:names:tc:saml:2.0:attrname-format:basic Différents profils pour l utilisation de ces attributs sont définis dans la documentation SAML Profiles. <saml:attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="FirstName"> <saml:attributevalue xsi:type="xs:string">jean</saml:attributevalue> </saml:attribute> Les attributs XACML Les attributs XACML diffèrent des attributs SAML. Dans une requête XACML on va trouver l élément <xacml-context:attribute>. Cet élément contient les attributs AttributeId et DataType, et optionnellement Issuer. Cet élément contient également un ou plusieurs éléments <xacml-context:attributevalue>. Voici un exemple : <xacml-context:attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name" Issuer="http://idp.gouv.fr"> </xacml-context:attribute> A noter que dans une politique XACML, l évaluation des attributs se fait à l aide des éléments <AttributeDesignator> et <AttributeSelector> XACML Attribute profile Les attributs SAML générés en accord avec le profil XACML adapté peuvent être transformés automatiquement en attributs XACML à utiliser comme entrées pour des décisions d autorisation XACML. Voici un exemple qui illustre ce profil. <saml:attribute 19/48

20 xmlns:xacmlprof="urn:oasis:names:tc:saml:2.0:profiles:attribute:xacml" xmlns:ldapprof="urn:oasis:names:tc:saml:2.0:profiles:attribute:ldap" xacmlprof:datatype="http://www.w3.org/2001/xmlschema#string" ldapprof:encoding="ldap" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid: " FriendlyName="givenName"> <saml:attributevalue xsi:type="xs:string">jean</saml:attributevalue> </saml:attribute> Cas 1 : rôle sans attributs sensibles Un SP a besoin de savoir si un utilisateur a le rôle adéquat pour lui donner l accès au service. Pour le SP, ce rôle correspond à une liste d attributs qu il a définie et peu donc demander à un ou plusieurs fournisseurs d attributs. Dans les cas multi CoTs, cette politique pour définir un rôle est établie suite à des accords définissant les responsabilités de chaque partie. Par exemple, dans le cas Enquête Judiciaire : Au niveau SP Enquête Judiciaire Politique d accès : Les utilisateurs ayant le rôle enquêteur peuvent accéder à la ressource en lecture Rôle enquêteur : (qualification=agent de police judiciaire OU qualification=officier de police judiciaire) ET habilitation=oui Au niveau IDP/AP Police Nationale Les différents attributs sont stockés sur l IDP/AP. Scénario : Jean Dupont fait une demande d accès au SP Enquête Judiciaire SP AP : Donne-moi les attributs qualification et habilitation de Jean Dupont AP SP : qualification=agent de police judiciaire ET habilitation=oui SP User : Accès autorisé Dans ce cas-là, le rôle enquêteur n est pas explicitement défini, le modèle de contrôle d accès utilisé est ABAC. Simplement, la Police aura préalablement déclaré à l opérateur Télécom qu elle mettait à la disposition du service Enquête Judiciaire ces attributs, et qu une personne habilitée par la loi à accéder à ces informations était parfaitement identifiée via ces attributs Cas 2 : rôle avec attributs sensibles Un SP a besoin de savoir si un utilisateur a le rôle adéquat pour lui donner l accès au service, mais ne connaît pas quels attributs l AP utilise pour définir ce rôle. Le SP doit donc demander au fournisseur d attributs si l utilisateur a le rôle adéquat, l AP répondra simplement par un booléen, et ainsi ne divulguera pas les attributs sensibles qu il a regardé pour déterminer si l utilisateur avait le rôle ou non. Par exemple, dans le cas Enquête Judiciaire : Au niveau SP Politique d accès : Les utilisateurs ayant le rôle enquêteur (sur le domaine Police Nationale) peuvent accéder à la ressource en lecture Au niveau AP Les différents attributs sont stockés. 20/48

FEDERATION DES IDENTITES

FEDERATION DES IDENTITES 1 FEDERATION DES IDENTITES Quel protocole de fédération pour quel usage? OAUTH & SAML Fabrice VAZQUEZ Consultant Sécurité du SI +331 73 54 3000 Cabinet de conseil et d expertise technique en sécurité du

Plus en détail

CIBLE DE SECURITE CSPN DU PRODUIT PASS. (Product for Advanced SSO)

CIBLE DE SECURITE CSPN DU PRODUIT PASS. (Product for Advanced SSO) CIBLE DE SECURITE CSPN DU PRODUIT PASS (Product for Advanced SSO) Préparé pour : ANSSI Préparé par: Thales Communications & Security S.A. 4 Avenue des Louvresses 92622 GENNEVILLIERS CEDEX France This document

Plus en détail

Cédric Ouvry Bibliothèque nationale de France Liberty Alliance Deployment Workshop Paris December 7, 2005

Cédric Ouvry Bibliothèque nationale de France Liberty Alliance Deployment Workshop Paris December 7, 2005 Web SSO SAML Liberty Cédric Ouvry Bibliothèque nationale de France Liberty Alliance Deployment Workshop Paris December 7, 2005 PLAN Cas d utilisation Déploiement du toolkit Introduction Production depuis

Plus en détail

Support de SAML2 dans LemonLDAP::NG. Clément OUDOT. Mercredi 7 juillet 2010

Support de SAML2 dans LemonLDAP::NG. Clément OUDOT. Mercredi 7 juillet 2010 Support de SAML2 dans LemonLDAP::NG Clément OUDOT Mercredi 7 juillet 2010 SOMMAIRE Enjeux et usages du SSO Présentation de LemonLDAP::NG SAML2 et la fédération d'identités Support SAML2 dans LemonLDAP::NG

Plus en détail

Introduction. aux architectures web. de Single Sign-On

Introduction. aux architectures web. de Single Sign-On Introduction aux architectures web de Single Sign-On Single Sign-on Authentifier 1 seule fois un utilisateur pour accéder à un ensemble d applications contexte web Nombre croissant d applications ayant

Plus en détail

Qu'est ce qu'une Fédération d'identités? Définitions Fonctionnement de base Fonctionnement détaillé Les principaux composants

Qu'est ce qu'une Fédération d'identités? Définitions Fonctionnement de base Fonctionnement détaillé Les principaux composants Qu'est ce qu'une Fédération d'identités? Définitions Fonctionnement de base Fonctionnement détaillé Les principaux composants Fédération Définit un cercle de confiance constitué de Fournisseurs d'identités

Plus en détail

Single Sign On. Nicolas Dewaele. Single Sign On. Page 1. et Web SSO

Single Sign On. Nicolas Dewaele. Single Sign On. Page 1. et Web SSO Page 1 Introduction Sommaire I- Présentation de la technologie II- Architectures classiques et étude du marché III- Implémentation en entreprise IV- Présentation de systèmes SSO Annexes Page 2 Introduction

Plus en détail

DESCRIPTION DU COMPOSANT

DESCRIPTION DU COMPOSANT Gestion des utilisateurs et des accès Composant pour un Egov intégré Qu'est-ce qu'un composant? C est un élément indispensable à l intégration des systèmes e-gov des différents niveaux politiques. Cet

Plus en détail

LemonLDAP::NG / SAML2. Xavier GUIMARD (Gendarmerie Nationale) Clément OUDOT (Groupe LINAGORA) WWW.LINAGORA.COM

LemonLDAP::NG / SAML2. Xavier GUIMARD (Gendarmerie Nationale) Clément OUDOT (Groupe LINAGORA) WWW.LINAGORA.COM LemonLDAP::NG / SAML2 Xavier GUIMARD (Gendarmerie Nationale) Clément OUDOT (Groupe LINAGORA) WWW.LINAGORA.COM 16, 17 et 18 MARS 2010 SOMMAIRE Définition du WebSSO Présentation de LemonLDAP::NG SAML2 et

Plus en détail

CONVENTION D'UTILISATION FAS

CONVENTION D'UTILISATION FAS CONVENTION D'UTILISATION Objectif du document : Une convention d'utilisation est un contrat spécifique à un service qui stipule les conditions liées à l'utilisation d'un service spécifique de Fedict. Il

Plus en détail

Ce document décrit une solution de single sign-on (SSO) sécurisée permettant d accéder à Microsoft Exchange avec des tablettes ou smartphones.

Ce document décrit une solution de single sign-on (SSO) sécurisée permettant d accéder à Microsoft Exchange avec des tablettes ou smartphones. PERSPECTIVES Le Single Sign-On mobile vers Microsoft Exchange avec OWA et ActiveSync Ce document décrit une solution de single sign-on (SSO) sécurisée permettant d accéder à Microsoft Exchange avec des

Plus en détail

Sécurisation d un espace collaboratif. Romain Laborde

Sécurisation d un espace collaboratif. Romain Laborde Sécurisation d un espace collaboratif Romain Laborde 26 septembre 2007 Plan Le concept d organisation virtuelle Introduction Contraintes Etude de cas définie dans le cadre d une coopération en le projet

Plus en détail

Cahier des charges des dispositifs de télétransmission des actes soumis au contrôle de légalité. Annexe 2 : sécurisation des échanges

Cahier des charges des dispositifs de télétransmission des actes soumis au contrôle de légalité. Annexe 2 : sécurisation des échanges Cahier des charges des dispositifs de télétransmission des actes Annexe 2 : sécurisation des échanges Page 2 / 7 1. OBJET DU DOCUMENT...3 2. PRINCIPES...3 3. SÉCURISATION DES DÉPÔTS DE FICHIERS SUR LES

Plus en détail

Profil de protection d un logiciel d ingénierie

Profil de protection d un logiciel d ingénierie Version 1.0 moyen-terme GTCSI 11 septembre 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant qui est l objet de l évaluation. 1 Descriptif

Plus en détail

OASIS www.oasis-open.org/committees/xacml/docs/docs.shtml Date de publication

OASIS www.oasis-open.org/committees/xacml/docs/docs.shtml Date de publication Statut du Committee Working Draft document Titre XACML Language Proposal, version 0.8 (XACML : XML Access Control Markup Language) Langage de balisage du contrôle d'accès Mot clé Attestation et sécurité

Plus en détail

PASS v2.0 : solution d authentification unique basée sur les composants Shibboleth Service Provider v2.5.1 et Identity Provider v2.3.

PASS v2.0 : solution d authentification unique basée sur les composants Shibboleth Service Provider v2.5.1 et Identity Provider v2.3. PREM IE R M IN IS T R E Secrétariat général de la défense et de la sécurité nationale Agence nationale de la sécurité des systèmes d information PASS v2.0 : solution d authentification unique basée sur

Plus en détail

Application des Spécifications détaillées pour la Retraite, architecture portail à portail

Application des Spécifications détaillées pour la Retraite, architecture portail à portail Pour Application des Spécifications détaillées pour la Retraite, architecture portail à portail Version 1.0 ON-X S.A. est une société du Groupe ON-X 15, quai Dion Bouton 92816 PUTEAUX cedex. Tél : 01 40

Plus en détail

Formation SSO / Fédération

Formation SSO / Fédération Formation SSO / Fédération CYRIL GROSJEAN (cgrosjean@janua.fr) CONSULTANT JANUA Agenda Objectifs du SSO Terminologie, acronymes et protocoles Présentation d'architectures de SSO Présentation d'architectures

Plus en détail

Conformité PCI DSS. Réduire les risques en gérant les identités et les accès. white paper

Conformité PCI DSS. Réduire les risques en gérant les identités et les accès. white paper Conformité PCI DSS Réduire les risques en gérant les identités et les accès Ce livre blanc explique comment la suite IAM d Evidian peut vous aider à vous conformer aux exigences PCI DSS. white paper 39

Plus en détail

Ministère de l éducation nationale, de l enseignement supérieur et de la recherche 07/11/2006

Ministère de l éducation nationale, de l enseignement supérieur et de la recherche 07/11/2006 Schéma directeur des espaces numériques de travail Annexe AAS Authentification-Autorisation-SSO Version 2.0 SOMMAIRE 1. Introduction... 3 1.1 Contexte... 3 1.2 Objectifs et contenu du document... 4 1.3

Plus en détail

Fiches micro-informatique SECURITE LOGIQUE LOGIxx

Fiches micro-informatique SECURITE LOGIQUE LOGIxx Objectif Fiches micro-informatique SECURITE LOGIQUE LOGIxx Présenter des préconisations pour sécuriser le poste de travail informatique et son environnement sous forme de fiches pratiques. Public concerné

Plus en détail

Solutions Microsoft Identity and Access

Solutions Microsoft Identity and Access Solutions Microsoft Identity and Access 2 Solutions Microsoft Identity and Access Microsoft Identity and Access (IDA) permet aux entreprises d améliorer leur efficacité et leurs connexions internes et

Plus en détail

TX A081025: Délégation de l authentification pour les Services Web

TX A081025: Délégation de l authentification pour les Services Web TX A081025: Délégation de l authentification pour les Services Web Jérémy Vauchelle Enseignant: Aurélien Bénel Intervenants: Chao Zhou Arnaud Pagnier Plan 1. Présentation du sujet 2. Présentation du protocole

Plus en détail

La construction d un référentiel d identité est au cœur des approches de gestion des identités et des accès.

La construction d un référentiel d identité est au cœur des approches de gestion des identités et des accès. Etat de l art Synchronisation des identités pour un référentiel d identités multi-annuaires La construction d un référentiel d identité est au cœur des approches de gestion des identités et des accès.

Plus en détail

Profil de protection d un pare-feu industriel

Profil de protection d un pare-feu industriel Version 1.0 court-terme GTCSI 13 juillet 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant qui est l objet de l évaluation. Les passages en

Plus en détail

ENVOLE 1.5. Calendrier Envole

ENVOLE 1.5. Calendrier Envole ENVOLE 1.5 Calendrier Envole RSA FIM 1 avril 2008 V 1.13 sur EOLE V 2.0 1 septembre 2008 EOLE V 2.1 10 octobre 2008 V 1.15 RC sur EOLE V 2.0 Modification du SSO EOLE 2.2 (PAM-CAS, CT EOLE V 2.2 RC Prise

Plus en détail

Guide Share France. Web Single Sign On. Panorama des solutions SSO

Guide Share France. Web Single Sign On. Panorama des solutions SSO Web Single Sign On Panorama des solutions SSO Agenda Concepts généraux Quelques solutions de Web SSO Questions & Réponses Définition Qu est-ce que le Single Sign-On? Solution visant à minimiser le nombre

Plus en détail

La fédération d identités, pourquoi et comment? Olivier Salaün, RENATER ANF Mathrice 2014

La fédération d identités, pourquoi et comment? Olivier Salaün, RENATER ANF Mathrice 2014 La fédération d identités, pourquoi et comment? Olivier Salaün, RENATER ANF Mathrice 2014 25/09/2014 1 RENATER Opérateur du réseau enseignement et recherche Sécurité Le CERT RENATER Animation réseau des

Plus en détail

Tour d horizon des différents SSO disponibles

Tour d horizon des différents SSO disponibles Tour d horizon des différents SSO disponibles L. Facq, P. Depouilly, B. Métrot, R. Ferrere ANF Les systèmes d authentification dans la communauté ESR : étude, mise en oeuvre et interfaçage dans un laboratoire

Plus en détail

Fédération du CRU pour la propagation d identités et d attributs

Fédération du CRU pour la propagation d identités et d attributs Fédération du CRU pour la propagation d identités et d attributs ou «Comment partager des ressources web entre établissements d enseignement supérieur» 1/47 1 Plan de la présentation 1. Problématique :

Plus en détail

Shibboleth. David Verdin - JOSY "Authentification centralisée pour les applications web" - Paris - 4 février 2010. 5 mai 2010 1

Shibboleth. David Verdin - JOSY Authentification centralisée pour les applications web - Paris - 4 février 2010. 5 mai 2010 1 Shibboleth David Verdin - JOSY "Authentification centralisée pour les applications web" - Paris - 4 février 2010 5 mai 2010 1 Plan de l'exposé Position du problème L'architecture de Shibboleth Shibboleth

Plus en détail

Les technologies de gestion de l identité

Les technologies de gestion de l identité Commission Identité Numérique Groupe de travail Gestion des identités Les technologies de gestion de l identité ATELIER 1 Paul TREVITHICK, CEO de Parity Responsable projet Higgins Président Fondation Infocard

Plus en détail

Créer et partager des fichiers

Créer et partager des fichiers Créer et partager des fichiers Le rôle Services de fichiers... 246 Les autorisations de fichiers NTFS... 255 Recherche de comptes d utilisateurs et d ordinateurs dans Active Directory... 262 Délégation

Plus en détail

Profil de protection d une passerelle VPN industrielle

Profil de protection d une passerelle VPN industrielle Profil de protection d une passerelle industrielle Version 1.0 court-terme GTCSI 13 juillet 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant

Plus en détail

CP - NBS System. La sécurité informatique : focus sur les menaces les plus communes et leurs solutions

CP - NBS System. La sécurité informatique : focus sur les menaces les plus communes et leurs solutions La sécurité informatique : focus sur les menaces les plus communes et leurs solutions Nous avons publié en février un article résumant les principaux risques liés au manque de sécurité des sites internet.

Plus en détail

Référentiel Général de Sécurité. version 2.0. Annexe A1

Référentiel Général de Sécurité. version 2.0. Annexe A1 Premier ministre Agence nationale de la sécurité des systèmes d information (ANSSI) Secrétariat général pour la modernisation de l action publique (SGMAP) Référentiel Général de Sécurité version 2.0 Annexe

Plus en détail

Sécurisation des architectures traditionnelles et des SOA

Sécurisation des architectures traditionnelles et des SOA Sécurisation des architectures traditionnelles et des SOA Un livre blanc de Bull Evidian Gestion SAML des accès SSO aux applications classiques et J2EE. Max Vallot Sommaire Émergence des architectures

Plus en détail

Application des Spécifications détaillées pour le RNIAM, architecture portail à portail

Application des Spécifications détaillées pour le RNIAM, architecture portail à portail Pour Application des Spécifications détaillées pour le RNIAM, architecture portail à portail Version 1.0 ON-X S.A. est une société du Groupe ON-X 15, quai Dion Bouton 92816 PUTEAUX cedex. Tél : 01 40 99

Plus en détail

FICHE N 10 SÉCURITÉ DES DONNÉES

FICHE N 10 SÉCURITÉ DES DONNÉES L article 34 de la loi «Informatique et Libertés» impose à un responsable de traitement de prendre toutes les précautions utiles pour préserver la sécurité des données dont il est responsable, en fonction

Plus en détail

Authentification et contrôle d'accès dans les applications web

Authentification et contrôle d'accès dans les applications web Authentification et contrôle d'accès dans les applications web Quelques Rappels Objectifs : contrôler que seulement Certains utilisateurs Exécutent certaines opérations Sur certains objets Trois entités

Plus en détail

Cible de sécurité CSPN

Cible de sécurité CSPN Cible de sécurité CSPN ClearBUS Application cliente pour la communication sécurisée Version 1.12 Le 25/11/2011 Identifiant : CBUS-CS-1.12-20111125 contact@clearbus.fr tel : +33(0)485.029.634 Version 1.12

Plus en détail

Règlement pour les fournisseurs de SuisseID

Règlement pour les fournisseurs de SuisseID Règlement pour les fournisseurs de SuisseID Version 1.0c du 4 novembre 2010 Règlement pour fournisseurs de SuisselD Nom Numéro de standard Catégorie Degré de maturité Règlement pour les fournisseurs de

Plus en détail

Dossier Technique. Détail des modifications apportées à GRR. Détail des modifications apportées à GRR Le 17/07/2008. Page 1/10

Dossier Technique. Détail des modifications apportées à GRR. Détail des modifications apportées à GRR Le 17/07/2008. Page 1/10 Dossier Technique Page 1/10 Sommaire : 1. REPONSE TECHNIQUE A LA DEMANDE 3 1.1. Prise en compte de la dernière version de phpcas 3 1.2. Gestion de la connexion à GRR 3 1.2.1. Récupération des attributs

Plus en détail

WebSSO, synchronisation et contrôle des accès via LDAP

WebSSO, synchronisation et contrôle des accès via LDAP 31 mars, 1er et 2 avril 2009 WebSSO, synchronisation et contrôle des accès via LDAP Clément Oudot Thomas Chemineau Sommaire général Synchronisation d'identités WebSSO et contrôle des accès Démonstration

Plus en détail

La suite logicielle Lin ID. Paris Capitale du Libre 25 septembre 2008

La suite logicielle Lin ID. Paris Capitale du Libre 25 septembre 2008 La suite logicielle Lin ID Paris Capitale du Libre 25 septembre 2008 Pourquoi Lin ID? Le domaine de la gestion des identités est vaste et complexe L'offre logicielle est réduite, dominée par quelques grands

Plus en détail

Ministère des affaires sociales. Direction Générale de la Santé (DGS) Dématérialisation des certificats de l enfant

Ministère des affaires sociales. Direction Générale de la Santé (DGS) Dématérialisation des certificats de l enfant Ministère des affaires sociales Direction Générale de la Santé (DGS) Dématérialisation des certificats de l enfant Spécifications fonctionnelles détaillées Date : 14/04/2014 Version : V0.2.1 Classification

Plus en détail

Profil de protection d un progiciel serveur applicatif MES

Profil de protection d un progiciel serveur applicatif MES Profil de protection d un progiciel serveur applicatif MES Version 1.0 court-terme GTCSI 1 er juillet 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne

Plus en détail

Evidian Secure Access Manager Standard Edition

Evidian Secure Access Manager Standard Edition Evidian Secure Access Manager Standard Edition LDAP SSO un contrôle d accès modulaire et extensible - V 1.1 Par Dominique Castan dominique.castan@evidian.com et Michel Bastien michel.bastien@evidian.com

Plus en détail

Comment utiliser mon compte alumni?

Comment utiliser mon compte alumni? Ce document dispose d une version PDF sur le site public du CI Comment utiliser mon compte alumni? Elena Fascilla, le 23/06/2010 Sommaire 1. Introduction... 2 2. Avant de commencer... 2 2.1 Connexion...

Plus en détail

La gestion des identités au CNRS Le projet Janus

La gestion des identités au CNRS Le projet Janus La gestion des identités au CNRS Le projet Janus Claude Gross CNRS/UREC Janus : les origines Fin 2007 : Annonce de l ouverture d un service ouvert à toutes les unités CNRS Besoin d une solution d authentification

Plus en détail

IGC Infrastructure de gestion de la confiance. Serge.Aumont@cru.fr florent.guilleux@cru.fr. JTO décembre 2002

IGC Infrastructure de gestion de la confiance. Serge.Aumont@cru.fr florent.guilleux@cru.fr. JTO décembre 2002 IGC Infrastructure de gestion de la confiance. Serge.Aumont@cru.fr florent.guilleux@cru.fr JTO décembre 2002 Chiffrement asymétrique Confidentialité d un message : le chiffrer avec la clé publique du destinataire.

Plus en détail

Séminaire EOLE Dijon 23/24 novembre 2011. Architecture Envole/EoleSSO

Séminaire EOLE Dijon 23/24 novembre 2011. Architecture Envole/EoleSSO Séminaire EOLE Dijon 23/24 novembre 2011 Architecture Envole/EoleSSO Sommaire Présentation du socle Envole EoleSSO : modes de fonctionnement Fédération et gestion des annuaires Accès aux services académiques

Plus en détail

Un exemple d'authentification sécurisée utilisant les outils du Web : CAS. P-F. Bonnefoi

Un exemple d'authentification sécurisée utilisant les outils du Web : CAS. P-F. Bonnefoi Un exemple d'authentification sécurisée utilisant les outils du Web : CAS 111 L authentification CAS : «Central Authentication Service» CAS ou le service central d authentification Le système CAS, développé

Plus en détail

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE MINISTÈRE DU TRAVAIL, DE l EMPLOI ET DE LA SANTÉ MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE MINISTÈRE DU BUDGET, DES COMPTES PUBLICS ET DE LA RÉFORME DE L ÉTAT Spécifications détaillées du mode

Plus en détail

PCI (Payment Card Industry) DSS (Data Security Standard )

PCI (Payment Card Industry) DSS (Data Security Standard ) PCI (Payment Card Industry) DSS (Data Security Standard ) Jean-Marc Robert Génie logiciel et des TI PCI-DSS La norme PCI (Payment Card Industry) DSS (Data Security Standard) a été développée dans le but

Plus en détail

A. Introduction. Chapitre 4. - les entités de sécurité ; - les sécurisables ; - les autorisations.

A. Introduction. Chapitre 4. - les entités de sécurité ; - les sécurisables ; - les autorisations. Chapitre 4 A. Introduction Le contrôle d'accès représente une opération importante au niveau de la gestion de la sécurité sur un serveur de bases de données. La sécurisation des données nécessite une organisation

Plus en détail

Création d un catalogue en ligne

Création d un catalogue en ligne 5 Création d un catalogue en ligne Au sommaire de ce chapitre Fonctionnement théorique Définition de jeux d enregistrements Insertion de contenu dynamique Aperçu des données Finalisation de la page de

Plus en détail

Windows Server 2008. Chapitre 3 : Le service d annuaire Active Directory: Concepts de base

Windows Server 2008. Chapitre 3 : Le service d annuaire Active Directory: Concepts de base Windows Server 2008 Chapitre 3 : Le service d annuaire Active Directory: Concepts de base omar.cheikhrouhou@isetsf.rnu.tn omar.cheikhrouhou@ceslab.org Objectives Comprendre les concepts de base d Active

Plus en détail

DOCUMENTATION DU COMPAGNON ASP

DOCUMENTATION DU COMPAGNON ASP DOCUMENTATION DU COMPAGNON ASP MANUEL UTILISATEUR VERSION 1.0 / SEPTEMBRE 2011 Rédacteur Gilles Mankowski 19/09/2011 Chapitre : Pre requis CONTENU Pre requis... 3 Introduction... 3 Comment fonctionne l'asp?...

Plus en détail

Dispositif assurant le filtrage des accès aux ressources électroniques via un annuaire LDAP

Dispositif assurant le filtrage des accès aux ressources électroniques via un annuaire LDAP Dispositif assurant le filtrage des accès aux ressources électroniques via un annuaire LDAP Document révisé en Mars 2006 Introduction, historique et rappels Le filtrage des accès aux ressources électroniques

Plus en détail

plate-forme PaaS (Autorisation)

plate-forme PaaS (Autorisation) Contrôle d accès dans une plate-forme PaaS (Autorisation) Ahmed BOUCHAMI, Olivier PERRIN, LORIA Introduction Avec le développement du cloud-computing et des réseaux sociaux, la collaboration est devenue

Plus en détail

Fédérer les identités et développer leurs usages dans de nouveaux contextes

Fédérer les identités et développer leurs usages dans de nouveaux contextes Track 2 : Fédérer les identités et développer leurs usages dans de nouveaux contextes Symposium International de la Transaction Electronique Sécurisée 11 et 12 Juin 2008 Rabat, Maroc 1. Introduction Le

Plus en détail

Manuel d utilisation V1.2.0

Manuel d utilisation V1.2.0 Manuel d utilisation V1.2.0 Manuel d utilisation DscBox Sommaire Manuel d utilisation DscBox... 2 Introduction... 3 Les acteurs de la dscbox... 3 Intégration du boitier dans un réseau existant... 3 Fonctionnalités

Plus en détail

Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE

Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE sommaire MIEUX COMPRENDRE LES CERTIFICATS SSL...1 SSL et certificats SSL : définition...1

Plus en détail

Les nouveautés en UCOPIA Version 5.0

Les nouveautés en UCOPIA Version 5.0 Les nouveautés en UCOPIA Version 5.0 Pour mieux répondre aux besoins de nos clients, UCOPIA sort la toute dernière version de la solution, disponible dès septembre 2014. Chaque evolution dans cette version

Plus en détail

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE MINISTÈRE DU TRAVAIL, DE l EMPLOI ET DE LA SANTÉ MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE MINISTÈRE DU BUDGET, DES COMPTES PUBLICS ET DE LA RÉFORME DE L ÉTAT Standard d'interopérabilité entre

Plus en détail

Gestion des utilisateurs et Entreprise Etendue

Gestion des utilisateurs et Entreprise Etendue Gestion des utilisateurs et Entreprise Etendue Laurent Ruyssen 6 rue Beaubourg - 75004 PARIS T 1 44 59 93 00 F 1 44 59 93 09 yphise@yphise.com - http://yphise.fr GUEE0009-1 Agenda Entreprise Etendue Mission

Plus en détail

BULK SMS Envoi en masse d un message texte moyennant un téléphone mobile (GSM)

BULK SMS Envoi en masse d un message texte moyennant un téléphone mobile (GSM) Ministère de l Enseignement Supérieur et de la Recherche Scientifique Ecole Supérieure Privée d Ingénierie et de Technologie BULK SMS Envoi en masse d un message texte moyennant un téléphone mobile (GSM)

Plus en détail

GUIDE DE DEMARRAGE SP Plus

GUIDE DE DEMARRAGE SP Plus GUIDE DE DEMARRAGE SP Plus Secteur public Version 1.2 31/08/2011 Ce document et son contenu sont strictement confidentiels et la propriété de Natixis Paiements. Il n est pas contractuel. Toute reproduction

Plus en détail

RÉFÉRENTIEL SUR LA SÉCURITÉ DES TITRES CHEQUES EMPLOI-SERVICE UNIVERSELS

RÉFÉRENTIEL SUR LA SÉCURITÉ DES TITRES CHEQUES EMPLOI-SERVICE UNIVERSELS RÉFÉRENTIEL SUR LA SÉCURITÉ DES TITRES CHEQUES EMPLOI-SERVICE UNIVERSELS Février 2015 SOMMAIRE 1. INTRODUCTION... 3 2. PÉRIMÈTRE... 4 3. MISE EN OEUVRE... 5 4. PRÉSENTATION DES OBJECTIFS DE SÉCURITÉ...

Plus en détail

C. Configuration des services de transport

C. Configuration des services de transport Page 282 Chapitre 8 Dans la version 2013 d'exchange, les dossiers publics sont devenus un type de boîtes aux lettres et utilisent les mêmes mécanismes de routage que les e-mails. - Le message est destiné

Plus en détail

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE MINISTÈRE DU TRAVAIL, DE l EMPLOI ET DE LA SANTÉ MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE MINISTÈRE DU BUDGET, DES COMPTES PUBLICS ET DE LA RÉFORME DE L ÉTAT Spécifications fonctionnelles et

Plus en détail

CONTRAT DE SOUSCRIPTION OFFRE PUSH-CLASSIQUE

CONTRAT DE SOUSCRIPTION OFFRE PUSH-CLASSIQUE CONTRAT DE SOUSCRIPTION OFFRE PUSH-CLASSIQUE ANNEXE 5 : CONDITIONS SPECIFIQUES AUX APPLICATIONS DE CAT. 3 V7.0 () Bouygues Telecom Société anonyme au capital de 616 661 789.28, immatriculée au RCS Nanterre

Plus en détail

Authentifications à W4 Engine en.net (SSO)

Authentifications à W4 Engine en.net (SSO) Note technique W4 Engine Authentifications à W4 Engine en.net (SSO) Cette note technique a pour but d expliquer le mécanisme de fonctionnement de la connexion des utilisateurs à W4 Engine, notamment lorsque

Plus en détail

Sécurisation du réseau

Sécurisation du réseau Sécurisation du réseau La sécurisation du réseau d entreprise est également une étape primordiale à la sécurisation générale de votre infrastructure. Cette partie a pour but de présenter les fonctionnalités

Plus en détail

Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup

Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup Serveur d intégration continue Jenkins et d analyse de code Sonar couplés à la forge logiciel SourceSup Sébastien MEDARD GIP RENATER 263 avenue du Général Leclerc CS 74205 35042 Rennes Cedex Résumé L intégration

Plus en détail

Projet de Système d Information National (SIN) SAMU Grippe A H1N1 / Déploiement dans les SAMU Centre 15

Projet de Système d Information National (SIN) SAMU Grippe A H1N1 / Déploiement dans les SAMU Centre 15 Projet de Système d Information National (SIN) SAMU Grippe A H1N1 Déploiement dans les SAMU-Centre 15 Mission de préfiguration ASIP 9, rue Georges Pitard 75 015 Paris Tél 01 58 45 32 50 Fax 01 58 45 33

Plus en détail

Systeme d authentification biometrique et de transfert de donnees cryptees

Systeme d authentification biometrique et de transfert de donnees cryptees Systeme d authentification biometrique et de transfert de donnees cryptees Securisez vos acces et protegez vos donnees Les composants ActiveX développés par NetInf associés aux produits de sécurisation

Plus en détail

educa.id Gestion d'identité et d'accès

educa.id Gestion d'identité et d'accès educa.id Gestion d'identité et d'accès Jürg Gasser Michael Deichmann Chef de projet Responsable du groupe Dévelop. TIC et support Sommaire Vue d'ensemble Démonstration Fonctions utilisateur Principes de

Plus en détail

Avertissement. Nom du stagiaire : Modification et utilisation interdites sans l accord de l auteur de ce support.

Avertissement. Nom du stagiaire : Modification et utilisation interdites sans l accord de l auteur de ce support. Reproduction et utilisation interdites sans l accord de l auteur Support de formation Administration Windows 2000 Server Avertissement Ce support n est ni un manuel d utilisation (pour cela, consultez

Plus en détail

La vie privée dans les environnements fédérés

La vie privée dans les environnements fédérés La vie privée dans les environnements fédérés Kheira BEKARA, Maryline LAURENT Institut Télécom, Télécom SudParis, SAMOVAR UMR 5157, 9 rue Charles Fourier, 91011 Evry, France Cet article présente la problématique

Plus en détail

Gestion de l'annuaire pour l'administrateur ENT. V1.2 décembre 2010

Gestion de l'annuaire pour l'administrateur ENT. V1.2 décembre 2010 Gestion de l'annuaire pour l'administrateur ENT V1.2 décembre 2010 I N D E X INTRODUCTION... 4 I. PRINCIPES DE FONCTIONNEMENT... 5 II. GESTION DES IDENTIFIANTS (LOGINS) ET DES MOTS DE PASSE UTILISATEURS...

Plus en détail

Manuel Bucom Version 3.1 Octobre 2008

Manuel Bucom Version 3.1 Octobre 2008 Manuel Bucom Version 3.1 Octobre 2008 Table des matières 1. LES DIFFÉRENTS ACTEURS DU USER MANAGEMENT ET LEURS DROITS...4 1.1. RESPONSABLE ACCES ENTREPRISE ET CO-RESPONSABLE ACCES ENTREPRISE...4 1.1.1.

Plus en détail

RECOMMANDATIONS DE SECURITE

RECOMMANDATIONS DE SECURITE PREMIER MINISTRE Secrétariat général de la défense et de la sécurité nationale Agence nationale de la sécurité des systèmes d information Paris, le 14 février 2013 N 524/ANSSI/SDE RECOMMANDATIONS DE SECURITE

Plus en détail

Table des matières. Préface... 15 Mathieu JEANDRON

Table des matières. Préface... 15 Mathieu JEANDRON Table des matières Préface... 15 Mathieu JEANDRON Chapitre 1. Les identités numériques... 19 Maryline LAURENT, Julie DENOUËL, Claire LEVALLOIS-BARTH et Patrick WAELBROECK 1.1. Introduction... 19 1.2. Dimension

Plus en détail

REAUMUR-ACO-PRES. Wifi : Point et perspectives

REAUMUR-ACO-PRES. Wifi : Point et perspectives REAUMUR-ACO-PRES Wifi : Point et perspectives 26 Octobre 2005 www.reaumur.net REseau Aquitain des Utilisateurs des Milieux Universitaire et de Recherche Version du 11/06/2006 09:03:32 1 26/10/2005 REAUMUR-ACO

Plus en détail

BIG DATA Jeudi 22 mars 2012

BIG DATA Jeudi 22 mars 2012 BIG DATA Jeudi 22 mars 2012 87 boulevard de Courcelles 75008 PARIS Tel :01.56.43.68.80 Fax : 01.40.75.01.96 contact@haas-avocats.com www.haas-avocats.com www.jurilexblog.com 1 2012 Haas société d Avocats

Plus en détail

Mise en place d un intranet de travail collaboratif. Guide utilisateur

Mise en place d un intranet de travail collaboratif. Guide utilisateur Mise en place d un intranet de travail collaboratif Guide utilisateur 03/05/2010 Sommaire 1. Introduction... 4 2. Premier contact avec Le portail... 4 2.1 Se connecter au portail.... 4 2.1.1 Inscription

Plus en détail

Interconnexion de la plateforme LinkedIn avec l eportfolio Mahara

Interconnexion de la plateforme LinkedIn avec l eportfolio Mahara Interconnexion de la plateforme LinkedIn avec l eportfolio Mahara D 1.3.3 Prototype Auteurs: Johann Luethi, Patrick Roth Projet Learning Infrastructure 2013 Work Package 1.3 - Integration of 3rd party

Plus en détail

Présentation SafeNet Authentication Service (SAS) Octobre 2013

Présentation SafeNet Authentication Service (SAS) Octobre 2013 Bâtir un environnement d'authentification très fiable Présentation SafeNet Authentication Service (SAS) Octobre 2013 Insérez votre nom Insérez votre titre Insérez la date 1 Présentation de l offre SAS

Plus en détail

Clément OUDOT LINAGORA

Clément OUDOT LINAGORA Clément OUDOT LINAGORA Sommaire Gestion et Fédération des identités Le projet FederID ANR InterLDAP Le logiciel FederID La gestion des identités Une personne (identité physique) possède une ou plusieurs

Plus en détail

Charte pour l usage de ressources informatiques et de services Internet

Charte pour l usage de ressources informatiques et de services Internet Prénom Nom : Signature : Date : Service : Charte pour l usage de ressources informatiques et de services Internet Ce texte, associé au règlement intérieur des entités, a pour objet de préciser la responsabilité

Plus en détail

arcopole Studio Annexe 7 Architectures Site du programme arcopole : www.arcopole.fr

arcopole Studio Annexe 7 Architectures Site du programme arcopole : www.arcopole.fr 4 arcopole Studio Annexe 7 Architectures Site du programme arcopole : www.arcopole.fr Auteur du document : Esri France Version de la documentation : 1.2 Date de dernière mise à jour : 26/02/2015 Sommaire

Plus en détail

Business Central Wireless Manager

Business Central Wireless Manager Business Central Wireless Manager Guide de présentation Sommaire CATÉGORIE DE PRODUIT... 3 PRÉSENTATION... 3 PRÉSENTATION DE BUSINESS CENTRAL... 3 FONCTIONNALITÉS ET ATOUTS... 4 POINTS D ACCÈS WIFI PRIS

Plus en détail

WebFTP Un client Web sécurisé pour FTP

WebFTP Un client Web sécurisé pour FTP WebFTP Un client Web sécurisé pour FTP Jirung Albert SHIH, Shih@math.Jussieu.fr Université Paris 7 JRES 2001 Introduction Nous allons dans ce document présenter une solution mise en œuvre sur le réseau

Plus en détail

CHARTE INFORMATIQUE LGL

CHARTE INFORMATIQUE LGL CHARTE INFORMATIQUE LGL Selon la réglementation indiquée dans la charte informatique du CNRS, tout accès aux ressources informatiques du LGLTPE nécessite une authentification des personnels. Cette authentification

Plus en détail

FONCTIONS CLEFS. Gestion documentaire. Chaîne de validation des documents. Espaces de travail collaboratif. Gestion des accès basée sur des rôles

FONCTIONS CLEFS. Gestion documentaire. Chaîne de validation des documents. Espaces de travail collaboratif. Gestion des accès basée sur des rôles Nuxeo Collaborative Portal Server 1 FONCTIONS CLEFS Gestion documentaire Chaîne de validation des documents Espaces de travail collaboratif Gestion des accès basée sur des rôles Sécurité Suivi des versions

Plus en détail

PROFIL PERSONNEL GUIDE DE L UTILISATEUR

PROFIL PERSONNEL GUIDE DE L UTILISATEUR PROFIL PERSONNEL GUIDE DE L UTILISATEUR Mis à jour le 25 septembre 2008 TABLE DES MATIÈRES 1. UN NOUVEAU SERVICE... 1 Personnalisé... 1 Sécuritaire... 1 Complémentaire... 1 2. ENREGISTREMENT ET AUTHENTIFICATION...

Plus en détail

WIFI sécurisé en entreprise (sur un Active Directory 2008)

WIFI sécurisé en entreprise (sur un Active Directory 2008) Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Paternité - Pas d'utilisation Commerciale 3.0 non transposé. Le document est librement diffusable dans le contexte de

Plus en détail