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

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

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

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

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

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

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

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

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

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

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

Conditions générales d hébergement de l application La-Vie-Scolaire.fr

Conditions générales d hébergement de l application La-Vie-Scolaire.fr de l application La-Vie-Scolaire.fr Référence :.. Date : Définitions «Contrat d accès au Service» : désigne le bon de commande, les conditions générales de vente et les éventuels annexes ou avenants conclus

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

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

PRESENTATION D INTEROPS

PRESENTATION D INTEROPS PRESENTATION D INTEROPS Nom Organisme Date Rédaction GT Technique Interops Validation Approbation Document applicable à compter du Identification du document Direction Objet Domaine Nature N d ordre Version

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

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

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

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

Plateforme AnaXagora. Guide d utilisation

Plateforme AnaXagora. Guide d utilisation Table des matières 1. PRESENTATION DE LA PLATE-FORME D APPRENTISSAGE ANAXAGORA... 3 2. ARCHITECTURE FONCTIONNELLE... 4 3. L APPRENTISSAGE... 5 3.1. L ESPACE DE TRAVAIL... 5 3.1.1. Le calendrier... 5 4.

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

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

GUIDE D'UTILISATION DU PORTAIL IAM

GUIDE D'UTILISATION DU PORTAIL IAM GUIDE D'UTILISATION DU PORTAIL IAM CONNEXION ET UTILISATION IAM Table des matières Généralités... 3 Objectifs du document... 3 Évolutions du portail... 3 Signaler un INCIDENT demander du support Contacter

Plus en détail

Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA

Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA 1- Introduction 1.1 Présentation générale Ce document définit les Conditions Générales d Utilisation (CGU) des certificats délivrés dans le cadre

Plus en détail

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+ Guide de formation avec exercices pratiques Configuration et dépannage de PC Préparation à la certification A+ Sophie Lange Troisième édition : couvre Windows 2000, Windows XP et Windows Vista Les Guides

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

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

OASIS est une fabrique à bien commun via l utilisation des applications proposées sur son store.

OASIS est une fabrique à bien commun via l utilisation des applications proposées sur son store. Guide Utilisateur 1.1 Présentation d OASIS OASIS est une fabrique à bien commun via l utilisation des applications proposées sur son store. Grâce à OASIS, vous serez capable d acheter ou de choisir des

Plus en détail

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

Cryptographie. Cours 6/8 - Gestion de clés

Cryptographie. Cours 6/8 - Gestion de clés Cryptographie Cours 6/8 - Gestion de clés Plan du cours Importance de la gestion des clés Clés secrètes, clés publiques Certificats Infrastructure à clé publique (Public Key Infrastructure, PKI) Dans le

Plus en détail

Projet Magistère: SSL

Projet Magistère: SSL Université Joseph Fourier, IMA Janvier 2010 Table des matières 1 Introduction 2 Qu est ce que SSL? 3 Historique de SSL/TLS 4 Théorie à propos du fonctionnement de SSL 5 Structure d un certificat 6 SSL

Plus en détail

Définition. Caractéristiques. - Du partage des ressources : espace de stockage, imprimantes, lignes de communication.

Définition. Caractéristiques. - Du partage des ressources : espace de stockage, imprimantes, lignes de communication. CONNECTER LES SYSTEMES ENTRE EUX L informatique, au cœur des tâches courantes, a permis de nombreuses avancées technologiques. Aujourd hui, la problématique est de parvenir à connecter les systèmes d information

Plus en détail

arcopole Studio Annexe 4 Intégration LDAP et processus d authentification Site du programme arcopole : www.arcopole.fr

arcopole Studio Annexe 4 Intégration LDAP et processus d authentification Site du programme arcopole : www.arcopole.fr arcopole Studio Annexe 4 Intégration LDAP et processus d authentification Site du programme arcopole : www.arcopole.fr Auteur du document : ESRI France Version de la documentation : 1.2.0.0 Date de dernière

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

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

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

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

www.lafamily.ch en 16 différences

www.lafamily.ch en 16 différences Cas d étude no 3 www.lafamily.ch en 16 différences juin 2003 Le mandat réalisé avec QuickSite de transformation du site existant de Lafamily.ch, centre globale d information pour les familles, à été de

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

Description de la maquette fonctionnelle. Nombre de pages :

Description de la maquette fonctionnelle. Nombre de pages : Description de la maquette fonctionnelle Nombre de pages : 22/07/2008 STATUT DU DOCUMENT Statut Date Intervenant(s) / Fonction Provisoire 22/07/2008 Approuvé Validé HISTORIQUE DES MODIFICATIONSICATIONS

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

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

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

Référentiel Général de Sécurité. version 1.0. Annexe A4

Référentiel Général de Sécurité. version 1.0. Annexe A4 Premier ministre Agence nationale de la sécurité des systèmes d information Ministère du budget, des comptes publics et de la réforme de l État Direction générale de la modernisation de l État Référentiel

Plus en détail

LA GESTION D ASTREINTE White Paper

LA GESTION D ASTREINTE White Paper LA GESTION D ASTREINTE White Paper GENERALITES SUR LA GESTION D ASTREINTE :... 2 POURQUOI METTRE EN PLACE UNE GESTION D ASTREINTE AUTOMATISEE?... 2 LA TRANSMISSION DE L INFORMATION, LE NERF DE LA GESTION

Plus en détail

Solutions de gestion de la sécurité Livre blanc

Solutions de gestion de la sécurité Livre blanc Solutions de gestion de la sécurité Livre blanc L intégration de la gestion des identités et des accès avec l authentification unique Objectif : Renforcer la politique de sécurité et améliorer la productivité

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

Cours CCNA 1. Exercices

Cours CCNA 1. Exercices Cours CCNA 1 TD3 Exercices Exercice 1 Enumérez les sept étapes du processus consistant à convertir les communications de l utilisateur en données. 1. L utilisateur entre les données via une interface matérielle.

Plus en détail

plate-forme PaaS (Audit)

plate-forme PaaS (Audit) Contrôle d accès dans une plate-forme PaaS (Audit) Ahmed BOUCHAMI, Olivier PERRIN, LORIA Introduction La sécurité d une plate-forme collaborative nécessite un module d authentification et un module de

Plus en détail

INTERCONNEXION CARTABLE EN LIGNE / E-SIDOC

INTERCONNEXION CARTABLE EN LIGNE / E-SIDOC INTERCONNEXION CARTABLE EN LIGNE / E-SIDOC 23/11/2014 e-sidoc et Cartable en Ligne Documentation sur les procédures à suivre pour mettre en place l authentification unique entre e-sidoc et l ENT Cartable

Plus en détail

Le Programme d achat en volume pour les entreprises de l App Store

Le Programme d achat en volume pour les entreprises de l App Store Le Programme d achat en volume pour les entreprises de l App Store L App Store comporte des milliers d apps professionnelles conçues pour améliorer la productivité de votre entreprise. Grâce au Programme

Plus en détail

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium dans le cadre du projet JASMINe Avril 2008 Table des matières 1 Introduction 3 1.1 Rappel sur JASMINe.......................................

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

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

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

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

Directive du DFJP sur la mise en place de liaisons en ligne et l octroi d autorisations d accès à des applications informatiques du DFJP

Directive du DFJP sur la mise en place de liaisons en ligne et l octroi d autorisations d accès à des applications informatiques du DFJP Directive du DFJP sur la mise en place de liaisons en ligne et l octroi d autorisations d accès à des applications informatiques du DFJP (Directive du DFJP sur les liaisons en ligne) du 30 septembre 2004

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

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

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

Commission Identité Numérique Groupe de travail Gestion des identités Les usages et les services ATELIER 2

Commission Identité Numérique Groupe de travail Gestion des identités Les usages et les services ATELIER 2 Introduction et cadrage Jean Pierre Buthion, Pdt de la Commission Identités Commission Identité Numérique Groupe de travail Gestion des identités Les usages et les services ATELIER 2 Analyse et synthèse

Plus en détail

Gestion de l Identité Numérique

Gestion de l Identité Numérique Gestion de l Identité Numérique La France veut accélérer et consolider le développement de l Economie numérique, instaurer la confiance numérique et lutter contre la fraude et l usurpation d identité,

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

ACCÈS AUX RESSOURCES NUMÉRIQUES

ACCÈS AUX RESSOURCES NUMÉRIQUES ACCÈS AUX RESSOURCES NUMÉRIQUES Identification, authentification et navigation entre les plateformes et les portails officiels Recommandations de la CORENE Juin 2014 Contenu Bref rappel du dossier... 3

Plus en détail

Utilisation de l application. Introduction à asa-control. Connexion à l application. Plus facile que tu ne le penses.

Utilisation de l application. Introduction à asa-control. Connexion à l application. Plus facile que tu ne le penses. asa-control Introduction à asa-control Utilisation de l application Plus facile que tu ne le penses. Tu travailles avec la souris et effectues toujours les mêmes étapes. Connexion à l application Choisis

Plus en détail

Convention d adhésion à la fédération d identités marocaine pour l éducation et la recherche (EduIDM)

Convention d adhésion à la fédération d identités marocaine pour l éducation et la recherche (EduIDM) Convention d adhésion à la fédération d identités marocaine pour l éducation et la recherche (EduIDM) Entre: Le Centre National pour la Recherche Scientifique et Technique (CNRST), établissement public

Plus en détail

Habilitation des organismes évaluateurs pour le référencement selon l ordonnance n 2005-1516. Recueil d exigences

Habilitation des organismes évaluateurs pour le référencement selon l ordonnance n 2005-1516. Recueil d exigences Recueil d exigences Version 1.1 Page 1/13 Historique des versions Date Version Évolutions du document 17/12/2010 1.01 Première version. 29/02/2012 1.1 Prise en compte de la date de la publication de l

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

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

Conditions Générales d Utilisation de la plateforme ze-questionnaire.com

Conditions Générales d Utilisation de la plateforme ze-questionnaire.com Conditions Générales d Utilisation de la plateforme ze-questionnaire.com Droit applicable : Français. Date de dernière mise à jour : 24/07/2015. 1. Préambule, Objet, et Définitions 1.1 Présentation ze-questionnaire.com

Plus en détail

Entrez votre courriel pour administrer votre domaine. Entrer. Figure 1 : Écran de connexion. Ajouter un alias pour votre domaine.

Entrez votre courriel pour administrer votre domaine. Entrer. Figure 1 : Écran de connexion. Ajouter un alias pour votre domaine. PROMAIL Cette interface Web permet à l administrateur de gérer l ensemble des paramètres du ou des domaines dont il a la charge ainsi que les comptes associés. Il suppose donc une connaissance basique

Plus en détail

LES OUTILS DE LA GESTION DE PROJET

LES OUTILS DE LA GESTION DE PROJET LES OUTILS DE LA GESTION DE PROJET PROJET : «ensemble des actions à entreprendre afin de répondre à un besoin défini dans des délais fixés». Délimité dans le temps avec un début et une fin, mobilisant

Plus en détail

Projet de Veille Technologique : la sécurité informatique - Chaînes de Confiance sur Internet -

Projet de Veille Technologique : la sécurité informatique - Chaînes de Confiance sur Internet - Projet de Veille Technologique : la sécurité informatique - Chaînes de Confiance sur Internet - Marc Tremsal Alexandre Languillat Table des matières INTRODUCTION... 3 DEFI-REPONSE... 4 CRYPTOGRAPHIE SYMETRIQUE...

Plus en détail

Dell Premier. Guide d achat et de commande. Connexion à votre page Premier. Gestion de votre profil

Dell Premier. Guide d achat et de commande. Connexion à votre page Premier. Gestion de votre profil Guide d achat et de commande Dell Premier Dell Premier est votre site Web d achat et d assistance sécurisé et personnalisé vous donnant accès à un processus d achat simple, efficace et économique. Consultez

Plus en détail

Sommaire CONNEXION WEBMAIL... 2 1. Comment se connecter au Webmail?... 2

Sommaire CONNEXION WEBMAIL... 2 1. Comment se connecter au Webmail?... 2 Sommaire CONNEXION WEBMAIL... 2 1. Comment se connecter au Webmail?... 2 LE COURRIER... 4 CREER UN NOUVEAU MESSAGE... 4 1. Comment envoyer un mail?... 4 2. Envoi avec une pièce jointe?... 7 REPONDRE A

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

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

CAPELO - COMPLÉMENTS AU DOSSIER DE

CAPELO - COMPLÉMENTS AU DOSSIER DE CAPELO - COMPLÉMENTS AU DOSSIER DE CARRIÈRE Manuel de l utilisateur de l application en ligne 11/04/2011 Tour du Midi / Zuidertoren Bruxelles1060 Brussel T +32 (0)2 791 50 00 F +32 (0)2 791 50 99 www.capelo.be

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

Politique de certification et procédures de l autorité de certification CNRS

Politique de certification et procédures de l autorité de certification CNRS Politique de certification et procédures de l autorité de certification CNRS V2.1 1 juin 2001 Jean-Luc Archimbaud CNRS/UREC Directeur technique de l UREC Chargé de mission sécurité réseaux informatiques

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

L audit de sécurité des réseaux Windows avec WinReporter

L audit de sécurité des réseaux Windows avec WinReporter White Paper L audit de sécurité des réseaux Windows avec WinReporter Ce document présente comment les administrateurs réseaux et système peuvent tirer le meilleur parti de WinReporter, édité par IS Decisions,

Plus en détail

Spécification fonctionnelle Syllabus

Spécification fonctionnelle Syllabus 2013 2014 Université Paris Diderot Paris 7 Master 1 Informatique UFR Informatique Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm Spécification fonctionnelle Syllabus -1- TABLE

Plus en détail

SEBINA OPENLIBRARY GESTION DES USAGERS ET DES BIBLIOTHÉCAIRES

SEBINA OPENLIBRARY GESTION DES USAGERS ET DES BIBLIOTHÉCAIRES SEBINA OPENLIBRARY GESTION DES USAGERS ET DES BIBLIOTHÉCAIRES GESTION DES REGISTRES : BIBLIOTHÈQUES, LECTEURS ET BIBLIOTHÉCAIRES Lecteur Bibliothécaire Groupe de lecteurs Groupe de bibliothécaires Groupe

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

JOSY. Paris - 4 février 2010

JOSY. Paris - 4 février 2010 JOSY «Authentification centralisée pour les applications web» Paris - 4 février 2010 Sommaire de la journée Présentations de quelques technologies OpenId CAS Shibboleth Retour d expériences Contexte :

Plus en détail

Portail du Consommateur. Guide d utilisation. Du dépôt de requêtes

Portail du Consommateur. Guide d utilisation. Du dépôt de requêtes Portail du Consommateur Guide d utilisation Du dépôt de requêtes Sommaire 1. CONNEXION A L APPLICATION DE GESTION DES REQUETES :... 3 2. INSCRIPTION AU DEPOT DE REQUETE :... 4 3. DEPOT D UNE NOUVELLE REQUETE

Plus en détail

ModSecurity. Cible de sécurité CSPN Version 0.96

ModSecurity. Cible de sécurité CSPN Version 0.96 Cible de sécurité CSPN Version 0.96 TABLE DES MATIERES 1 IDENTIFICATION... 3 1.1 IDENTIFICATION DE LA CIBLE DE SECURITE... 3 1.2 IDENTIFICATION DU PRODUIT... 3 2 ARGUMENTAIRE (DESCRIPTION) DU PRODUIT...

Plus en détail

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Mars 2012 Pas à pas vers de bonnes exigences

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Mars 2012 Pas à pas vers de bonnes exigences Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 OutsourcINg Pas à pas vers de bonnes exigences Outsourcing 10 11 Pas à pas vers de bonnes

Plus en détail

Une fois la page chargée, vous devriez vous trouvez sur cette interface :

Une fois la page chargée, vous devriez vous trouvez sur cette interface : 1. Introduction Moodle est une plate-forme d enseignement collaborative en ligne déployée à l Université de Biskra. Elle permet de créer des espaces de cours accessibles depuis Internet où l enseignant

Plus en détail

BOUYGUES TELECOM ENTREPRISES - CLOUD

BOUYGUES TELECOM ENTREPRISES - CLOUD BOUYGUES TELECOM ENTREPRISES - CLOUD PARTIE CLIENT Version 1.4. 21/06/2013 Partie client Page 1 Sommaire 1 FONCTIONS CLES DU PORTAIL 3 1.1 Pré-requis d utilisation des services Cloud 3 1.2 Principes de

Plus en détail

OFFICE 365 - OUTLOOK QUICK START GUIDE

OFFICE 365 - OUTLOOK QUICK START GUIDE OFFICE 365 - OUTLOOK QUICK START GUIDE 1 @student.helha.be Chaque étudiant de la Haute École dispose pour ses contacts administratifs et pédagogiques, d une boite mail dont l adresse a comme structure

Plus en détail

Résolution des problèmes liés aux imprimantes www.ofppt.info

Résolution des problèmes liés aux imprimantes www.ofppt.info ROYAUME DU MAROC Office de la Formation Professionnelle et de la Promotion du Travail aux imprimantes DIRECTION RECHERCHE ET INGENIERIE DE FORMATION SECTEUR NTIC Diagnostiquer un problème Sommaire 1. Introduction...

Plus en détail

Innovation technologique dans les établissements scolaires : l ENT, les impacts sur l organisation du travail et les risques associés

Innovation technologique dans les établissements scolaires : l ENT, les impacts sur l organisation du travail et les risques associés Innovation technologique dans les établissements scolaires : l ENT, les impacts sur l organisation du travail et les risques associés Version destinée aux enseignants qui exercent dans des établissements

Plus en détail

PFE. Gestion de portefeuille électronique par carte à puce. Equipe N 16 Projet N 98. «Sujet non industriel proposé par les élèves»

PFE. Gestion de portefeuille électronique par carte à puce. Equipe N 16 Projet N 98. «Sujet non industriel proposé par les élèves» PFE Gestion de portefeuille électronique par carte à puce Equipe N 16 Projet N 98 «Sujet non industriel proposé par les élèves» Sommaire Introduction... 4 Le contexte financier... 4 Le contexte technologique...

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

Par KENFACK Patrick MIF30 19 Mai 2009

Par KENFACK Patrick MIF30 19 Mai 2009 Par KENFACK Patrick MIF30 19 Mai 2009 1 Introduction II. Qu est ce qu un OpenId? III. Acteurs IV. Principe V. Implémentation VI. Sécurité VII. conclusion I. 2 Vue le nombre croissant de sites web nous

Plus en détail

Processus d accréditation

Processus d accréditation AGRI-STABILITÉ AGRI-QUÉBEC PLUS AGRI-INVESTISSEMENT AGRI-QUÉBEC Devis du préparateur accrédité de données Processus d accréditation Processus d accréditation, rôle et engagements du préparateur 2015 Avril

Plus en détail