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

Transcription

1 Département : Concerne : Exploitation Projet CERBERE, Analyse fonctionnelle Nos ref. : Vos ref. : CERBERE Version: Description Ecrit par Revu par Date 00.92G Version draft Albert Bruffaerts Comité de travail 03 28/11/ Version finalisée CSdC Albert Bruffaerts 08/12/ Version abrégée Albert Bruffaerts 14/01/2008 Page 1/26

2 Table des matières 1. Introduction Définition des Acronymes et des Termes Description de la terminologie Identité et Données d identification Signalétique d identification ou signalétique partagé Entités et Données de référence Structure organisationnelle et périmètre organisationnel Gestion des Identités : Consolidation des signalétiques partagés Référentiel des Identités et des Autorisations Application cible ou ressource gérée Profil applicatif d utilisation et permissions Signalétique applicatif et compte utilisateur Gestion des autorisations : attribution des permissions aux identités Rôle fonctionnel Règle de gestion des autorisations Circuits d approbation et de suivi de demandes de droits d accès Rôle organisationnel Groupe organisationnel Délégation de la gestion interactive des autorisations Mise à jour du signalétique d identification en self-service Changement du mot de passé en self-service Auto-enregistrement d identité Source externe d identités Source externe de données de référence Propagation automatisée des événements du cycle de vie Intégration forte ou faible d une application cible ou d une ressource gérée Infrastructure de Contrôle d Accès WEB Traçabilité, Journalisation et Audit Fédération d identités Page 2/26

3 1. INTRODUCTION 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. Page 3/26

4 2. DÉFINITION DES ACRONYMES ET DES TERMES 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 Profil applicatif 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 sousjacent est générique. Voir section 3.8. 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 spécifique Autorisation fine 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. Equivalent à «permission» ou «instance de profil applicatif». Voir section 3.8. 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 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 Rôle global Rôle sans paramètre. Voir section Rôle générique Rôle avec un ou plusieurs paramètres. Voir section Rôle spécifique Rôle fonctionnel 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 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. Page 4/26

5 Rôle organisationnel Attribution Attribution conditionnelle Groupe organisationnel Identité Données d identification Signalétique d identification Entité de référence Unité organisationnelle Structure organisationnelle Périmètre organisationnel Compte utilisateur Signalétique applicatif Titre d authentification Une identité se voit généralement attribuer plusieurs rôles fonctionnels. Voir section 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 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 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 d identités défini au sein d une unité organisationnelle dont la signification est spécifique à l unité. Voir section Entité active capable d accès à une application cible ou à une ressource gérée par le GIA. Voir section 3.1. Données associées à une identité permettant son identification. Voir section 3.1. Ensemble des attributs associés à une identité enregistrée dans le RIA. Voir section 3.2. 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. 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. 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. Ensemble d unités organisationnelles dépendant de manière directe ou indirecte d une unité spécifique. Voir section 3.4. 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. 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. «credentials» ; une information permettant de valider une identification ; par exemple, un mot de passe. Page 5/26

6 3. DESCRIPTION DE LA TERMINOLOGIE 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 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 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. Page 6/26

7 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 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. Page 7/26

8 Fragment de structure organisationnelle Réseau R01 dépend de dépend de PO P001 PO P002 dépend de dépend de Ecole E0001 Ecole E0002 Ecole E0003 Périmètre PO P001 Ecole E5001 Ecole E5002 Ecole E5003 Périmètre PO P 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. Page 8/26

9 Référentiel des Identités et des Autorisations contient Signalétique d identification attaché à profils Profil applicatif Référentiel contient Unité organisationnelle dépend de contient Entité de référence Cat 3 Entité de référence Cat 2 attaché à Entité de référence Cat 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 Signalétique applicatif contient pré-requis requiert Application supporte Profil applicatif implémente requiert incompatible Fonctionnalité correspond à Autorisation fine Page 9/26

10 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 de Signalétique applicatif est dérivé de Signalétique applicatif contient Déclaration d Application contient Déclaration de Profil applicatif contient correspond à requiert est dérivé de pré-requis Application supporte Profil applicatif incompatible Page 10/26

11 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. Page 11/26

12 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 identification profils Profil applicatif accès à Signalétique applicatif contient requiert correspond à Application reconnaît Compte utilisateur 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. Page 12/26

13 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 Unité Réseau R01 dépend de attaché à Unité conditionnel à PO P002 Identité Tartempion profils Profil SIEL Mutateur Profil SIEL Vérificateur contexte Unité Ecole E5001 contexte dépend de Unité Ecole E 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. Page 13/26

14 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 est l extension de Rôle fonctionnel rôles Signalétique d identification incompatible profils requiert Profil applicatif alimente Signalétique applicatif contient 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. Page 14/26

15 Profils applicatifs vs rôles fonctionnels Identité rôle Rôle Directeur d école requiert contexte contexte Profil Profil SIEL SENS VérificateurMutateur Unité Ecole E5001 Profil GIA GesLocale Tartempion rôle profil requiert Rôle Enseignant Profil SIEL Lecteur Profil SENS Self Service contexte contexte Unité Ecole E5003 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. Page 15/26

16 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 est l extension de est l extension de Déclaration de Rôle est dérivé de Rôle fonctionnel requiert est visible par Unité organisationnelle dépend de est visible par Déclaration de Profil applicatif contexte attaché à contexte est dérivé de rôles Signalétique d identification profils Profil applicatif requiert 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. Page 16/26

17 Position organisationnelle vs rôle fonctionnel Unité Réseau R01 dépend de attaché à conditionnel à Unité PO P002 Rôle Enseignant Unité Ecole E5001 dépend de Identité Tartempion rôle contexte Rôle Enseignant contexte Unité Ecole E 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 CIRCUITS D APPROBATION ET DE SUIVI DE DEMANDES DE DROITS D ACCÈS Page 17/26

18 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 rôles Rôle organisationnel est l extension de rôles Signalétique d identification requiert profils incompatible Rôle fonctionnel requiert Profil applicatif 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. Page 18/26

19 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 Rôle organisationnel est l extension de Signalétique d identification rôles rôles Rôle fonctionnel groupes requiert requiert Groupe organisationnel profils Profil applicatif 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 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. Page 19/26

20 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é Page 20/26