Rapport. egov: Vision infrastructure IAM. E-Government ffo initiative B janvier 2011, Nr projet

Transcription

1 Rapport egov: Vision infrastructure IAM E-Government ffo initiative B janvier 2011, Nr projet

2 Informations sur le document Titre: Numéro de projet: Date: Fichier: Nombre de pages: Contrôlé par le cointervenant resp. le chef de projet: egov: Infrastructure pilote IAM <Versanddatum> U:\12564_eCH\00_IAM_eGovernment\00_Anforderungen_und_Architektur\Berichte\AWK_D ok_100118_iam_egov_f.doc 47, pièces jointes non comprises Version Date Modifications majeures Responsable V Etablissement de la structure du document Gabriel Müller V Ajustement de la structure du document Adrian Marti V Version préliminaire Markus A. Meier V Feedback AWK Markus A. Meier V Feedback groupe de projet egov (H. Häni, D. Wunderli, E. Meyer, C. Dolf, C. Mattmann, M. Zweiacker Markus A. Meier V Feedback selon WS Markus A. Meier V Feedback complémentaire Markus A. Meier V Dernier Feedback, Input selon SEC Workshop Markus A. Meier V Assurance de qualité AWK Markus A. Meier V Version définitive AWK dernier Feedback Markus A. Meier AWK Group AG Ce rapport est confidentiel et est exclusivement destiné au donneur d ordre. C est ce dernier qui dispose du droit d utiliser les résultats des travaux d AWK pour l objectif convenu. Toute utilisation dépassant le cadre de l ordre est interdite. AWK Group AG Leutschenbachstrasse 45 CH-8050 Zürich Tel Fax /47

3 Abréviations et nomenclature Abréviation IAM NIP SSO KPI Description Identity Access Management Numéro d identification personnel Single Sign-On Key Performance Indicator Références Titre Auteur / éditeur Date Lien / fichier [1] ech Referenzmodell IAM Whitepaper No.: IAM [2] ech-0107 IAM Design Prinzipien [3] Technische Spezifikation N. Haenni, M. Itin, V. Kulhavy, H. Rüger, C. Winteregg 23. April 2007 SEAC: W. Müller, H. Häni Membres du groupe de travail spécification et confirmation des fonctionnalités / Groupe de travail, c/o SECO option=com_docman&tas k=doc_download&gid= 990&lang=de nthosting.ch/gast/dokumente %20Projekt%20Stabi3I KT/_Specificat ion_1%200_deen.pdf 3/47

4 Sommaire 1. Vue d ensemble Relation avec Motivation Termes dans le contexte IAM Identifiant Identité Sujet Ressource Certificat digital Espace de noms domaine Attributs Claim, Claimset Security Token Service STS, Relying Party RP Claim Assertion Service, Claim Assertion Infrastructure, Identity Provider, Service Provider dans le contexte IAM - Identity et Access Management Registre Relation de confiance (Trust) Vision egov IAM Domain Adapter-Service Authentification Name Mapping (mise en relation des noms) Régistration de l identité Access Control Mapping Gestion et distribution de l identité Principes, exigences, standards Principes Exigences Conditions requises et standards Processus dans le contexte IAM Législatif Identification /47

5 Administration Autorisation Exécutif Gestion / administration Distribution Identification Authentification Contrôles d accès Audit Architecture technique Modèle de référence technique Archtecture informatique Topologie système IAM Les éléments d architecture IAM Identités Informations concernant les droits d accès, les privilèges et les rôles Stockage des identités Sujets et ressources Approvionnement Cas d application typiques L utilisateur consulte les données le concernant dans le registre des habitants Processus et opérations dans l adapter-service IAM egov Vérification d un document du notaire X par l utilisateur Y L utilisateur (citoyen) entre au service de l administration cantonale E-Banking d un client disposant de Un agriculteur accède au moyen de sa à un système de gestion (p.ex. un système cantonal) L utilisateurpasse commande auprès d une entreprise de vente par correspondance /47

6 Interface Interface Interface Interface 1. Vue d ensemble Ce document décrit la vision d une architecture IAM possible dans le cadre de l initiative egov ffo B2.06 du catalogue des initiatives prioritaires. Elle est représentée par la Figure 1: Administrations trust Infrastructure IAM egov Suisse 2 CSP ID CA 1 Utilisateurs Registres Infrastructure CSP IdP CAS 3 2 trust CSP Certification Provider IdP Identity Provider CAS Claim Assertion Service 2 Entreprises trust Figure 1: architecture egov IAM Une infrastructure IAM gère typiquement des ressources et leurs identités ainsi que les attributs et autorisations au sein d une entreprise ou d une organisation. L architecture egov IAM est une approche destinée aux organisations décentralisées. Cette approche se base sur le principe que des utilisateurs ou des ressources accédant à d autres ressources possèdent un certificat digital d une instance de certification accréditée (Certification Authority CA) émis par un Certification Service Provider (CSP). Par ailleurs, on suppose qu une relation de confiance (trust) définie de manière précise existe entre ces différentes ressources. On se basera sur le processus suivant (voir Figure 1 ci-dessus): 1) Les utilisateurs s enregistrent auprès de l instance de régistration 1 (p.ex. ) et obtiennent un certificat digital (p.ex.sur Smartcard) 2) L utilisateur utilisant p.ex. une prestation d un service administratif s authentifie au moyen d un certfificat. 1 Au sens strict, on distingue entre l instance de régistration (Registration Authority) et l instance de certification (Certification Authority) de l instance d émission des certificats. 6/47

7 3) L identité de l utilisateur est vérifiée auprès de l Identity-provider IdP. Les informations complémentaires éventuellement requises sont obtenues avec l approbation de l utilisateur auprès du CAS (Claim Assertion Service) du CSP. Cette vision tente de définir l architecture egov IAM à un niveau d abstraction élevé sans entrer dans les détails techniques. On se concentrera sur la présentation des processus et des dépendances. Le document est structuré comme suit: Motivation en guise d introduction (chapitre 2) Introduction avec définitions des termes essentiels (chapitre 3) Vision (Chapitre 4) Principes, exigences, standards (chapitre 5) Processus dans le contexte IAM, subdivisés dans le législatif et l exécutif (chapitre 6) Architecture technique (vision approfondie chapitre Fehler! Verweisquelle konnte nicht gefunden werden.) Cas d application typiques (chapitre 8) 1.1. Relation avec Ce document est fortement influencé par les activités en relation avec. De nombreux exemples font explicitement usage de ainsi que du support prévu (voir représentation symbolique ci-contre) conjointement avec le certificat d authentification ou de signature. Ainsi le chapitre 3 définit non seulement les termes usuels du contexte IAM, mais aussi les termes spécifiques à. Un aspect essentiel du présent document est cependant de ne pas se limiter à. Les principes décrits sont d une portée générale et applicables à un contexte nettement plus large. 7/47

8 2. Motivation En guise d introduction, un cas d application possible de la mise en œuvre de auprès d un service administratif, p.ex. l établissement d une attestation spécifique pour un habitant de la commune X. D autres cas d applications sont cités dans le chapitre 8. Conditions préalables: L utilisateur est en possession de La commune X a une relation de confiance (Trust) envers l infrastructure IAM egov Suisse. Le cas d application fortement simplifié illustre les étapes requises: Habitant 2 1 Internet Adapter-Service 9 5 Législatif Identification Administration Autorisation Exécutif Authentification Name Mapping Registrierung Access Control Mapping Verteilung 4 3 Identification 6 Portal communal 7 8 Registre des habitants Commune X Service Y Infrastructure IAM egov Suisse CSP ID CA Infrastructure CSP IdP CAS Interface trust Figure 2: L habitant utilise le service Y de la commune X 1) L habitant utilise sa sur son ordinateur 2) Il invoque le portal communal de la commune X 3) Voulant utiliser un service Y sécurisé, il doit s identifier 2. Ceci peut se faire au moyen de. 4) L authentification s effectue au moyen de (par l intermédiaire de l Adapter-Service, voir les détails au chapitre 4.1). 2 Authentification forte 8/47

9 5) Sa est validée 6) La (nom externe) est mise en relation avec le nom interne qui se trouve dans le registre des habitants (voir les détails dans les notes ci-dessous). 7) L habitant est identifié avec succès 8) Le service voulu est invoqué 9) L habitant reçoit le résultat désiré. Remarques: les étapes suivantes n ont pas été mentionnées explicitement: Saisie du code personnel (NIP): on suppose que l utilisation du certificat sur nécessite la saisie du NIP. Name Mapping: Le nombre limité d attributs pouvant être stockés sur pour un utilisateur donné peut rendre nécessaire que l utilisateur fournisse des informations supplémentaires pour s identifier. Ces étapes omises ici sont décrites plus en détail dans le cadre de la description des claims dans le chapitre 3.8 ou dans le cas d application du chapitre /47

10 3. Termes dans le contexte IAM Dans le cadre d IAM, de nombreux termes sont utilisé dans des contextes différents. Ainsi, il est important de définir une base de discussion commune. Dans ce document, les termes français utilisés proviennent du glossaire du modèle de référence IAM ech ainsi que du contexte (dans la mesure où ces termes français existent). Souvent, les termes anglais sont utilisés dans la mesure où ils sont largement répandus et connus. Certains termes sont illustrés et approfondis au moyen d exemples et de diagrammes. Les termes sont définis non pas par ordre alphabétique, mais selon la logique du document ainsi que des interdépendances des termes entre-eux Identifiant Identifiant Un identifiant est une chaîne de caractères qui définit clairement un sujet dans un espace de noms. L identifiant univoque d un sujet ou d une ressource est souvent un nom complexe et peu explicite. En outre, cet identifiant peut être contenu dans un certificat digital. L identifiant sert uniquement à identifier un sujet de manière univoque sans ambigüité possible. Remarque:L identifiant dans le contexte est le numéro univoque sous la forme Identité Identité Une identité a un identifiant (nom univoque), souvent associé à une quantité de caractéristiques supplémentaires, qui peuvent être attribuées clairement à un sujet dans un espace de noms. Un sujet peut avoir plusieurs identités. 10/47

11 3.3. Sujet Sujet Un sujet est une entité qui a accès ou demande d avoir accès à une ressource électronique. Il peut s'agir d'une personne physique ou morale, mais aussi d'une machine Ressource Ressource Une ressource est une application, un service, une fonction, un processus ou un ensemble de données, auquel un sujet demande d avoir accès Certificat digital Certificat digital Un certificat digital comprend des informations numériques permettant d identifier un sujet ou une ressource de manière univoque (détermination du propriétaire du certificat). Dans ce but, un certificat comporte usuellement: Le nom de l instance ayant émis le certificat Informations concernant les modalités et procédures selon lesquelles le certificat a été émis Durée de validité du certificat Clé publique Le nom (ou une autre désignation univoque) du propriétaire du certificat (sujet) Informations complémentaires concernant le sujet Enumérations des usages auxquels le certificat est destiné Une signature digitale permettant de vérifier l authenticité des informations contenues dans le certificat Remarques: Dans la suitte de ce document, le terme «certificat» désignera toujours le «certificat digital» Le nom du sujet (l identifiant) n est pas assimilable automatiquement à son certificat! 11/47

12 3.6. Espace de noms domaine Le caractère univoque d un nom est lié en général à un contexte clairement défini et délimité. On parle d espace de noms resp. de domaine. Domaine Un domaine constitue un espace de noms. les identifiants sont univoques à l intérieur de cet espace, c.-à-d. qu il n existe pas plusieurs ressources ou sujets différents avec des identifiants identiques. Nous sommes tous familiarisé avec l espace de noms internet et utilisons la notation www pour invoquer une ressource définie du web, p.ex. Aux temps antérieurs à internet, nous étions déjà habitués à des espaces de noms tels que noms de processus d un système d exploitation ou l espace de noms d un système de gestion de fichiers. Les espaces de noms, resp. les domaines sont d une importance essentielle dans le contexte IAM, car tout environnement IAM ne gère qu un nombre fini de sujets et de ressources. Des relations de confiance (Trust relations) peuvent être établies entre des domaines distincts afin de permettre l utilisation d identités dans un contexte englobant plusieurs domaines. Remarque concernant l unicité: le modèle de référence ech stipule qu une personne (un sujet) peut posséder plusieurs identités. Au sein d un espace de noms donné, une ressource exige systématiquement une identité univoque. Pour résoudre cette ambiguïté, les identités externes doivent être mises en relation avec les identités correspondantes à l intérieur de l espace de noms.cette mise en relation (identity mapping) peut être considérée comme une sorte d adressage indirecte (cf. Figure 3): Espace de noms X Ext-ID A1 Ext-ID A3 Ext-ID C2 Nom ressourcea Ext-ID A1 Ext-ID A2 Ext-ID A3 Nom ressourceb Ext-ID B1 Ext-ID B2 Ext-ID B3 Nom ressourcec Ext-ID C1 Ext-ID C2 Ext-ID C3 Nom ressourced Ext-ID D1 Ext-ID D2 Ext-ID D3 A D C B Figure 3: Espace de noms et mise en relation des identités 12/47

13 Dans cette figure, les identités externes (ID ext) sont mises en relation avec les identités internes. On constate p.ex. que les identités externes distinctes ID ext A1 et ID ext A2 font référence à la même Ressource «nom ressource A». L identité externe ID ext C2 fait référence à la ressource «nom ressource C». Les identités externes peuvent évidemment faire usage d autres espaces de noms Attributs Outre l identifiant univoque, les identités peuvent posséder des attributs, décrivant des caractéristiques supplémentaires. Ainsi un sujet «utilisateur» possède normalement des attributs tels que nom, prénom, numéro de téléphone, adresse , etc. Attributs Les attributs sont des champs d information de type quelconque pouvant être associé à une identité. Ils servent à décrire les caractéristiques du sujet. Une de ces caractéristiques d un sujet est un ensemble de règles d accès, c.-à-d. une description de qui est autorisé à utiliser une ressource de quelle manière (access management). Les attributs sont souvent rassemblés par groupe (cf. Figure 7) de manière à pouvoir les gérer plus simplement, p.ex. pour définir plus clairement les responsabilités pour la gestion. Ci-dessous, on donnera un exemple de regroupement d attributs dans le cas d une gestion d utilisateurs: Attributs obligatoirs tels que nom, prénom, adresse , etc. Attributs de gestions des droits d accès tels que p.ex. L utilisateur dispose des rôles office, internet, administrateur des impôts, membre de la commission de gestion, L utilisateur est autorisé à utiliser les applications X, Y, Z L utilisateur est autorisé à lire les fichiers U, S, W et à modifier K, S. Attributs spécifiques tels que p.ex. unité d organisation, supérieur hierarchique Attributs privés tels que p.ex. adresse de domicile, foto de l utilisateur, ; Dans cet exemple, les attributs privés peuvent p.ex. se trouver sous la seule responsabilité de l utilisateur lui-même, c.-à-d. qu il est responsable de la mise à jour de ces attributs. Par contre, les attributs de la gestion des droits d accès sont gerés évidemment par les instances autorisées. Remarque: la définition des attributs necessaires et pertinents est une tâche particulièrement exigente. Souvent, on ne sait que par l usage prévu ou le contexte quels sont les attributs réellement utiles. Le principe des claims, resp. des claimsets permet d adresser ce problème (cf. 3.8). 13/47

14 Claimset 3.8. Claim, Claimset Claim (angl. pour affirmation) est un concept plutôt récent dans le contexte IAM. Il permet de séparer les identités et attributs. Claim Affirmation sur un sujet, certifiée conforme par un organisme officiel, p. ex. "a 18 ans révolus", "est médecin". Claimset Un Claimset est un ensemble de Claims certifiés par un organisme officiel, tout comme un claim isolé. La Figure 4 illustre un exemple de claimset, un ensemble de claims isolés qui est muni d une signature életronique dans sa totalité (security token) Security Token Claim 1 Claim 2 Nom, prénom Claim 3 Claim n Adresse Age Signature Figure 4: Security Token avec claimset et signature Les claims permettent d externaliser pour ainsi dire la gestion des attributs. Celle-ci ne se fait pas dans le système cible ou dans l IAM cible. C est l utilisateur qui envoie à l application ou au système cible les attributs requis sous forme d un security token signé. Cette application ou ce système peut avoire confiance envers les informations du claimset grâce à la relation de confiance entre l application ou le système et l instance qui a émis les claims (cf. 3.9 STS). 14/47

15 3.9. Security Token Service STS, Relying Party RP Les claimsets sont générés par le Security Token Service STS (cf. 3.8). Le concept du STS sera expliqué en relation avec les Relying Parties RP. STS Le Security Token Service STS désigne l infrastructure qui génère les security tokens munis de leur signature électronique conformément aux standards internationaux en vigueur, resp. qui met ce service à disposition. Remarque: Dans le contexte, les STS sont désignés sous le terme CAS (Claim Assertion Service) (cf. 3.10). RP Le Relying Party en tant que propriétaire d une ressource fait confiance (angl. trusts) au sens juridique du terme en les claims émis par un Security Token Service STS «digne de confiance». Le terme Relying Party est souvent utilisé en relation avec les claims et le Security Token Service STS. Le Relying Party RP consitue usuellement une application ou un système informatique. La Figure 5 ci-dessous illustre le principe du service STS. Dans cet exemple, on utilise deux STS pour rassembler toutes les informations requises (fédération de Security Token Services). trust trust STS-A STS-B RP 6 Utilisateur Figure 5: Federated Security Token Service 15/47

16 Condition préalable: Le Relying Party RP fait confiance aux deux Security Token Service Provider STS-A et STS-B. Cas d application: 1) RP demande les attributs correspondants, p.ex. adresse commerciale, adresse de domicile et l âge 2) L utilisateur consulte STS-A pour ses attributs adresse de domicile et âge. 3) Ces informations lui sont fournies par STS A dans un security token sous forme d un claimset. 4) L utilisateur envoie ce security token au STS B afin d y ajouter son adresse commerciale. 5) Le security token (claimset) enrichi de l adresse commercial est renvoyée à l utilisateur. 6) L utilisateur décide d envoyer ce security token (claimset) au RP Claim Assertion Service, Claim Assertion Infrastructure, Identity Provider, Service Provider dans le contexte Les termes tels que CAS, CAI, IdP et SP sont souvent utilisés dans le contexte de. CAS Claim Assertion Service un Security Token Service (STS) dans le contexte. Le STS est décrit plus en détail au chapitre 3.9. CAI Claim Assertion Infrastructure infrastructure utilisée pour mettre à disposition avec le consentement explicite de l utilisateur des attributs (claims) d utilisateurs contenus dans des répertoires et registres sous forme sécurisée. IdP Identity Provider Un service permettant de valider des certificats d authentification. SP Service Provider Correspond au terme RP (cf. 3.9). 16/47

17 Les concepts de CAS, CAI, IdP et SP sont illustrés dans la Figure 6 ci-dessous: Infrastructure centrale Directory- et Assertion-Service Infrastructure CSP IdP CAS Other IdP Other CAS Interface Interface Interface Interface Claim Assertion Infrastructure CAI Interface Browser Interface Service Provider (SP) Utilisateurs Applications Figure 6: Claim Assertion Infrastructure CAI La Claim Assertion Infrastructure CAI constitue le lien entre les différents partenaires et comprend selon la spécification technique (cf. [3]) les éléments suivants: Infrastructure centrale: Infrastructure CSP (Certification Service Provider) comprenant: IdP Identity Provider CAS Claim Assertion Service Directory- et Assertion Service: IdP et CAS Service Provider suplémentaires (en option) Utilisateurs (disposant de ): utilisant des applications d un fournisseur de services (Service Provider SP) Service Provider (SP): Fournisseurs de services, resp. d applications (cf. 3.9) désignés habituellement sous le terme de Relying Party (RP) Un cas d application typique d un claimset dans le contexte est décrit au chapitre IAM - Identity et Access Management L identity management gère les noms des sujets et ressources. Souvent, la gestion englobe également les attributs ainsi que les droits d accès. Ceci explique le terme IAM Identity and Access Management: 17/47

18 IAM Identity et Access Management se consacre à la gestion des identités, de leurs attributs ainsi que des droits d accès. Les informations gérées au moyen d un IAM pour un utilisateur informatique donné (sujet) peuvent p.ex. se présenter comme suit: Utilisateur informatique Identifiant Attributs obligatoires Attributs de droits d accès Attributs spécifiques Attribute privés Figure 7: Exemple d un record IAM gestion des utilisateurs Remarque: un certain ensemble minimal d attributs sera contenu dans les certificats électroniques dans le contexte egov IAM. En raison des dispositions en relation avec la protection des données en Suisse, seuls des attributs non critiques peuvent être utilisés à cette fin, p.ex. nom, prénom Registre Les registres sont des répertoires. Un grand nombre de registres existe en Suisse p.ex. le registre des habitants, le registre des avocats, le registre d état civil, le registre des véhicules à moteur, etc. Ils sont gérés en principe par des instances officielles (administrations). En plus de ces registres officiels, il existe toute une série de registres supplémentaires, p.ex. registres des diplômes universitaires, des diplômes EPF ainsi que des diverses Ecoles d ingénieurs, etc. Les répertoires contiennent des informations spécifiques concernant une personne ou une organisation. Ces informations sont partiellement confidentielles. Registre Répertoire (banque de données) permettant de gérer des informations spécifiques concernant une personne, un groupe de métiers ou une organisation. 18/47

19 Le grand nombre de répertoires pose des exigences particulières pour les registres. Ce problème est décrit notamment sous le titre «Harmonisation des registres» par l Office Fédéral de la statistique (cf. ) Relation de confiance (Trust) La relation de confiance entre les partenaires est d une importance majeure dans le contexte IAM. Trust Relation de confiance définie formellement entre entités, p.ex. description formelle des conditions requises pour que deux domaines puissent se faire confiance mutuellement. 19/47

20 Interface Interface Interface Interface 4. Vision La vision part du principe que l IAM au sein du e-government se basera sur une approche décentralisée. L objectif est que des sujets puissent adresser n importe quelle ressource dans n importe quel espace de noms et puissent utiliser ces ressources de la manière prévue (access management). L infrastructure de base IAM egov comprend: Au moins une instance de registration (Registration Authority RA) avec une instance de certification(certification Authority CA) associée auprès de laquelle sujets et ressouces peuvent obtenir une identité digitale (p.ex. CSP ) Un support de données pour le transport des identités digitales, p.ex. Smartcard, clé USB Les services de base IAM egov Suisse avec un service de répertoire pour rechercher des ressources, p.ex. : - Instances de registration officielles accréditées (services CA) - Administrations - Entreprises - Registres - ev. d autres Des services supplémentaires peuvent être proposés en option, tels que p.ex. STS (Security Token Service). egov IAM Domain Adapter Service (système de référence d interconnection entre les différents domaines cf. les détails sous 4.1) Un répertoire des informations concernant les questions organisationnelles, juridiques et sémantiques ainsi que les clauses de responsabilité. L utilisateur peut faire usage des services de base IAM à l aide d un certificat digital émis par une instance accréditées sans autres frais. La Figure 8 donne une vue schématique de cette vision sous forme d une topologie IAM avec le sujet utilisateur et les ressources administrations, entreprises et régistres. Administrations trust Infrastructure IAM egov Suisse 2 CSP ID CA 1 Utilisateurs Registres Infrastructure CSP IdP CAS 3 2 trust CSP Certification Provider IdP Identity Provider CAS Claim Assertion Service 2 Entreprises trust Figure 8: Topologie IAM egov 20/47

21 La vue statique de l architecture IAM egov IAM selon la Figure 8 comprend: Infrastructure IAM egov IAM: Celle-ci comprend dans le cas de Suisse ID les CSPs (Certification Service Providers) ainsi que l infrastrucure CSP avec l IdP (Identity Provider Service) et le CAS (Certification Assertion Service). Sujets et ressources: Les utilisateurs, les services CA (CA ), administrations, entreprises, registres, services de base IAM Suisse. Les sujets et ressources résident usuellement dans différents espaces de noms (domaines). Relations de confiance (Trust): Toutes les ressources c.-à-d. dans cet exemple, les domaines services CA, administrations, régistres et entreprises - ont une relation de confiance envers les services de base IAM egov Suisse. Domain Adapter-Service: représentation du monde extérieur au domaine sur l architecture IAM à l intérieur du domaine (cf. 4.1 pour les détails). La vue dynamique de l architecture IAM egov IAM selon la Figure 8 se présente comme suit: Un utilisateur désire utiliser un service d une administration. Pour ce faire, il peut procéder comme suit: 1) L utilisateur s inscrit auprès de l instance de registration 3 (p.ex. ) et reçoit un certificat digital (p.ex. sur Smartcard) 2) L utilisateur utilise p.ex. un service proposé par une administration. Il s authentifie de manière forte au moyen d un certificat d authentification. 3) L identité de l utilisateur est vérifiée auprès de l Identity-provider IdP. Des informations supplémentaires concernant l utilisateur sont obtenues auprès du CAS (Claim Assertion Service) du CSP avec le consentement de l utilisateur egov IAM Domain Adapter-Service Il est recommandé d utilser un egov IAM Domain Adapter-Service pour représenter le monde externe sur le contexte interne au système IAM. 3 Au sens strict, on distingue pour une instance d émission de certificats entre l instance de régistration (Registration Authority) et l instance de certification (Certification Authority). 21/47

22 La Figure 9 illustre de manière schématique la structure de ce service: Adapter-Service Législatif Identification Administration Autorisation Exécutif Authentification Name Mapping Régistration Access Control Mapping Distribution / approvisionnement Figure 9: Adapter-Service Cet Adapter-Service est constitué de deux parties: Le législatif: Ici, on définit les processus définissant les modalités pour l identification, l administration et l autorisation des sujets. Ces processus déterminent p.ex. la manière dont le service de registration de l exécutif doit être réalisé. En outre, on définit la représentation des droits d accès (autorisation au sein du domaine) ainsi que la distribution de l identité sur les systèmes cible. L exécutif: Il s agit ici des services proposés aux applications. L exécutif de l adapter-service peut avoir les fonctionnalités suivantes: Authentification: L identité externe est authentifiée, c.-à-d. on vérifie qu elle possède une identité digitale valable provenant d une instance d émission reconnue. Name Mapping: Mise en relation (projection) de l identité externe sur l identité utilisée en interne (cf. Figure 3). Registration: Création de l identité selon les règles du domaine. Eventuellement, le nom externe peut être utilisé directement pour la régistration 4. Access Control Mapping: Autorisation selon les régles du domaine. L autorisation peut s effectuer implicitement sur la base de règles prédéfinies ou explicitement. Dans ce cas, le premier service invoqué devrait être une demande d autorisation. Des règles implicites d autorisation peuvent impliquer p.ex. que le possesseur d une est autorisé à invoquer certains services. 4 Remarque: Une régistration est toujours requise quand un sujet externe désire utiliser une ressource d un domaine. Si l identité existe déjà par la suite d une régistration antérieure, elle peut évidemment être réutilisée. 22/47

23 Gestion et distribution de l identité: Mise en œuvre du processus de gestion et de distribution dans le système IAM interne. Après la mise en relation de l identité externe avec l identité interne, il est possible d utiliser la ressource interne ou le service. Les régles et modalités du domaine sont applicables, c.-à-d. que seules les fonctions et données autorisées sont accessibles. La fonction de mapping de l adapter-service permet ainsi à l utilisateur d accéder aux ressources et services internes du domaine. L utilisateur benéficie de l avantage de pouvoir accéder aux ressources et services internes de plusieurs domaines à l aide d une identité unique. Du côté des responsables (owner) de ressources et services, la fonctin de mapping permet aux administrateurs d un domaine une association d une granularité fine des règles d accès et des rôles. Les fonctionalités de l exécutif sont approfondies ci-après. Les processus du législatif y sont également inclus Authentification Une identité externe est authentifiée p.ex. au moyen d un certificat digital. Ceci certifie uniquement qu il s agit bien d une identité valide, étant donné qu il existe une relation de confiance envers l infrastructure IAM egov et donc indirectement envers la CA ayant effectué la régistration et émis le certificat. Ainsi, la validité du certificat peut être vérifiée. L identification à proprement dite n est effectuée qu à l étape suivante (cf ) Name Mapping (mise en relation des noms) Comme décrit au chapitre Fehler! Verweisquelle konnte nicht gefunden werden. dans le cadre des explications concernant les espaces de noms, les identités externes (les identifiants, c.-à-d. les noms des identités) doivent être mises en relation avec les identités internes. Comme décrit en Figure 3, un sujet peut disposer de plusieurs identifiants. De plus, le name mapping peut, en cas de besoin, mettre en relation les attributs associés à une identité avec des attributs internes. Des règle correspondantes sont à définir dans l adapter service Régistration de l identité La régistration comprend un certain nombre de processus législatifs 5 identification: Le législatif définit la manière dont les identifiants et identités externes sont utilisés au sein de l espace de noms donné. administration: Définition des attributs (chaînes de caractères) qui seront associés aux identiés. 5 Les processus IAM à l intérieur d un domaine sont décrits en détail au chapitre 6. 23/47

24 L identité (le représentant interne) peut être utilisé après sa registration pour un single sign-on à l intérieur du domaine (délégation sécurisée) Access Control Mapping Lors de la création d une identité, les attributs d autorisation valables pour le domaine doivent lui-être associés. Le processus d autorisation du législatif définit les modalités correspondantes. Une règle peut stipuler p.ex. qu une identité externe reçoive le rôle «invité». La définition des droits d accès et privilèges du rôle «invité» fait également partie de cette activité Gestion et distribution de l identité Après la définition de tous les critères requis pour la génération de l identité, les processus exécutifs gestion et distribution sont invoqués. Gestion: Ce processus génère l identité avec ses attributs dans le répertoire IAM du domaine. Distribution: Ce processus distribue l identité sur les systèmes cible appropriés. 24/47

25 5. Principes, exigences, standards 5.1. Principes Les principes suivants s appliquent à l infrastructure IAM egov: Approche décentralisée: l IAM egov doit supporter les structures fédéralistes en Suisse. Architecture homogène: l IAM egov dispose d une architecture homogène applicable à toute la Suisse. Infrastructure de base pour toute la Suisse: l IAM egov IAM supporte une approche IAM fédéraliste et décentralisée en mettant à disposition et en assurant l exploitation des services de base appropriés. Réalisation décentralisée: L intégration de l IAM egov IAM avec les différents espaces de noms se déroule de manière décentralisée sous la responsabilité des responsables (owner) des espaces de noms respectifs. Coordination IAM egov: Un groupe de travail assure la coordination des principes et exigences pour l infrastructure IAM egov au niveau national. Relations de confiance entre les domaines: Des relations de confiance sont établies entre les différents domaines (espaces de noms). Attributs standarts: Un ensemble minimal d attributs est défini pour les utilisateurs informatiques (sujets) tels que p.ex. nom, prénom, etc. Ceci rend l utilisation des identités digitales plus aisée Exigences Disponibilité: L infrastructure IAM egov est hautement disponible (365 jours, 24 heures) avec une performance définie précisement. Des fenêtres de maintenance prédifinies sont à prévoir, pendant lesquelles la disponibilité des systèmes reste assurée dans la mesure du possible avec ev. une performance réduite. Performance: La performance de l infrastructure est définie, c.-à-d. p.ex. les temps de réponse maximals, le nombre maximal d invoquations de service simultanées, la durée moyenne d une requête. Scalabilité / évolutibilité: L infrastructure IAM egov définit la capacité des entrées (nombre d identités) pouvant être gérées par le système. Les évolutions futures sont à prendre en considération également afin que l infrastructure puisse évoluer en conséquence. Accès et services axés sur l utilisateur: L interface utilisateur de l infrastructure IAM egov en particulier pour la registration est à consevoir de manière aussi simple d usage et compréhensible que possible. 25/47

26 La connaissance des processus, du cadre légal ainsi que des infrastructures mises en œuvre inspire confiance: Un consensus fiable existe en matière de terminologie, sémantique et concepts d interopérabilité entre les domaines de confiance impliqués. Sécurité et protection des données: L utilisateur a la certitude de pouvoir se fier à la protection de ses activités et données selon l état actuel de la technologie et il se voit informer sur les dangers eventuels. Le traitement des données ne s effectue que sur la base de sources authentifiées et par conséquent fiables. Les opérations sont transparentes et vérifiables pour l utilisateur. Ceci s applique en particulier à la validation des informations concernant la sécurité. Contrôle des identités de domaines: Chaque domaine faisant partie des domaines en relation de confiance peut garantir une gestion et un contrôle sécurisés de ses identités (accès selon les règles, auditabilité). Transparence des systèmes dans un contexte décentralisé et fédéraliste: Dans le contexte GRC (Governance, Risc and Compliance), la transparence requise doit être assurée. Ceci s applique en particulier pour les identifiants et droits d accès définis et exigés par les différentes applications. Intégration de domaines privés: Les systèmes sont, sous réserve des conventions et conditions légales correspondantes ouverts face aux domaines privés. Contrôles d accès multi-niveaux: Les systèmes IAM peuvent gérer différents niveaux de sécurité définis, p.ex. un niveau public, un niveau à authentification faible, un niveau à authentification forte. Auditabilité: Les processus IAM doivent être vérifiables et auditables. L exploitation comprend une surveillance (monitoring). Les actions en relation avec la sécurité doivent être journalisées (logging) Conditions requises et standards L infrastructure IAM egov est en conformité avec des standards définis, parmi lesquels les standards suivants sont d une importance majeure : Standards ech E-Government UE: directives et standards, notamment MODINIS, IDABC, STORK, CEN Standards techniques internationaux: OASIS, WS-*, SOAP, SAML, 26/47

27 6. Processus dans le contexte IAM L Identity and Access Management (IAM) se consacre en premier lieu à l organisation et aux processus. La représentation des processus ci-dessous distingue en accord avec le modèle de référence IAM ech un groupe de processus législatif et un groupe de processus exécutif (Figure 10): Domaine Législatif Identification Administration Autorisation Processus définissant des identités de manière univoque et leurs associant un nom. Les sujets concernés doivent s authentifier. Exécutif Administration Processus définissant les attributs d une identité donnée. Des ressources différentes ont en général des attributs différents. Distribution Processus associant des rôles aux identités (droits et privilèges). Audit Processus assurant la gestion des identités ainsi que de leurs attributs. Processus assurant la distribution des identités aux systèmes cible (synchronisation). Processus assurant l enregistrement d évennements en relation avec la sécurité. Authentification (1) Authentification (2) Droits d accès Processus par lequel une ressource apporte la preuve de son identité. Processus assurant la vérification de l identité d une ressource. Processus gérant les droits d accès d une identité sur une ressource. Figure 10: Processus IAM egov IAM Les processus sont décrits en détail ci-dessous Législatif Identification Ce processus est responsable de l identification univoque d une ressource. Ceci nécessite une instance digne de confiance qui vérifie (qui effectue une régistration) les su- 27/47

28 jets et ressources selon des critères prédéfinis. Cette vérification peut être déléguée à une instance externe avec laquelle existe une relation de confiance. Après leur régistration, les sujets et ressources obtiennent leur identifiant univoque, valable pour cet espace de noms. Ce processus s applique également, lorsque des identités externes désirent utiliser des ressources internes du domaine (cf. chapitre 4.1.3). Remarques: RA Registration Authority: Dans le contexte d une identification, on utilise fréquement le terme de «régistration». Cette régistration est effectuée par l instance de régistration (angl. Registration Authority RA). CA Certification Authority: Le sujet / la ressource obtient en général non seulement un identifiant (un nom univoque), mais reçoit un certificat digital émis par l instance de certification (angl. Certification Authority CA) Administration Suite à son identification, le sujet se voit définir ses attributs. Un ensemble d attributs obligatoires, d attributs de droits d accès, d attributs spécifiques ainsi que d attributs privés est à définir (cf. chapitre 3.7). Les attributs obligatoires pour les utilisateurs de ressources informatiques peuvent comprendre p.ex. nom, prénom et adresse . Les attributs obligatoires sont gérés en principe par une instance centrale, tandis que l utilisateur gère ses attributs privés lui-même Autorisation Les sujets (utilisateurs) obtiennent des rôles ainsi que des droits (privilèges). Ceci implique des processus tels qu illustrés en guise d exemple dans la Figure 11 pour l autorisation d un utilisateur informatique: Supérieur hiérarchique 2 Support informatique 4 Responsables des applications 5 IT Security Officer Responsables des utilisateurs Contrôle des profiles d accès standards Attribution des attributs de droits d accès Figure 11: Autorisation d un utilisateur informatique 28/47

29 Les étapes dans cet exemple: 1) Le responsable des utililisateurs envoie une demande d autorisation à son supérieur. 2) Le supérieur confirme la demande et la fait suivre au support informatique. 3) Le support informatique contrôle la demande selon les profiles d autorisation existants. Si les profiles désirés sont en accord avec la demande, le profil est assigné directement (cf. point 6). 4) Si un nouveau profile doit être édifié, le responsable de l application (application owner) doit être consulté. 5) Par la suite, les attributs de droits d accès peuvent être assignés au nouveau profile. 6) Le responsable des utilisateurs ainsi que son supérieur sont informés de la finalisation de l autorisation. Important: L autorisation au sens stricte du terme est le processus définissant les rôles; dans notre exemple il s agit de la définition des profiles standards ou l établissement de nouveaux profiles sur demande. De plus, l autorisation comprend l assignation des profiles de droits d accès aux utilisateurs. Il s agit dans les deux cas d activités législatives. Les profiles standards permettent p.ex. d assigner «automatiquement» des attributs de contrôles d accès aux ressources externes (cf ). La mise en pratique de l autorisation sur un système constitue consitue un processus purement administratif Exécutif Gestion / administration Les identités peuvent être gérées soit sous forme papier ou plus élégamment à l aide d une infrastructure IAM. Une infrastructure IAM stocke les identités ainsi que leurs attributs à l intérieur d un repository (banque de données, répertoire). Dans la Figure 11 ci-dessus, le support informatique gère les identités. 29/47

30 La Figure 12 représeente la gestion à proprement dite: Domaine Ressource Ressource Ressource Ressource Lotus Notes Windows AD SAP Other Appl. IAM Domaine Gestion IAM Répertoire IAM RP Distribution Figure 12:Gestion et distribution IAM La gestion génère les identités avec leurs attributs dans le répertoire IAM du domaine contenant les systèmes cible. La distribution sur les systèms cible est décrite dans le chapitre Fehler! Verweisquelle konnte nicht gefunden werden. ci-dessous. Un certain nombre de systèmes cible utilisent ces identités ainsi que leurs attributs qui doivent donc être distribués. En outre, il faut assurer que la gestion centrale ainsi que les systèmes cible restent en synchronisation, c.-à-d. que leurs informations concernant les identités restent alignées. La Figure 12 illustre l interconnection de l infrastructure IAM avec différents systèmes tels que AD Windows, SAP Identification Les ressources informatiques doivent s identifer, c.-à-d. démontrer leur identité. Dans le cadre de l IAM egov, on suppose que les sujets disposent de certificats digitaux émis par une instance officielle pour s identifier (authentification forte) Authentification L authentification est la vérification de l identitée prétendue d un sujet. Ainsi, nous distinguons ici entre identification et authentification, contrairement à l usage en anglais, où les deux notions sont désignées par to authenticate. Dans le contexte IAM egov, ce processus comprend la vérification que le certificat soit valable et provienne d une instance d émission officielle. Dans le contexte, le certificat d authentification est vérifié au moyen de l IdPs (Identity Provider Service) du CSP (Certification Service Provider). 30/47

31 consults Error consults Access OK Contrôles d accès Le contrôle d accès est le processus assurant qu une ressource ne puisse être accédée que selon les modalités prévues. On distingue entre le contrôle d accès aux fonctions et le contrôle d accès aux données. Le contrôle d accès aux fonctions fait en sorte qu un sujet ne puisse exécuter que les fonctions pour lesquelles il est autorisé. Le contrôle d accès aux données fait en sorte que l utilisateur ne puisse accéder aux données que de la manière autorisée, c.-à-d. que p.ex. il ne peut qu accéder en lecture à l agenda d un autre utilisateur. La Figure 13 illustre un modèle générique de contrôle d accès. 1 Access Request Access Control Interface 7 Access granted 2 IAM 3 Check credentials Authentication Verification 6 Error Logger 4 5 Fetch Access Control Ruleset Error Access Policy Evaluator Figure 13: Modèle générique de contrôle d accès Audit Ce processus enregistre les informations en relation avec la sécurité dans le contexte IAM. Dans l IAM egov, ces données sont stockées localement dans chaque domaine. L architecture IAM egov définit les évennements à enregistrer obligatoirement. 31/47

32 7. Architecture technique D abord, le modèle de référence technique est présenté (angl. Technical Reference Model, TRM). Ensuite, la topologie des systèmes de l architecture proposée sera décrite. Finalement, les processus mentionnés au chapitre 6 sont approfondis Modèle de référence technique Le modèle de référence est motivé par deux obejtifs : Etablissement d une taxonomie consistente définissant une terminologie et permettant une description homogène des composants ainsi que des structures conceptionelles de l environnement IAM. Etablissement d un schéma MRT correspondant. Celui-ci contient une représentation visuelle de la taxonomie utilisés et assure ainsi une meilleure compréhension de la taxonomie. La figure ci-dessous décrit une taxonomie pour la gestion des identités largement acceptée avec la représentation visuelle correspondante. Architecture informatique Sécurité Fédération Access Control Authentification Qualité et KPI Répertoire des identités Identités Attributs Robustesse Ressources Distribution Synchronisation, intégration Performance Exploitabilité Figure 14: Modèle de référence technique (MRT) pour l IAM 6 6 Source: adaptation au modèle de The Open Group 32/47

33 Interface Interface Interface Interface 7.2. Archtecture informatique Topologie système IAM La topologie système IAM egov a déjà été esquissée dans la vision: Administrations trust Infrastructure IAM egov Suisse 2 CSP ID CA 1 Utilisateurs Registres Infrastructure CSP IdP CAS 3 2 trust CSP Certification Provider IdP Identity Provider CAS Claim Assertion Service 2 Entreprises trust Figure 15: Topologie système IAM egov Les éléments d architecture IAM L infrastructure IAM egov comprend quatre éléments d architecture 7 (Architecture Building Blocks ABB): Instance de régistration et d émission de certificats (CSP), Infrastructure CSP, supports de certificats digitaux et Domain Adapter-Service IAM egov. Le CSP ainsi que le support du certificat digital ne seront pas approfondis dans ce document. Description Infrastructure CSP Cette infrastructure comprend au minimum: IdP (Identity Provider Service): Un service assurant la vérification de certificats d authentification. Des services supplémentaires peuvent être proposés à ititre optionel tels que p.ex. un Security Token Service STS (cf. 3.9) (désigné dans le contexte par CAS Claim Assertion Service). Functions / processus Vérification du certificat d euthentification En option:service STS pour la génération de Security Token avec Claimset et signature 7 TOGAF (The Open Group Architectural Framework) se base sur la notion d ABB (Architecture Building Blocks). 33/47

34 Description Domain Adapter-Service IAM egov Service pour la mise en relation d identités externes avec les identités internes Functions / processus Authentification Name Mapping Régistration Mapping des droits d accès Gestion et distribution sur les systèmes cible internes. Les fonctions du domain service-adapter IAM egov sont décrites en détail au chapitre 4.1. Afin de faciliter aux partenaires la participation à l infrastructure IAM egov, le domain adapter--service IAM egov est à mettre à disposition en tant que service standard dans les technologies les plus usuelles. Remarque: Le domain adapter-service IAM egov IAM comprend non seulement la technologie, maus aussi la définition d un certain nombre de processus tels que p.ex. les règles définissant les attributs de contrôle d accès, resp. les démarches à respecter (cf. également le chapitre 7.3.1) Identités Dans le contexte egov, différents services CA proposeront des identités diverses 8 avec des attributs divers. Les identités auront donc des structures variables. Il serait évidemment souhaitable dans le contexte IAM egov de définir un ensemble minimal d attributs obligatoires pour chaque catégorie de sujets et ressources. Ceci rendrait l infrastructure egov plus efficace. Cette exigence ne constitue cependant pas une condition préliminaire d un point de vue fonctionnel Informations concernant les droits d accès, les privilèges et les rôles Une solution IAM gère normalement des droits d accès, des privilèges ainsi que des rôles d une identité donnée. Ces attributs de droits d accès sont gérés à l intérieur des différents domaines de manière décentralisée, donc en règle générale pas au niveau egov. Au niveau egov, des règles et recommandations concernant le processus d autorisation peuvent cependant être proposées. De telles règles pourraient se présenter p.ex. comme suit: Les détenteurs d une ont accès en lecture sur une certaine banque de données, p.ex. sur leur registre des habitants. Une certification notariale peut être validée par le certificat digital du notaire (, vérification dans le registre des notaires). Le détenteur d une faisant partie du domaine de compétence de l administration commune X peut accéder aux fonctions X, Y, Z à l intérieur de la commune. 8 Ici, on ne distingue pas entre identités externes et internes, étant donné que la discussion porte sur les identités en tant que telles. 34/47

35 Ces règles d accès peuvent être mises en application par l adapter service IAM egov, c.-à-d. lors de la génération de l identité interne, les attributs de contrôle d accès sont générés en accord avec ces règles. Remarque: La validité de la représentation des attributs de contrôle d accès externes sur les attributs internes doit être vérifiée lors de chaque invocation Stockage des identités L instance de certification (Certification Authority CA) stocke les identités dans un répertoire. Ces identités sont mises à disposition des sujets et ressources sous une forme appropriée, p.ex. pour les utilisateurs sur carte à puce ou sur une clé USB sous forme d un certificat électronique. Figure 16: Représentation symbolique de supports (carte, clé USB) 7.5. Sujets et ressources Le chapitre 3 définit les termes sujet et ressource. Les identités sont utilisées pour différentes catégories de sujets et de ressources. Sommairement, les utilisateurs de systèmes informatiques sont principalement concernés dans le contexte IAM egov. La topologie des systèmes IAM egov démontre cependant que nous ne pouvons pas nous limiter uniquement à ce type d utilisateurs. Les sujets et ressources suivants sont d une importance centrale dans le contexte ech : Sujets Utilisateur normal Identié pour une personne individuelle Utilisateur fonctionnel (délégué) d entreprises Utilisateur fonctionnel (délégué) de services publics Utilisateurs techniques, p.ex. utilisateur fonctionnel d un service, d un processus, 35/47

36 Interface Ressources Applications Services Systèmes (p.ex. ordinateur, imprimante, ) etc 7.6. Approvionnement La Figure 17 illustre en guise d exemple le transport (l approvisionnement) des identités d un utilisateur depuis un ordinateur portable vers le domaine cible par l intermédiaire d internet. Adapter-Service Utilisateurs 1 Législatif Identification Administration Autorisation Domaine Ressource Ressource Ressource Ressource Vérification ID Infrastructure IAM egov Suisse Internet Exécutif Authentification 2 Name Mapping 5 Régistration Access Control Mapping Distribution / approvisionnement Lotus Notes Windows AD IAM du domaine SAP administration IAM Répertoire IAM Other Appl. RP CSP ID CA Infrastructure CSP IdP CAS 3 ID du domaine Régistration, Access Control Mapping 4 Répertoire IAM trust Figure 17: Approvisionnement d une identité Le législatif a édifié les règles applicables à l identification, l administration et l autorisation pour le domaine (cf. chap. 6.1). Dans cet exemple, l utilisateur utilise sa carte à puce avec son ordinateur portable. Son certificat digital est transmis via internet à l adapter-service IAM egov du domaine cible. L adapter-service effectue les opérations suivantes: 2) Authentification: L identité est vérifiée par rapport au certificat digital au sein de l infratsructure IAM egov Suisse envers laquelle le domaine cible dispose d une relation de confiance. 3) Name Mapping: L identité externe est mise en relation avec l identité interne en application des règles du législatif. 4) Régistration: L identité interne est générée dans le cas où elle n existerait pas encore. Son nom externe est enregistré en guise d attribut. Le cas échéant, des attributs complémentaires sont ajoutés ou demandés de la part de l utilisateur (cf. 3.8 Claims et 3.9 Security Token Service STS). 36/47

37 Access Control Mapping: Les attributs de contrôle d accès sont générés et enregistrés en application des règles du législatif. Ici également, des attributs complémentaires peuvent être demandés auprès de l utilisateur. 5) Distribution: Les systèmes cible du domaine sont approvisionnés avec l identité interne. 8. Cas d application typiques Les exemples suivants permettent d apréhender les processus décrits plus facilement L utilisateur consulte les données le concernant dans le registre des habitants Conditions préliminaires: L utilisateur dispose de Le registre des habitants est accessible via internet Le registre des habitants a une relation de confiance envers l infrastructure IAM egov Il existe une infrastructure IAM au sein du domaine du registre des habitants en mesure de générer une identification univoque pour tous les utilisateurs (fonction applicable au domaine entier). Le législatif du registre des habitants a défini que: Les utilisateurs sont des habitants disposant de Chaque utilisateur est autorisé à consulter (lire) ses propres données Utilisateur 1 Internet Infrastructure IAM egov Suisse CSP ID CA 2 10 Adapter-Service Législatif Identification Administration Autorisation 9 Lotus Notes 3 Exécutif 4 Authentification 5 Name Mapping Unique ID Régistration 5 Access Control 6 Mapping Distribution / 7 approvisionnement Domaine du registre des habitants Windows AD IAM du domaine SAP Registre des habitants 8 Administration IAM Répertoire IAM Infrastrcture CSP IdP CAS Interface trust Figure 18: L utilisateur consulte ses données du registre des habitants 37/47

38 1) L utilisateur utilise sa sur son ordinateur. Il consulte le service du contrôle des habitants où il invoque la fonction «Mes données»». 2) Le certificat digital de l utilisateur est envoyé au Domain adapter du registre des habitants. 3) L adapter service effectue l authentification. 4) L utilisateur est authentifié au moyen de l infrastructure IAM egov. 5) Après vérification de l identité de l utilisteur, une identité univoque est générée en son nom au sein du domaine ou une identité existante est utilisée (5 ). 6) L utilisateur est enregistré dans le répertoire local IAM, dans le cas où il n y existerait pas encore. 7) Les trributs de contrôle d accès sont implantés en accord avec les règles du législatif, p.ex. les utilisateurs disposants d une ont en général droit de lecture sur le registre des habitants. 8) L enregistrement IAM est distribué, resp. syncrhonisé sur le(s) système(s) cible. 9) L adapter envoie la requête au registre des habitants (dans le contexte de l identité locale) 10) L utilisateur reçoit la réponse Processus et opérations dans l adapter-service IAM egov L adapter-service IAM egov définit des processus et des opérations tels qu illustrés dans la figure suivante en guise d exemple. Règles IAM Adapter-Service Législatif Identification Administration Autorisation Pour les habitants de la commune, les régles suivantes sont applicables: 1. Tousles habitants de la commune sont enregistrés de manière univoque dans l IAM 2. Seuls les utilisateurs disposant de peuvent utiliser la consultation électronique 3. Tous les possesseurs de ont droit de lecture sur le registre des habitants 4. La règle 1 implique qu une identité univoque est établie pour tous les habitants. 5. Celle-ci est enregistrée dans le répertoire IAM. 6. Les attributs de droits d accès appropriés sont édifiés, donc p.ex. Accès en lecture pour tous les habitants dans le registre des habitants. 7. La communication avec le registre des habitants s effectue par Domaine du registre des habitants Windows AD SAP 4 7 Registre des habitants Exécutif Authentification Name Mapping Régistration Access Control Mapping Distribution / approvisionnement Unique ID 5 IAM du domaine Administration IAM Répertoire IAM 6 Figure 19: Processus et opérations de l adapter-service IAM egov 38/47

39 Le législatif du domaine du registre des habitants définit les règles locales IAM, p.ex: 1) Tous les habitants de la commune ont une inscription univoque dans l IAM de la comune 9. 2) Seuls les utilisateurs disposant d une peuvent consulter életroniquement leurs données 3) Toutes les personnes possédant des certificats ont droit de lecture sur le registre des habitants 4) La règle 1 implique qu une identité univoque est définie pour tous les habitants (au sein de la commune). 5) Cette identité est enregistrée dans le répertoire IAM. 6) Les attributs d accès requis sont définis, ainsi p.ex. accès en lecture pour tous les habitants dans le registre des habitants. 7) La communication avec le registre des habitants s effectue par Vérification d un document du notaire X par l utilisateur Y Conditions préliminaires: Le notaire et l utilisateur disposent respectivement de leur propre Le notaire est inscrit au registre des notaires. Ce registre peut délivrer des certificats digitals pour les notaires qui y sont inscrits. Le registre des notaires a une relation de confiance (trust) envers l infrastructure IAM egov. 9 Remarque: Le cas fréquent où plusieurs communes exploitent un répertoire commun n est pas pris en considération ici. 39/47

40 La figure ci-dessous illustre un déroulement possible: Notaire Utilisateur 1 Document Cert. notaire Internet Cert. notaire Registre des notaires Infrastructure IAM egov Suisse CSP ID CA 3 Infrastructure CSP IdP CAS Interface trust Figure 20: Vérification d une certification notariale d un document 1) Le notaire utilise sa sur son ordinateur. 2) Il sollicite un certificat pour notaire auprès du registre des notaires. 3) Le registre des notaires vérifie l identité du notaire au moyen de sa 4) Le certificat digital du notaire est établi. 5) Le notaire emballe le document, sa ainsi que son certificat de notaire et encrypte la totalité de ce paquet avec sa clé secrète. Le paquet est envoyé par e- mail au destinataire. 6) L utilisateur dispose également d une Suisse ID sur son ordinateur portable. 7) Il reçoit l du notaire, décrypte le paquet à l aide de la clé publique du notaire. Ensuite il envoie le certificat du notaire ainsi que son propre certificat au registre des notaires. 8) Etant en possession d une, l utilisateur est autorisé à vérifier la validité du certificat du notaire. Il reçoit la réponse correspondante. 40/47

41 8.4. L utilisateur (citoyen) entre au service de l administration cantonale Conditions préliminaires: L administration cantonale a décidé que les utilisateurs disposent d une identité unique dans le contexte IAM. Ainsi les concitoyens qui sont simultanément collaborateurs de l administration cantonale utilisent la même identité dans les deux contextes. L administration cantonale a une relation de confiance (Trust) envers l infrastructure IAM egov. Les collaborateurs de l administration cantonale utilisent sur cartes à puce. Le législatif de l administration cantonale a décidé que chaque utilisateur informatique du domaine de l administration cantonale dispose d un seul enregistrement IAM. Plusieurs identités externes peuvent être associées à une identié unique du domaine (cf. Figure 3). L utilisateur est une personne ayant déjà fait appel à des services électroniques de l adminitration cantonale. De ce fait, l utilisateur existe déjà dans le répertoire IAM de l administration. Voici un scénario possible: Utilisateur X Supérieur hiérarchique de X Utilisateur X Internet Adapter-Service Législatif Identification Administration Autorisation 2 Administration cantonale Infrastructure IAM egov Suisse CSP ID CA Exécutif Authentification Name Mapping Régistration Access Control Mapping Distribution / approvisionnement Lotus Notes Unique ID 3 HR Windows AD IAM du domaine 3 SAP Other Appl. 4 Administration IAM Répertoire IAM Infrastructure CSP IdP CAS Interface trust Figure 21: L utilisateur X entre au service de l administration cantonale 41/47

42 1) X a été embauché par le supérieur hiérarchique. 2) X est enregistré dans le système des employés (HR). 3) Une identité univoque est générée dans le répertoire IAM de l administration cantonale. Etant donné qu elle existe déjà (voir conditions préliminaires), l identifiant existant est utilisé. Toutefois, un attribut «employé administration cantonale» y est ajouté. En tant qu employé de l administration, il reçoit en application des règles du législatif les droits d accès requis pour son travail. 4) Son identité comprenant tous les attributs requis est distribuée sur les systèmes cible. 5) L utilisateur X s identifie sur son ordinateur à sa place de travail de l administration cantonale au moyen de sa. 6) L authentification s effectue au niveau local au niveau de l Active Directory Windows qui fait partie intégrante de l environnement de confiance de l administration cantonale avec relation de confiance envers l infrastructure IAM egov E-Banking d un client disposant de Eventuellement, les utilisateurs pourraient effectuer leurs transactions bancaires au moyen de 10. Conditions préliminaires: Le législatif de la banque a édicté les règles suivantes: La banque accèpte en tant que moyen d authentification digne de confiance. Les nouveaux clients doivent s identifier personnellement auprès de la banque pour établir une relation bancaire. Cette régistration nécessite une pièce d identité ainsi que la du client 11, s il désire utiliser celle-ci pour les transactions bancaires par la suite. Les utilisateurs authentifiés peuvent utiliser toutes les fonctionalités e- banking sur leurs comptes et dépôts. Le client X a une relation bancaire (un compte) auprès de la banque. L initialisation de la relation client a déjà été effectuée selon les règles du législatif (cf. flèches bleues dans la Figure 22 ci-dessous). La banque dispose d une relation de confiance envers l infrastructure IAM egov. 10 Ce type d application ne fait momentanément pas partie des objectifs de. 11 Remarque: Les clients de la banque désirant administrer des comptes de personnes tierces au moyen du e-banking auront besoin d une procuration. La banque adaptera les droits d accès dans son domaine en conséquence. 42/47

43 Internet Une consultation du solde d un compte bancaire peut s effectuer de la manière suivante: Client X 1 Relation client Adapter-Service 2 Législatif Identification Administration Autorisation 7 Banque 4 Infrastructure IAM egov Suisse CSP ID CA 3 Exécutif Authentification Name Mapping Régistration Access Control Mapping Distribution / approvisionnement 5 ID Client 6 Gestion du compte Infrastructure CSP IdP CAS Interface trust Figure 22: Le client X consulte son compte auprès de sa banque 1) Le client X utilise sa sur son ordinateur. 2) Il ouvre l application, resp. le site internet e-banking de sa banque. 3) Il s y identifie au moyen de son certificat digital. 4) Ce certificat est validé au moyen de l infrastructure IAM egov. 5) S il est valide, le Name Mapping est appliqué, c.-à-d. que sa est associée au numéro de compte interne. 6) L application de gestion des comptes est invoquée pour le client X. 7) Le client X peut utilise l application de gestion des comptes. La banque peut augmenter la sécurité de l étape d authentification (étape 3) en demandant en supplément à l utilisateur de saisir un nombre aléatoire, p.ex. au moyen d un token RSA. Remarque: Seules les fonctions d authentification et de name mapping de l adapter service sont utilisées dans cet exemple. 43/47