cerbere gestion des identités et des autorisations: modèle ... 15- présentation... ·...

Etnic Place Solvay 4 1030 Bruxelles

Gestion des Identités et des Autorisations: Modèle générique

CERB Analyse 080114 V0101 GIA ModeleGenerique.doc

© copyright ETNIC Imprimé le 16/01/2008 11:42:00

/26

CERBERE Gestion des Identités et des Autorisations: Modèle générique

Version: Description Ecrit par Revu par Date 00.92G Version draft Albert Bruffaerts Comité de travail 03 28/11/2006

01.00 Version finalisée CSdC Albert Bruffaerts 08/12/2006

01.01 Version abrégée Albert Bruffaerts 14/01/2008

Département : Concerne :

Exploitation Projet CERBERE, Analyse fonctionnelle

Nos ref. : Vos ref. :





/26

Table des matières 1. Introduction ................................................................................................................................... 3 2. Définition des Acronymes et des Termes..................................................................................... 4 3. Description de la terminologie ...................................................................................................... 6

3.1. Identité et Données d’identification ........................................................................................... 6 3.2. Signalétique d’identification ou signalétique partagé................................................................ 6 3.3. Entités et Données de référence .............................................................................................. 7 3.4. Structure organisationnelle et périmètre organisationnel ......................................................... 7 3.5. Gestion des Identités : Consolidation des signalétiques partagés ........................................... 8 3.6. Référentiel des Identités et des Autorisations .......................................................................... 9 3.7. Application cible ou ressource gérée ...................................................................................... 10 3.8. Profil applicatif d’utilisation et permissions.............................................................................. 11 3.9. Signalétique applicatif et compte utilisateur............................................................................ 12 3.10. Gestion des autorisations : attribution des permissions aux identités ................................ 13 3.11. Rôle fonctionnel................................................................................................................... 14 3.12. Règle de gestion des autorisations ..................................................................................... 17 3.13. Circuits d’approbation et de suivi de demandes de droits d’accès ..................................... 17 3.14. Rôle organisationnel............................................................................................................ 18 3.15. Groupe organisationnel ....................................................................................................... 19 3.16. Délégation de la gestion interactive des autorisations ........................................................ 19 3.17. Mise à jour du signalétique d’identification en self-service ................................................. 21 3.18. Changement du mot de passé en self-service.................................................................... 21 3.19. Auto-enregistrement d’identité ............................................................................................ 22 3.20. Source externe d’identités................................................................................................... 22 3.21. Source externe de données de référence........................................................................... 22 3.22. Propagation automatisée des événements du cycle de vie................................................ 23 3.23. Intégration forte ou faible d’une application cible ou d’une ressource gérée...................... 23 3.24. Infrastructure de Contrôle d’Accès WEB............................................................................. 24 3.25. Traçabilité, Journalisation et Audit ...................................................................................... 25 3.26. Fédération d’identités .......................................................................................................... 25





/26

11.. IINNTTRROODDUUCCTTIIOONN

Le but de ce document est de détailler une vision de la Gestion des Identités et des Autorisations dans le contexte de l’Etnic afin que chacun puisse se déterminer par rapport à un cadre précis. Dès l’abord, il est important de bien faire la distinction entre la problématique de la Gestion des Identités et des Autorisations, qui intervient principalement avant la requête d’accès et la problématique du Contrôle des Identités et des Autorisations qui intervient lors de la requête d’accès mais qui ne peut avoir lieu que sur base des données mises à jour par les procédures de gestion. Dans le contexte de l’Etnic, la problématique du Contrôle des Identités et des Autorisations a déjà été abordée dans d’autres documents, notamment à propos des applications Web développées en interne. C’est pourquoi ce document se concentre exclusivement sur la problématique de la Gestion des Identités et des Autorisations. Le document est organisé comme suit. La section 2 définit les acronymes principaux tandis que la section 3 décrit la terminologie utilisée.





/26

22.. DDÉÉFFIINNIITTIIOONN DDEESS AACCRROONNYYMMEESS EETT DDEESS TTEERRMMEESS

Acronyme Définition

CAW Contrôle ou Contrôleur des Accès WEB

GIA Gestion ou Gestionnaire des Identités et des Autorisations

G&CIA Gestion et Contrôle des Identités et des Autorisations

RIA Référentiel des Identités et des Autorisations

RBAC « Role-Based Access Control »

SAML « Security Assertion Markup Language » défini par l’OASIS

SPML « Service Provisioning Markup Language »défini par l’OASIS

GED Gestion électronique de documents

WebSSO « Web Single Sign On »

Terme Définition

Permission Instance de profil applicatif caractérisant une catégorie d’utilisateurs pour une application ou une ressource donnée ; l’instance de profil applicatif peut comporter des valeurs de paramètres si le profil sous-jacent est générique. Voir section 3.8.

Profil applicatif Caractérisation d’une catégorie d’utilisateurs pour une application ou une ressource particulière. Une application est supposée supporter une collection fermée de profils applicatifs. Un profil peut être global (sans paramètre) ou générique (avec paramètres). Une instance de profil doit définir la valeur des paramètres. Voir section 3.8.

Profil applicatif global Profil applicatif sans paramètre. Voir section 3.8.

Profil applicatif générique Profil applicatif avec un ou plusieurs paramètres. La valeur des paramètres permettra au module d’autorisation de l’application de dériver les autorisations fines correspondant à l’instance de profil. Voir section 3.8.

Profil applicatif spécifique Equivalent à « permission » ou « instance de profil applicatif ». Voir section 3.8.

Autorisation fine Droit d’accès à une fonction interne de l’application, à un écran particulier, à un dispositif interactif particulier, à une zone de données particulière spécifique à une application ou une ressource. Voir sections 3.7 et 3.24.

Rôle Caractérisation d’une catégorie d’acteurs au sein d’une organisation ; une organisation est supposée requérir une collection fermée de rôles pour assurer son fonctionnement. Cette caractérisation a pour but de faciliter l’attribution des permissions aux identités. Plusieurs rôles peuvent être attribués à une même identité ; les rôles peuvent être définis à des niveaux d’abstraction différents ; les rôles sont supposés transversaux par rapport aux applications. Voir section 3.11.

Rôle global Rôle sans paramètre. Voir section 3.11.

Rôle générique Rôle avec un ou plusieurs paramètres. Voir section 3.11.

Rôle spécifique Equivalent à « instance de rôle », c’est-à-dire référence à un rôle avec des valeurs pour les paramètres s’il est générique. Voir section 3.11.

Rôle fonctionnel Rôle défini par rapport à un processus métier caractérisant la participation de l’acteur dans le processus. Dans le contexte de l’Etnic, les rôles fonctionnels sont supposés être définis de manière centralisée et peuvent être globaux ou génériques.





/26

Une identité se voit généralement attribuer plusieurs rôles fonctionnels. Voir section 3.11.

Rôle organisationnel Rôle défini au sein d’une unité organisationnelle dont la signification est spécifique à l’unité et son périmètre organisationnel. Dans le contexte de l’Etnic, les rôles organisationnels sont supposés être définis de manière décentralisée et ne peuvent être que globaux. Une identité se voit généralement attribuer un seul rôle organisationnel. Voir section 3.14

Attribution C’est le fait d’associer à une identité (ou un groupe ou un rôle) une caractérisation (groupe, instance de rôle, instance de profil applicatif) qui lui donne des droits d’accès à des applications ou des ressources dans le périmètre du GIA. Voir section 3.10

Attribution conditionnelle Concerne les identités. L’attribution conditionnelle d’une caractérisation (rôle, profil applicatif, groupe) est explicitement liée à l’appartenance de l’identité à une unité organisationnelle. La suppression de l’appartenance entraîne automatiquement la suppression des attributions conditionnelles correspondantes. Voir section 3.10

Groupe organisationnel Groupe d’identités défini au sein d’une unité organisationnelle dont la signification est spécifique à l’unité. Voir section 3.15.

Identité Entité active capable d’accès à une application cible ou à une ressource gérée par le GIA. Voir section 3.1.

Données d’identification Données associées à une identité permettant son identification. Voir section 3.1.

Signalétique d’identification

Ensemble des attributs associés à une identité enregistrée dans le RIA. Voir section 3.2.

Entité de référence Entité ne réalisant pas d’accès mais dont l’identification est enregistrée dans le RIA, comme par exemple une unité organisationnelle ou un site d’implantation. Voir section 3.3.

Unité organisationnelle Entité représentant un nœud d’une structure organisationnelle enregistrée dans le RIA. Une identité est d’habitude attachée à une ou plusieurs unités organisationnelles. Voir section 3.4.

Structure organisationnelle

Ensemble d’unités organisationnelles organisées comme une arborescence par la relation « dépend de » : c’est-à-dire chaque unité a au plus une unité dont elle dépend. Voir section 3.4.

Périmètre organisationnel Ensemble d’unités organisationnelles dépendant de manière directe ou indirecte d’une unité spécifique. Voir section 3.4.

Compte utilisateur Identité applicative incarnée dans une base d’utilisateurs gérée de manière autonome par une application ou une ressource. Voir section 3.9.

Signalétique applicatif L’ensemble des attributs requis par une application ou une ressource particulière pour satisfaire une demande d’accès. Correspond à l’ensemble des attributs associés au compte utilisateur pour une application donnée. Voir section 3.9.

Titre d’authentification « credentials » ; une information permettant de valider une identification ; par exemple, un mot de passe.





/26

33.. DDEESSCCRRIIPPTTIIOONN DDEE LLAA TTEERRMMIINNOOLLOOGGIIEE

Cette section a pour but d’introduire une terminologie aussi uniforme et aussi précise que possible afin de permettre un discours cohérent au sein de l’Etnic. Il faut savoir que les variations de terminologie dans le domaine de la Gestion des Identités et des Autorisations, tant dans la littérature technique que commerciale, sont très nombreuses. 3.1. IDENTITÉ ET DONNÉES D’IDENTIFICATION Une identité correspond à une entité (ou encore un agent) dument enregistrée et identifiée qui peut accéder à une ou plusieurs ressources intégrées dans le périmètre de l’infrastructure de Gestion des Identités et des Autorisations. Une identité correspond soit à une personne physique soit à un programme informatique soit à tout autre dispositif actif qui peut réaliser des accès à des ressources. Une infrastructure de Gestion des Identités et des Autorisations comporte un Référentiel des Identités et des Autorisations où sont enregistrées toutes les identités connues. Les identités sont d’habitude identifiées par une clé d’identification globale, unique à l’intérieur du périmètre de l’infrastructure de GIA. A cette identité, et donc à cette clé globale, on associe un ensemble de données qui permette l’identification externe de l’entité sous-jacente : 1) pour les personnes physiques : prénoms et patronyme, domicile, date de naissance, numéro

d’employé, etc. 2) pour les agents informatiques : adresse IP, nom conventionnel de l’application, identification de

révision, etc. Dans le RIA, on peut aussi retrouver la représentation d’autres entités, qui sont généralement aussi qualifiées d’identités mais que nous appellerons ici entités (ou données) de référence pour les distinguer des identités actives, qui sont responsables d’accès aux ressources gérées. Ces entités de référence peuvent représenter, notamment : 1) des unités organisationnelles 2) des sites d’implantation 3) des ressources gérées 4) des rôles 5) des groupes 6) etc. 3.2. SIGNALÉTIQUE D’IDENTIFICATION OU SIGNALÉTIQUE PARTAGÉ Dans le RIA, on retrouve par identité enregistrée, un signalétique qui regroupe tous les attributs considérés comme utiles à partager dans le périmètre de l’infrastructure de GIA. Ces attributs sont notamment : 1) la clé d’identification globale 2) les attributs d’identification externe : prénom, patronyme, dénomination habituelle, etc. 3) les rôles, les permissions et les groupes gérés par la GIA 4) l’association avec les clés d’identification des comptes appartenant à l’identité et existant sur les

ressources gérées 5) les attributs relatifs à la position organisationnelle, fonctionnelle, géographique, etc. 6) les attributs concernant les informations de contact : téléphone, fax, adresse électronique, etc. La liste exhaustive des attributs sera déterminée par les analyses détaillées des différentes étapes de déploiement : elle est donc appelée à s’enrichir au fur et à mesure des étapes. Pour faciliter leur gestion, on peut imaginer que les attributs sont partitionnés en catégories correspondants à des besoins métiers ou des restrictions légales distincts. La fonction principale de la GIA est de maintenir à jour et diffuser ces signalétiques, afin que le contrôle des accès se base sur des données à jour et complètes.





/26

3.3. ENTITÉS ET DONNÉES DE RÉFÉRENCE Dans le RIA, on peut aussi retrouver des entités, qui sont généralement aussi qualifiées d’identités mais que nous appellerons ici entités de référence pour les distinguer des identités actives qui sont responsables d’accès aux ressources gérées. Ces entités de référence peuvent représenter : 1) des unités organisationnelles 2) des sites d’implantation 3) des ressources gérées 4) des profils applicatifs 5) des rôles 6) des groupes d’identités 7) etc. La problématique de la maintenance de ces données de références est la même que celle des identités actives. Il faut donc aussi répertorier les sources externes pour établir des liens de synchronisation, et les applications consommatrices pour les alimenter. Il faut aussi prévoir des interfaces d’administration pour permettre l’encodage des données de référence sans référentiel externe au RIA. 3.4. STRUCTURE ORGANISATIONNELLE ET PERIMETRE ORGANISATIONNEL La structure organisationnelle est représentée habituellement par une collection d’unités organisationnelles, structurée par une relation d’ordre partiel « dépend de ». La structure organisationnelle sert à organiser la population des identités, à donner un contexte opérationnel à leur gestion. Une identité est en général associée à une ou plusieurs unités organisationnelles de manière directe ou via un rôle spécifique ou une permission. L’attribution d’un rôle, d’une permission ou d’un groupe peut éventuellement être conditionnelle à l’attachement de l’identité concernée à une unité organisationnelle spécifique ; ces attributions conditionnelles sont particulièrement utiles pour gérer les attributions de personnes attachées à plusieurs unités aux métiers différents : quand elle quitte l’unité, toutes les attributions conditionnelles à l’unité sont supprimées d’un seul coup. La structure organisationnelle sert souvent de support à l’expression de règles permettant l’automatisation d’un certain nombre de procédures comme l’attribution d’un rôle à une identité ou la dérivation des permissions pour un rôle spécifique. La structure organisationnelle est un exemple de donnée de référence dont la maintenance est primordiale pour le bon fonctionnement de la GIA. Une unité de référence permet de déterminer un périmètre organisationnel, c’est-à-dire toutes les unités qui en dépendent de manière directe ou indirecte. On peut vouloir définir des règles de délégation ou d’attribution uniquement dans un périmètre organisationnel. Certains rôles ou certaines ressources peuvent être limités en terme de validité ou visibilité à un périmètre organisationnel spécifique.





/26

Fragment de structure organisationnelle

PO P001

Ecole E0001

Ecole E0002

Ecole E0003

PO P002

Ecole E5001

Ecole E5002

Ecole E5003

Réseau R01

dépend de dépend de

dépend dedépend de

Périmètre PO P001 Périmètre PO P002

3.5. GESTION DES IDENTITÉS : CONSOLIDATION DES SIGNALÉTIQUES PARTAGÉS La gestion des identités s’occupent de consolider dans un même RIA les signalétiques d’identification concernant les identités pouvant accéder une application ou une ressource intégrée dans le périmètre de l’infrastructure de GIA. Les signalétiques doivent souvent s’appuyer sur des données de références, comme la structure organisationnelle ou les sites d’implantation. Une des problématiques majeures est la mise à jour permanente du référentiel afin que l’information disponible soit complète et correcte. Les moyens utilisés sont :

1. des liens automatisés de synchronisation avec des sources externes 2. une interface interactive Web pour la mise à jour par des gestionnaires centraux ou délégués 3. une interface interactive Web pour la mise à jour en self-service 4. des procédures automatisées périodiques de désactivation sur base d’un critère d’inactivité

Une infrastructure de GIA offre aussi souvent une interface interactive Web pour la consultation des identités et des entités de référence :

1. annuaire des personnes (pages blanches) avec possibilité de recherche par critères ; 2. annuaire de la structure organisationnelle (pages jaunes) avec possibilité de recherche par

critères ; 3. annuaire des sites d’implantations avec possibilité de recherche par critères ; 4. etc.





/26

Référentiel des Identités et des Autorisations

Référentiel

Profil applicatif

dépend decontient


profils

contient

Unité

organisationnelle

Entité de référence Cat 1

contient

attaché à

Entité de

référence Cat 2

Entité de référence Cat 3

attaché à

3.6. RÉFÉRENTIEL DES IDENTITÉS ET DES AUTORISATIONS Un des composants clé de l’infrastructure de GIA est le Référentiel des Identités et des Autorisations. Ce référentiel contient tous les signalétiques d’identification et toutes les données de référence requises pour gérer les accès des applications cibles et des ressources intégrées au périmètre de la GIA. Pour faciliter la mise en commun des données consolidées au sein du RIA, le protocole LDAP v3 est un avantage considéré comme indispensable par l’Etnic.

Autorisations fines: internes à l’application

Application Profil applicatif

Fonctionnalité

implémente

supporte

correspond à

Autorisation fine

requiert

Signalétique

applicatif

contient

requiert

pré-requis

incompatible





/26

3.7. APPLICATION CIBLE OU RESSOURCE GÉRÉE Une infrastructure de GIA a pour but de gérer les données d’identification et d’autorisation requises pour le contrôle d’accès à un ensemble d’applications et de ressources intégrées à son périmètre. Il y a donc lieu d’identifier et d’enregistrer dans le RIA toutes les applications et ressources concernées : c’est la fonction des Déclarations d’Application. Pour chaque application ou ressource, il faudra déclarer les permissions qui seront gérées par la GIA (profils applicatifs) ainsi que les données requises par l’application ou la ressource pour satisfaire une demande d’accès autorisée et qui seront fournies par le GIA (signalétique applicatif). La manière dont l’application ou la ressource consomme le signalétique applicatif et interprète les profils applicatifs pour dériver les droits d’accès par rapport aux fonctionnalités et aux données internes à l’application relève du domaine des autorisations fines (« fine-grained authorisation »), domaine considéré ici comme hors périmètre du GIA proprement dit. Selon le contexte, les autorisations fines seront entièrement du ressort de l’application elle-même (application avec module d’autorisation intégré) ou partiellement déléguées à un dispositif externe à l’application et éventuellement partagé par un ensemble d’applications : par exemple, un Contrôleur d’Accès Web pour sécuriser l’accès aux pages Web qui constituent l’interface utilisateur de l’application. Une application ou une ressource peut avoir un périmètre de visibilité défini par un périmètre organisationnel, c’est-à-dire que seules les identités liées au périmètre organisationnel peuvent recevoir un accès à l’application. Le concept peut être étendu aux permissions relatives à l’application ou la ressource, notamment dans le cadre de la délégation de l’attribution des permissions. Pour faciliter la gestion des applications, on peut imaginer qu’elles soient partitionnées en catégories correspondants à des domaines métiers différents.

Profils et signalétiques applicatifs

Déclaration

d’Application

Profil applicatifsupporte

correspond à

contient

Déclaration de Signalétique applicatif

contient

contient

pré-requis

incompatible

Application

Signalétique applicatif

requiert

Déclaration de Profil applicatif

est dérivé de

est dérivé de





/26

3.8. PROFIL APPLICATIF D’UTILISATION ET PERMISSIONS Un profil d’utilisation est spécifique à une application (ou à un type d’application). L’ensemble des profils d’utilisation caractérise les fonctionnalités et les droits d’accès internes aux écrans et aux données fournies par l’application pour chacune de ces catégories d’utilisateurs ; ils constituent une vue abstraite externe de l’application, permettant la gestion des autorisations relatives à l’application via un dispositif externe, le Gestionnaire d’Identités et des Autorisations. Exemple : quatre profils applicatifs pour une application de gestion de signalétiques 1) Mutation 2) Vérification 3) Approbation 4) Audit Un profil applicatif doit dans certains cas (notamment, lors de l’accès à des données consolidées de plusieurs entités organisationnelles) être qualifié par un ensemble de paramètres pour déterminer sa zone d’impact autorisée. Un des paramètres les plus fréquents est une unité organisationnelle de référence déterminant un périmètre organisationnel. Nous appellerons « permission » ou encore « profil spécifique » une instance de profil applicatif avec la valeur de ses paramètres ; nous appellerons « profil générique » un profil exigeant des paramètres dont la valeur n’est pas connue ; nous appellerons « profil global » un profil qui ne requiert pas de paramètre. Les différents profils applicatifs supportés par une application sont habituellement enregistrés dans le RIA : nous appellerons cet enregistrement une Déclaration de Profil applicatif. Les profils associés aux identités seront des instances de profils (permissions), dérivées d’une déclaration particulière. Exemple : Référentiel de signalétiques associés à des unités organisationnelles Les profils applicatifs peuvent être génériques et qualifiés par deux paramètres : 1) une unité de référence (tous) 2) un niveau de séniorité (tous sauf l’audit) : junior, senior, authority L’unité de référence détermine un périmètre organisationnel dans la structure organisationnelle ; le niveau de séniorité détermine la liste des attributs impactés et/ou des intervalles de valeurs valides. Ce qui donnerait, les profils génériques suivants : 1) Mutation( unité, niveau ) 2) Vérification( unité, niveau ) 3) Approbation( unité, niveau ) 4) Audit( unité ) On permettra une relation « pré-requis » entre les instances de profils applicatifs. L’attribution d’une permission qui demande des pré-requis, soit est refusée par manque des pré-requis, soit entraîne l’attribution des pré-requis en cascade, selon les règles d’attribution en vigueur. On peut supposer pour la simplicité que les pré-requis portent sur des instances de profils applicatifs (permissions) avec les mêmes paramètres de qualification et qu’ils sont statiques, c’est-à-dire indépendants du signalétique applicatif. Exemple. Un vérificateur possède tous les droits d’un mutateur avec les mêmes paramètres de qualification. Un approbateur possède tous les droits d’un vérificateur avec les mêmes paramètres de qualification. On permettra une relation « incompatible » entre les permissions. Un signalétique applicatif ne pourra pas comporter simultanément deux permissions incompatibles. On peut supposer pour la simplicité que les incompatibilités portent sur des instances de profils applicatifs (permissions) avec les mêmes paramètres de qualification et qu’elles sont statiques, c’est-à-dire indépendantes du signalétique applicatif. Exemple : Un auditeur ne peut être ni mutateur ni vérificateur ni approbateur.





/26

Pour une application donnée, les profils applicatifs disponibles ainsi que les relations « pré-requis » et « incompatible » sont déclarés dans la déclaration d’application correspondante.

Identité vs comptes utilisateurs

Signalétique

d’identificationProfil applicatif

profils

Signalétique

applicatif

accès àcontient

Compte

utilisateurApplication

correspond àrequiert

reconnaît

3.9. SIGNALETIQUE APPLICATIF ET COMPTE UTILISATEUR Le signalétique applicatif est l’ensemble des attributs, y compris la clé d’identification applicative, qui est requis par une application pour satisfaire une demande d’accès par un utilisateur et déterminer les autorisations fines gérées au sein du code applicatif (écrans, dispositifs interactifs et données). Pour les applications ou les ressources qui gèrent de manière autonome une base d’utilisateurs, le signalétique applicatif regroupe tous les attributs associés à un compte utilisateur au sein de l’application. Le signalétique applicatif comprend notamment : 1) clé d’identification applicative (identification du compte utilisateur) 2) une ou plusieurs instances de profils applicatifs (ou données équivalentes) 3) un ou plusieurs attributs interprétés par l’application Exemple : Clé d’identification applicative : nom du compte Instance de profil applicatif : voir ci-dessus Attribut : adresse électronique pour notification Le lien entre le signalétique applicatif et les autorisations fines gérées au sein de l’application est considéré comme hors du périmètre du GIA. Dans le contexte d’un GIA, les données requises pour le signalétique applicatif sont enregistrées dans le signalétique d’identification au sein du RIA et fournie à l’application, soit via un dispositif externe, le Contrôleur d’Accès, soit via une consultation directe du RIA par l’application, soit via un lien de synchronisation (« account provisioning ») utilisant un connecteur.





/26

On peut rencontrer à ce niveau des problèmes de transformation et conversion de données pour permettre la dérivation du signalétique applicatif à partir du signalétique d’identification. Si tout le signalétique applicatif ne provient pas du RIA, de manière directe ou calculée, une administration des données spécifiques à l’application doit être maintenue. On supposera que le signalétique applicatif qui doit être fourni par le GIA pour une application donnée sera déclaré de manière explicite dans une Déclaration de Signalétique applicatif, contenue dans la Déclaration d’Application. Pour une application, les instances de signalétique applicatif seront dérivées de la déclaration de signalétique correspondante.

Position organisationnelle

& attribution conditionnelle

dépend de

dépend de

Tartempion

Identité

Réseau R01

Unité

PO P002

Unité

Ecole E5003

Unité

attaché à

SIELVérificateur

Profilprofils

contexte

Ecole E5001

Unité

contexte

SIELMutateur

Profil

conditionnel à

3.10. GESTION DES AUTORISATIONS : ATTRIBUTION DES PERMISSIONS AUX IDENTITÉS La gestion des autorisations, une fois toutes les identités et les données de références en place, consiste à attribuer aux identités reconnues les permissions correspondants aux applications et ressources gérées auxquelles les identités doivent accéder pour remplir leur fonction au sein de leur unité organisationnelle. Le nombre d’associations à gérer est vite extraordinairement élevé, pour peu que la population d’utilisateurs soit significative ainsi que le nombre d’applications ou de ressources gérées. Pour faciliter cette gestion des autorisations, on introduit en général le concept de rôle (« role-based access control » ; « RBAC ») et de groupe, mais aussi de règle (« rule-based access control »), de délégation de gestion et de circuit (« workflow ») d’approbation et de suivi. Ces concepts sont détaillés dans des rubriques spécifiques. Il est à noter que dans des contextes où une identité peut être associée à plusieurs unités organisationnelles avec des métiers différents, l’attribution de permissions (ainsi que de rôles ou de groupes) est utilement conditionnelle à l’association explicite de l’identité bénéficiaire à une unité organisationnelle spécifique. Cette condition permet de supprimer l’attribution des permissions, rôles et groupes liés à une unité aussitôt que l’association de l’identité avec cette unité est supprimée.





/26

Dans certains contextes, il est aussi utile de permettre des attributions temporaires de permissions ou de rôles pour traiter des cas d’exceptions.

Rôles fonctionnels: vue individuelle

Signalétique


profils

Rôle fonctionnel

requiert

rôles

est l’extension de

Signalétique applicatif

alimentecontient

incompatible

3.11. RÔLE FONCTIONNEL Afin de faciliter l’attribution des permissions aux identités du RIA, la bonne pratique recommande d’introduire des rôles qui servent d’intermédiaires entre les identités et les permissions. Les rôles ont pour but d’agréger les permissions afin de constituer des ensembles signifiants par rapport à la participation des personnes au sein des grands processus métiers de l’organisation. Normalement, ces rôles devraient provenir d’une analyse des processus métiers et représenter la participation des personnes à ces processus. On peut cependant aussi adopter une approche pragmatique et observer l’état courant des permissions pour synthétiser des rôles. Par principe, les rôles sont transversaux par rapport aux applications : en général, un rôle regroupe des profils applicatifs correspondant à plusieurs applications. Les rôles ne sont pas liés directement à la fonction ou au grade statutaire, qui est souvent trop générique pour pouvoir en dériver un besoin fonctionnel précis ; de plus, les règles régissant les fonctions et les grades statutaires sont autonomes par rapport aux processus métiers. Les rôles doivent être définis de manière centralisée afin d’en maintenir le nombre aussi réduit que possible. Ils doivent être documentés ; leur évolution doit être guidée par un comité de pilotage. Pour faciliter leur gestion, on peut imaginer que les rôles soient partitionnés en catégories correspondant à des métiers distincts.





/26

Profils applicatifs vs rôles fonctionnels

Tartempion

Identité

Ecole E5003

Unité

Enseignant

Rôle

rôle

contexteDirecteur

d’école

Rôle

Ecole E5001

Unité

contexte

SIEL

Vérificateur

Profil

SIEL

Lecteur

Profil

requiert

requiert

contexte

contexte

rôle

profil

SENS

Mutateur

Profil

SENS

Self Service

Profil

GIA

GesLocale

Profil

Un rôle doit dans certains cas (notamment, lors de l’accès à des données consolidées de plusieurs entités organisationnelles) être qualifié par un ensemble de paramètres pour déterminer sa zone d’impact autorisée. Un des paramètres les plus fréquents est une unité organisationnelle de référence déterminant un périmètre organisationnel. Nous appellerons « rôle générique » un rôle exigeant des paramètres ; nous appellerons « rôle global » un rôle qui ne requiert pas de paramètre ; nous appellerons « rôle spécifique » une instance de rôle générique avec la valeur de ses paramètres. La logique veut que : 1. un rôle global soit défini comme un ensemble d’instances de profils applicatifs (permissions) ; la

règle de définition pouvant (règle dynamique) ou pas (règle statique) dépendre du signalétique d’identification.

2. un rôle générique soit défini comme un ensemble de permissions et de profils applicatifs génériques accompagnés d’une règle d’instanciation des paramètres afin que l’instanciation du rôle générique en rôle spécifique donne un ensemble de permissions comme résultat ; la règle peut (règle dynamique) ou pas (règle statique) dépendre du signalétique d’identification.

Un signalétique ne peut contenir que des instances de rôles, dérivées de rôles globaux ou génériques. En effet, les rôles génériques ne sont que la représentation de règles de calcul permettant de dériver les ensembles de permissions correspondant à un rôle spécifique ; il faut donc instancier le rôle pour pouvoir l’attribuer à une identité. Nous supposerons que les rôles sont enregistrés dans le RIA par une Déclaration de Rôle. Toute instance de rôle associée à une identité sera dérivée d’une Déclaration de Rôle donnée. On permettra une relation « est l’extension de » parmi les rôles. Un rôle fonctionnel, global ou spécifique, héritera de toutes les permissions des rôles dont il est l’extension. En pratique, on étendra les règles de définition de rôles en permettant d’y introduire des rôles globaux à la place de permissions et des rôles génériques à la place de profils applicatifs. On permettra une relation « incompatible » parmi les rôles. La relation est symétrique. Un signalétique applicatif ne pourra pas comporter simultanément deux rôles fonctionnels incompatibles.





/26

La relation sera définie par des règles qui devront être vérifiées avant toute mise à jour des rôles associés à une identité. En cas de violation, la mise à jour doit être rejetée et la violation rapportée.

Rôles fonctionnels: vue organisationnelle

Unitéorganisationnelle

Rôle fonctionnelest dérivé de


Déclaration de Profil applicatif

est visible par

Déclaration de Rôle

est visible par

Profil applicatifest dérivé de


rôles

profils


requiert requiert

attaché à

dépend de

contexte

contexte

Il est à noter que l’appartenance à une unité organisationnelle est normalement une donnée plus fondamentale que les rôles que l’identité se voit attribués au fur et à mesure de son cycle de vie. Comme déjà évoqué précédemment, l’attribution d’un rôle peut même être conditionnelle à l’appartenance à une unité organisationnelle donnée. La suppression de l’appartenance entraîne alors la suppression de toutes les attributions qui lui sont conditionnelles.





/26

Position organisationnelle vs rôle fonctionnel

Réseau R01

dépend de

dépend de

Tartempion

Identité

Unité

PO P002

Unité

Ecole E5003

Unité

attaché à

Enseignant

Rôlerôle

contexte

Ecole E5001

Unité

contexte

Enseignant

Rôle

conditionnel à

3.12. RÈGLE DE GESTION DES AUTORISATIONS Une autre manière de combattre la charge que représente la gestion des autorisations est d’élaborer des règles applicables de manière automatique. Ces règles peuvent intervenir pour 1) Attribuer des instances de rôles sur base des valeurs d’attributs du signalétique d’identification

(règle d’attribution de rôle) 2) Attribuer des permissions sur base du rôle et/ou du signalétique d’identification (rôle générique :

règle de dérivation des permissions) ; cette règle pourrait même sélectionner la ressource cible sur base du signalétique d’identification en cas d’instances multiples de ressources du même type

3) Définir une procédure de résolution quand la relation « pré-requis » sur les instances de profils applicatifs n’est pas satisfaite pour une identité

4) Définir une procédure de résolution quand la relation « incompatible » sur les instances de profils applicatifs n’est pas respectée pour une identité

5) Définir comment la relation « est l’extension de » sur les instances de rôles est utilisée pour dériver les rôles subalternes

6) Définir une procédure de résolution quand la relation « incompatible » sur les instances de rôles n’est pas respectée pour une identité

7) Etc. Les règles d’attribution de rôles et de permissions constituent les cas les plus habituels. Elles ne sont pas nécessairement aussi dynamiques ou génériques que la présente description le suggère. Si les profils et les rôles sont uniquement globaux (sans paramètres à instancier), les règles sont beaucoup plus simples mais la puissance de modélisation est bien moindre. Quand il n’y a pas de règle automatique possible, on délègue à des gestionnaires humains la tâche de donner des valeurs aux paramètres et d’attribuer les rôles et permissions ; on peut aussi définir des circuits d’approbation et de suivi des demandes de droits d’accès. 3.13. CIRCUITS D’APPROBATION ET DE SUIVI DE DEMANDES DE DROITS D’ACCÈS





/26

Dans les cas où la satisfaction d’une demande requiert l’acquisition d’une ou plusieurs approbations, ou encore la contribution d’une ou plusieurs personnes, la définition d’un circuit prédéfini (« workflow » ; formalisation d’une procédure de type administratif) encode la procédure à suivre. Le circuit détaille les étapes requises, les formulaires de saisie correspondants et les intervenants habilités à exécuter chaque étape. Chaque demande, introduite de manière interactive ou déclenchée par un événement, sera exécutée sous la supervision d’un moteur de circuits (« workflow engine »). Les intervenants dans le circuit sont d’habitude notifiés par un courriel dont le texte contient une URL qui leur permet d’activer immédiatement le formulaire d’approbation et/ou de saisie. L’exécution avec succès d’un circuit doit se conclure par la modification des rôles ou des permissions de l’identité concernée, avec propagation automatisée (intégration forte de la ressource) ou manuelle (intégration faible de la ressource) vers les ressources concernées. On peut imaginer deux profils applicatifs génériques pour gérer le droit de déclenchement de ces circuits : 1) GIA :: RequestRoles( identityPerimeter, roleCategory, delegationFlag )

Ce profil générique donne le droit d’introduire une demande de rôle appartenant à la catégorie roleCategory pour une identité liée au périmètre organisationnel identityPerimeter. L’indicateur de délégation delegationFlag donne ou non le droit de déléguer ce droit.

2) GIA :: RequestPermissions( identityPerimeter, resourceCategory, delegationFlag ) Ce profil générique donne le droit d’introduire une demande de permissions concernant une application ou ressource appartenant à la catégorie ressourceCategory pour une identité liée au périmètre organisationnel identityPerimeter. L’indicateur de délégation delegationFlag donne ou non le droit de déléguer ce droit.

Rôles organisationnels

Signalétique


profils

Rôle fonctionnel

requiert

rôles


incompatible

Rôle

organisationnelrôles

requiert

3.14. ROLE ORGANISATIONNEL Afin de faciliter la délégation de la gestion des autorisations, il est parfois utile de permettre aux gestionnaires de la sécurité locale de définir des rôles organisationnels, c’est-à-dire des rôles qui ont une utilité locale, au sein de l’unité où ils ont été définis.





/26

Le but poursuivi est de permettre aux gestionnaires de sécurité locale de composer des rôles qui collent à la pratique locale, sur base de rôles fonctionnels et profils applicatifs définis de manière centralisée. Pour permettre une définition aisée, ces rôles organisationnels seront des rôles globaux, c’est-à-dire sans paramètres. Dans leur définition, on pourra requérir des rôles fonctionnels et des profils applicatifs génériques mais en spécifiant la valeur des paramètres requis.

Groupes organisationnels

Groupeorganisationnel

Profil applicatifprofils

Rôle fonctionnel

requiert

rôles

Rôle organisationnel

requiert

Signalétiqued’identification

groupes

rôles


3.15. GROUPE ORGANISATIONNEL Afin de faciliter la délégation de la gestion des autorisations, il est parfois utile de permettre aux gestionnaires de la sécurité locale de définir des groupes organisationnels, c’est-à-dire des groupes d’identités qui ont une utilité locale, au sein de l’unité où ils ont été définis. Le but est de permettre aux gestionnaires de sécurité locale de regrouper ensemble des personnes qui effectuent les mêmes tâches au sein de l’unité ; les rôles et permissions requises peuvent alors être attribuées au groupe plutôt qu’aux personnes une à une. Une identité bénéficiera donc des rôles et permissions qui lui sont attribués en direct mais aussi des rôles et permissions attribués aux groupes dont elle est membre. On permettra une relation « est l’extension de » parmi les groupes. Un groupe organisationnel héritera de tous les membres des groupes dont il est l’extension. 3.16. DÉLÉGATION DE LA GESTION INTERACTIVE DES AUTORISATIONS En l’absence de GIA, les personnes qui attribuent les permissions aux utilisateurs sont souvent les gestionnaires de chacune des applications, ce qui fait qu’il n’y a pas de vue globale des permissions dont une personne bénéficie. Pour effectuer leur tâche, ils utilisent la console d’administration de la ressource ou application concernée ou des lignes de commande spécifiques.





/26

Le déploiement d’un GIA permet d’acquérir une vue globale de toutes les permissions d’une identité tout en supportant la délégation de la gestion des autorisations vers du personnel ignorant les spécificités techniques de chaque application. Dans le cadre de l’Etnic, outre l’équipe centrale de gestion de la sécurité globale, on veut nommer au sein des unités organisationnelles des agents gestionnaires de la sécurité locale. Ces gestionnaires délégués seront proches du métier et pas de la technique ; dans la pratique, ils peuvent être les responsables opérationnels des personnes bénéficiaires des permissions accordées ; ils auront accès à une console d’administration conviviale leur permettant de : 1) Gérer l’attribution de rôles fonctionnels ; 2) Gérer l’attribution de permissions, si toutes les permissions ne sont pas attribuées sur base d’un

rôle ; 3) Gérer le cycle de vie (créer , modifier, supprimer) des identités sans source externe. Afin de faciliter la gestion des attributions de rôles fonctionnels et des permissions, les gestionnaires de sécurité locale pourront aussi : 1) Définir des rôles et des groupes organisationnels ; 2) Attribuer des rôles et des permissions aux groupes organisationnels ; 3) Nommer les identités comme membres d’un groupe organisationnel. Pour être cohérent, on doit imaginer que les fonctionnalités requises pour ces gestionnaires de sécurité locale sont aussi représentées par des profils applicatifs liés au GIA, considéré comme une application cible spécifique. Cela permet de gérer ces droits d’accès particuliers dans le même cadre que les autres. On peut donc imaginer les profils applicatifs génériques suivants pour représenter les permissions requises par ces gestionnaires délégués : 1) GIA :: AttributionRoles( identityPerimeter, roleCategory, delegationFlag )

Ce profil générique donne le droit d’attribuer des rôles de la catégorie roleCategory à des identités (ou groupes d’identités) associées au périmètre organisationnel identityPerimeter. L’indicateur de délégation delegationFlag donne ou non le droit de déléguer le droit d’attribution de rôle.

2) GIA :: AttributionPermissions( identityPerimeter, resourceCategory, delegationFlag ) Ce profil générique donne le droit d’attribuer des permissions portant sur des ressources de la catégorie ressourceCategory à des identités (ou groupes d’identités) associées au périmètre organisationnel identityPerimeter. L’indicateur de délégation delegationFlag donne ou non le droit de déléguer le droit d’attribution de rôle.

3) GIA :: LifecycleEntry( objectPerimeter, objectClass, delegationFlag ) Ce profil générique donne le droit de créer, désactiver, réactiver, supprimer les entrées d’un classe d’objet objectClass (notamment identité, rôle organisationnel ou groupe organisationnel) dans le contexte d’un périmètre organisationnel objectPerimeter auquel l’objet est lié. L’indicateur de délégation delegationFlag donne ou non le droit de déléguer ce droit.

4) GIA :: UpdateEntry( objectPerimeter, objectClass, attrCategory, delegationFlag ) Ce profil générique donne le droit de mettre à jour des entrées du RIA appartenant à la classe d’objets objectClass (notamment identité, rôle organisationnel ou groupe organisationnel) et lié au périmètre organisationnel objectPerimeter ; la mise à jour ne peut porter que sur les attributs de la class attrCategory. L’indicateur de délégation delegationFlag donne ou non le droit de déléguer ce droit.

Normalement, les rôles et les permissions attribuables par un gestionnaire de sécurité locale doivent dépendre de : 1) Les paramètres de la permission de délégation 2) La position organisationnelle du bénéficiaire ciblé





/26

3.17. MISE À JOUR DU SIGNALÉTIQUE D’IDENTIFICATION EN SELF-SERVICE Une partie de la charge de mise à jour du signalétique d’identification peut être déléguée à l’utilisateur lui-même. Pour ce faire, il faut mettre à disposition de la population visée une interface, Web de préférence, lui permettant de modifier les attributs dont la gestion est en self-service. Ces attributs portent notamment sur les données suivantes : 1. prénom favori 2. numéro de téléphone direct 3. numéro de mobile professionnel 4. numéro de bureau 5. numéro de fax le plus proche 6. etc.

On peut imaginer des profils applicatifs génériques pour autoriser le self-service : 1) GIA :: SelfServiceEntryUpdate( attrCategory )

Le profil applicatif donne le droit à celui qui peut s’authentifier avec le mot de passé contenu par l’entrée de modifier les attributs appartenant à la catégorie attrCategory.

3.18. CHANGEMENT DU MOT DE PASSE EN SELF-SERVICE Suivant la maturité de la population concernée, on peut aussi mettre en self-service la gestion du mot de passe. On peut permettre à l’utilisateur final 1) de modifier son mot de passe à condition qu’il se souvienne du mot de passe courant 2) de mettre un nouveau mot de passe à condition qu’il puisse répondre à une ou plusieurs

questions personnelles (challenges dont il est supposé être le seul à connaître la réponse et dont il a dû fournir la réponse au préalable)

Le nouveau mot de passe, une fois enregistré dans le RIA, peut être ou non propagé vers les ressources accessibles à l’utilisateur. Quand la modification du mot de passe est en self-service, des contraintes sont souvent configurables, notamment : 1) Structure lexicale du mot de passe : présence de minuscule/majuscule, chiffres, signes spéciaux,

etc ; taille, etc. 2) Durée de vie maximale 3) Histoire enregistrée pour éviter la réutilisation d’un mot de passe ancien 4) Temps minimum entre deux changements successifs 5) Divers messages de notification concernant le statut du mot de passe Il peut être utile que la configuration soit conditionnelle à un périmètre organisationnel. On peut imaginer des profils applicatifs génériques pour autoriser le changement de mot de passe en self-service : 1) GIA :: SelfServicePwdModif( resourceCategory )

Le profil applicatif donne droit à changer le mot de passe pour des ressources appartenant à la catégorie resourceCategory à la condition de connaître le mot de passe courant géré par le GIA et que celui-ci soit valide.

2) GIA :: SelfServicePwdReset( resourceCategory ) Le profil applicatif donne droit à changer le mot de passe pour des ressources appartenant à la catégorie resourceCategory à la condition de répondre correctement à des questions dont la réponse est secrète ; les réponses ont été données au préalable et sont enregistrées dans le RIA.

L’utilisation d’autres méthodes d’authentification peut introduire d’autres besoins de gestion, notamment en self-service, des titres de créance (« credentials ») correspondants. Le GIA doit les intégrer, le plus souvent par des applications auxiliaires ou des liens de synchronisation supplémentaires vers des référentiels spécialisés.





/26

3.19. AUTO-ENREGISTREMENT D’IDENTITÉ L’auto-enregistrement est la possibilité pour un agent inconnu de l’infrastructure de GIA de créer un signalétique d’identification qui le représente dans le RIA. Une des problématiques majeures de l’auto-enregistrement est de ne pas créer de doublons (plusieurs signalétiques concernant la même personne) suite à des variations typographiques (avec ou sans accents, fautes d’orthographe) dans les données d’identification. Il est donc utile de pouvoir y associer le déclenchement d’un circuit de validation. La possibilité d’auto-enregistrement est indispensable pour gérer de grandes populations dont un faible pourcentage est réellement actif par rapport aux ressources gérées. L’existence d’un référentiel externe d’identités facilitera la validation. Exemple : Applications disponibles sur Internet pour les élèves : on pourra valider la qualité d’élève dans le référentiel SIEL. 3.20. SOURCE EXTERNE D’IDENTITES Pour certaines sous-populations d’identités, on peut déterminer des sources externes qui contiennent le signalétique d’identification (ou en tout cas une partie significative) des identités. Afin d’éviter le double encodage de données, il convient alors d’intégrer ces sources externes et d’établir un lien de synchronisation automatisé entre la source externe et le RIA. Il est aussi utile que certains événements propagés par le lien de synchronisation déclenchent un circuit d’approbation, de validation, d’enrichissement du signalétique ou de propagation. Un GIA se caractérisera par la liste de connecteurs techniques lui permettant d’interagir avec un nombre plus ou moins large de référentiels existants dans des technologies variées ou supportant des protocoles divers. Exemples dans le contexte de l’Etnic : L’application ULIS gère un référentiel des agents de la CFWB ainsi qu’un référentiel des agents de l’Etnic pour la gestion des ressources humaines. Ces deux référentiels sont des sources externes d’identités requises pour la GIA des applications destinées aux agents de la CFWB et de l’Etnic. L’application SENS gère le référentiel des enseignants dépendant de la CFWB. Ces données forment l’essentiel des identités requises pour la GIA des applications « Enseignement » destinées aux professeurs. 3.21. SOURCE EXTERNE DE DONNÉES DE RÉFÉRENCE Pour certaines catégories d’entités de référence, on peut déterminer des sources externes qui contiennent le signalétique d’identification (ou en tout cas une partie significative) des entités concernées. Afin d’éviter le double encodage de données, il convient alors d’intégrer ces sources externes et d’établir un lien de synchronisation automatisé entre la source externe et le RIA. Il est aussi utile que certains événements propagés par le lien de synchronisation déclenchent un circuit d’approbation, de validation, d’enrichissement du signalétique ou de propagation. Un GIA se caractérisera par la liste de connecteurs techniques lui permettant d’interagir avec un nombre plus ou moins large de référentiels existants dans des technologies variées ou supportant des protocoles divers. Exemple Etnic : L’application FASE gère le référentiel des écoles et des Pouvoirs Organisateurs par réseau subsidié par la CFWB. Ces données forment une partie de la structure organisationnelle requise dans le RIA pour la GIA des applications « Enseignement ».





/26

3.22. PROPAGATION AUTOMATISÉE DES EVENEMENTS DU CYCLE DE VIE L’existence d’un RIA est l’occasion d’organiser la mise à jour automatisée d’un certain nombre de référentiels externes qui servent souvent de mécanismes d’authentification ou d’autorisation à des applications pré-existantes, commerciales ou développées en interne. La facilité d’intégration de ces applications dépend de l’existence ou non et du degré de configurabilité du connecteur fourni par le produit de GIA. Ces connecteurs permettent notamment de :

1. créer/supprimer/désactiver/réactiver un compte spécifique à l’application 2. mettre à jour les attributs de ce compte à partir des données enregistrées dans le RIA 3. mettre à jour le mot de passe 4. mettre à jour les permissions 5. comparer une sous-population du RIA avec la base de comptes utilisateurs de l’application

afin de réconcilier les données dans un sens ou dans un autre 6. détecter une mutation dans la ressource gérée pour la remonter vers le GIA (connecteur

bidirectionnel) Dans l’idéal, les connecteurs sont bi-directionnels, un référentiel externe pouvant être producteur et consommateur selon l’attribut visé.

Application cible: intégration forte

GIAInfra de Gestiond’Identification et

d’Autorisation

Module de Contrôled’Accès

Module Fonctionnel02


Application ou Référentiel

GestionnaireSécurité

GestionnaireRessource

Notification

Interaction via connecteur

3.23. INTÉGRATION FORTE OU FAIBLE D’UNE APPLICATION CIBLE OU D’UNE RESSOURCE GÉRÉE Une application cible ou une ressource gérée bénéficiera d’une intégration forte avec le GIA si la gestion de l’identification et de l’autorisation de ses utilisateurs se fait à partir du RIA par propagation automatique des événements du cycle de vie des identités correspondantes. Dans ce cas, les besoins en administration spécifique à l’application ou à la ressource sont très faibles. Une application cible ou une ressource gérée bénéficiera d’une intégration faible avec le GIA si la gestion de l’identification et de l’autorisation de ses utilisateurs est guidée par le GIA mais que les interventions requises au niveau de l’application ou de la ressource sont réalisées par un gestionnaire spécifique de l’application ou de la ressource après notification par le GIA.





/26

Pour une application ou une ressource donnée, la situation concrète peut se situer au milieu des deux situations décrites : certaines actions sur la cible seront automatisées et d’autres exigeront l’intervention du gestionnaire de l’application ou de la ressource concernée.

Application cible : intégration faible

GIAInfra de Gestiond’Identification et

d’Autorisation

Module de Contrôle

d’Accès


Module Fonctionnel

01

Application ou Référentiel

Gestionnaire

Ressource

NotificationAction

Gestionnaire

Sécurité

Confirmation

3.24. INFRASTRUCTURE DE CONTRÔLE D’ACCÈS WEB L’infrastructure de Contrôle d’Accès Web (CAW) est un sous-système qui intercepte les demandes d’accès http et HTTPS, détermine la méthode d’authentification requise ou possible, vérifie si la session sous-jacente est considérée comme authentifiée, force l’authentification si elle ne l’est pas, vérifie si la demande d’accès exprimée dans l’URL est autorisée par rapport à l’identité authentifiée, redirige la demande d’accès, augmentée du signalétique applicatif (permissions inclues), vers l’application demandée. Pour un GIA générique, le Contrôleur d’Accès Web est une application cible, presque comme une autre. En fait, soit le CAW accède au RIA pour obtenir les informations dont il a besoin, soit le RIA propage vers le référentiel spécifique du CAW les événements détectés pour le garder à jour. Bref, il faut qu’il existe une intégration forte entre les deux infrastructures, le GIA et le CAW. C’est la condition « sine qua non » pour le CAW s’appuyer sur des données complètes et à jour. Dans une situation idéale, il faudrait aussi que les interfaces Web du GIA soient sous le contrôle du CAW, ce qui permettrait de bénéficier d’un WebSSO s’il est fourni par le CAW déployé. Si une application Web sous le contrôle du CAW a besoin d’un ensemble d’attributs spécifiques à l’application (aucune autre application n’est supposée avoir accès à ces attributs), l’application devra maintenir un référentiel spécifique (RDB ou LDAP) d’utilisateurs qui devra sans doute être synchronisé avec le RIA. L’application Web est aussi supposée gérer la relation entre profils applicatifs et autorisations fines, soit dans le code applicatif soit dans un référentiel spécifique soit avec l’aide du CAW lui-même.





/26

GIA : intégration avec CAW

GIAGestionnaire

des Identités etdes Autorisations

CAW

Contrôleurd’Accès

Web

ESB - Enterprise Software Bus

Application Web02Application Web

01

GestionnairesSécurité

Infrastructure de Gestion et Contrôle des Identités et des Autorisations

Interaction automatisée

Ressource01Ressource

01

Service Web02Service Web

01

3.25. TRAÇABILITÉ, JOURNALISATION ET AUDIT La conformité à certaines dispositions légales, notamment concernant la protection des données à caractère personnel, implique que l’on puisse vérifier, notamment en cas d’incident, l’histoire des événements, y compris les étapes de circuits d’approbation, concernant un compte spécifique. Il est aussi souvent prévu une supervision périodique basée sur la génération de rapports. Pour permettre ce genre d’audit, le système doit enregistrer au fil de l’eau de manière systématique et sécurisée les événements significatifs concernant les données d’identification et d’autorisation des comptes. Il doit aussi offrir une interface Web interactive d’audit, réservée aux personnes autorisées, permettant de consulter les journaux ainsi constitués et de configurer la génération de rapports périodiques. 3.26. FÉDÉRATION D’IDENTITÉS De plus en plus, les organisations participent à des processus métiers dont le support informatique est distribué sur plusieurs organisations autonomes, ayant chacune leur domaine de sécurité et donc leur infrastructure de G&CIA. L’approche de base est qu’une personne devant accéder à des applications hébergées dans différents domaines soit enregistrée dans chacun des référentiels d’identités concernés, ce qui implique une gestion de l’identité et une authentification dans chacun des domaines. Le concept de fédération d’identités a été introduit pour attaquer cette double problématique. Pour ce faire, la fédération d’identités distingue deux catégories de domaines : le domaine fournisseur de services et le domaine fournisseur d’identités. Selon les contextes et la manière de mettre en œuvre les standards liés au concept de fédération, on peut :

1. supporter le « WebSSO » multi-domaine, en authentifiant l’utilisateur uniquement dans le domaine fournisseur d’identité ;

2. supprimer la gestion d’identités dans le domaine fournisseur de service pour peu que les attributs gérés dans le domaine fournisseur d’identités suffisent pour déterminer les droits d’accès sur le domaine fournisseur de services.





/26

La fédération d’identités est basée sur des échanges standardisés de messages encodés de manière standardisée entre domaines ayant établi un contrat de confiance. Un de ces standards est la norme SAML V2.0, basée sur le format balisé XML, et définie par le « Security Services Technical Committee » du consortium OASIS. Pour les évolutions futures de l’infrastructure de G&CIA, le support de la norme SAML V2.0 est considéré comme un avantage certain par l’Etnic. L’infrastructure G&CIA de l’Etnic pourra jouer un rôle de producteur d’affirmations SAML (« SAML asserting party ») aussi bien qu’un rôle de consommateur d’affirmations SAML (« SAML relying party »). Le cas d’utilisation le plus courant de la norme SAML est le WebSSO multi-domaine. Pour ce cas d’utilisation précis, les entités communicantes sont les CAW plutôt que les GIA.

Fédération d’Identités

G&CIA

Etnic

G&CIA

Fedict

G&CIA

MRW

G&CIAMET

G&CIA

Easiwal

SAML

SAML SAML

cerbere gestion des identités et des autorisations: modèle ... 15- présentation... ·...

Documents