Département : Concerne : Exploitation Projet CERBERE, Analyse détaillée Nos ref. : Vos ref. : Version: Description Ecrit par Revu par Date 00.90 Requis par le comité de pilotage du 6 avril 2011 Albert Bruffaerts 19/09/2011 00.91 Page 1/24
Résumé pour exécutif Le but de ce document est de servir de guide aux intégrateurs devant intervenir sur des projets d acquisition d application dont les utilisateurs seront gérés via l infrastructure CERBERE. CERBERE est une plate-forme centralisée de gestion des utilisateurs et de leurs droits d accès aux ressources informatiques du MCF. Ce guide se veut surtout pragmatique. Ceux qui seraient intéressés par plus de détails peuvent consulter les documents repris dans la section 7 reprenant les documents de référence. Ce guide pour l intégration aborde les points principaux qui constituent l interface entre une application protégée et l infrastructure CERBERE selon trois axes : les utilisateurs les droits d accès les données de référence complémentaires Cependant la manière concrète de réaliser l intégration va dépendre principalement de l architecture technique utilisée par l application à intégrer. La question va être abordée fonction par fonction. L infrastructure CERBERE doit être utilisée par un maximum d applications : c est la mutualisation des données consolidées ainsi que des efforts consacrés à leur mise à jour qui font toute sa valeur. Page 2/24
Table des matières 1. Introduction... 4 2. Considérations générales... 6 2.1. Architecture conceptuelle d une application... 6 2.2. Mécanisme d authentification... 7 2.3. Mécanisme de contrôle d accès... 9 2.4. Accès au signalétique applicatif... 10 2.5. Accès aux données de contexte liées au signalétique applicatif... 10 2.6. Association de données spécifiques à un utilisateur reconnu... 10 3. Intégration des Utilisateurs... 11 3.1. Procédure d Authentification... 11 3.1.1. Application web sous le contrôle de CAW-IU... 11 3.1.2. Service web sous le contrôle de CAW-S... 11 3.1.3. Application indépendante du CAW mais intégrée à CERBERE... 11 3.2. Accès aux données de l utilisateur responsable... 12 3.2.1. Application web sous le contrôle de CAW-IU... 13 3.2.2. Service web sous le contrôle de CAW-S... 13 3.2.3. Application indépendante du CAW mais intégrée à CERBERE... 13 3.3. Accès aux données d un utilisateur arbitraire... 13 3.3.1. Applications «LDAP-enabled»... 14 3.3.2. Applications utilisant des tables relationnelles... 14 3.3.3. Méthode de constitution du référentiel externe à CERBERE... 14 3.3.4. Utilisateur et intervenant... 14 3.4. Associations de données «métier» à un utilisateur... 14 4. Intégration des Droits d accès... 16 4.1. Procédure d autorisation : permissions d entreprise... 16 4.1.1. Application web sous le contrôle de CAW-IU... 16 4.1.2. Service web sous le contrôle de CAW-S... 17 4.1.3. Application indépendante du CAW mais intégrée à CERBERE... 17 4.2. Procédure d autorisation : autorisations fines... 20 4.2.1. Interprétation des valeurs de paramètres des instances de profils applicatifs... 20 4.2.2. Règles d autorisation... 20 5. Intégration des données de contexte... 21 5.1. Accès aux données de contexte... 21 5.2. Acquisition des données de contexte... 21 6. Quelques considérations... 22 6.1. Situation : Annuaire LDAP externe à l application... 22 6.2. Situation : Référentiel des utilisateurs interne à l application... 22 6.3. Procédure d autorisation interne à la ressource... 22 6.3.1. Dispositif d autorisation basé sur l association à un agrégat identifié... 22 6.3.2. Dispositif d autorisation basé sur une règle exécutable... 23 6.3.3. Applications développées sur mesure... 23 6.4. Traçabilité... 23 7. Références... 24 Page 3/24
1. INTRODUCTION Le but de ce document est de servir de guide aux intégrateurs devant intervenir sur des projets d acquisition d application dont les utilisateurs seront gérés via l infrastructure CERBERE. CERBERE est une plate-forme centralisée de gestion des utilisateurs et de leurs droits d accès aux ressources informatiques du MCF. CERBERE offre trois principaux services : un référentiel, le Référentiel des Identités et des Autorisations (RIA), contenant principalement les signalétiques de tous les utilisateurs des applications protégées ainsi que les données de référence liées aux utilisateurs pour permettre leur gestion ; à ce référentiel est associé un ensemble de pages Web, le Gestionnaire des Identités et des Autorisations (GIA), permettant aux personnes autorisées de consulter et de modifier ces signalétiques ; un service de Contrôle des Accès Web (CAW) : toute URL protégée requiert une authentification réussie et le bénéfice des droits d accès prévus lors de l analyse fonctionnelle ; ce service est rendu via deux composants logiciels, l un dédié au contrôle d accès web des interfaces utilisateurs (CAW-IU), l autre dédié au contrôle d accès web aux services web publiés (CAW-S) ; un service de synchronisation de signalétiques caractérisant notamment les utilisateurs des différentes applications ; ce service peut synchroniser des référentiels externes ; il peut aussi consolider dans le RIA des données provenant de référentiels externes. Il est utile de comprendre que certaines applications sont dans le périmètre de CERBERE sans être sous le contrôle du CAW de CERBERE ; dans ce cas, ces applications possèdent leur propre mécanisme de contrôle des accès, mécanisme qui utilise des données d authentification et d autorisation synchronisées par CERBERE. Ce guide se veut surtout pragmatique. Ceux qui seraient intéressés par plus de détails peuvent consulter les documents repris dans la section 7 reprenant les documents de référence. Ce guide pour l intégration aborde les points principaux qui constituent l interface entre une application protégée et l infrastructure CERBERE selon trois axes : les utilisateurs les droits d accès les données de référence complémentaires Cependant la manière concrète de réaliser l intégration va dépendre principalement de l architecture technique utilisée par l application à intégrer. La question va être abordée fonction par fonction. Liste des fonctions abordées : 1. intégration des utilisateurs a. procédure d authentification b. accès aux données de l utilisateur responsable c. accès aux données des autres utilisateurs d. association de données applicatives spécifiques à un utilisateur 2. intégration des droits d accès a. procédure d autorisation permissions d entreprise b. procédure d autorisation autorisations fines 3. intégration des données de contexte a. interprétation des données de contexte b. acquisition des données de contexte Pour chaque fonction, les contextes techniques suivants seront passés en revue si relevant : 1. application web sous le contrôle de CAW-IU Page 4/24
2. service web sous le contrôle du CAW-S 3. application indépendante du CAW mais intégrée à CERBERE Recommandation. Si des questions se posent sur le fonctionnement de CERBERE, il vaut mieux les adresser directement à l équipe CERBERE plutôt que d essayer d y répondre en vase clos et d aboutir à des réponses erronées. L infrastructure CERBERE doit être utilisée par un maximum d applications : c est la mutualisation des données consolidées ainsi que des efforts consacrés à leur mise à jour qui font toute sa valeur. Page 5/24
2. CONSIDERATIONS GENERALES 2.1. ARCHITECTURE CONCEPTUELLE D UNE APPLICATION Définition. L architecture d un système c est l organisation fondamentale d un système telle qu elle est incarnée par ses composants et les relations qu ils entretiennent entre eux et avec l environnement ; c est aussi les principes qui gouvernent la conception et l évolution de ce système. Voir page 3 de [ARCH-IEEE]. D un point de vue (très) abstrait, une application métier est essentiellement composée de : 1. un catalogue de transactions métier disponibles : T 1,..., T n 2. un ensemble d objets métier de types variés, accédés via l exécution d une transaction métier : O 1,..., O m 3. souvent, un ensemble de collections identifiées, qui structurent les objets métier : C 1,..., C p Dans ce contexte, d un point de vue tout aussi abstrait, l exécution d une transaction métier T i,agissant sur un objet métier O q appartenant à une collection C h est réalisée sous la responsabilité d un signalétique applicatif d utilisateur U k. Cependant l exécution de la transaction est systématiquement conditionnée à la réussite de deux mécanismes auxiliaires : 1. un mécanisme d authentification utilisant des titres d authentification lié au signalétique applicatif d utilisateur U k pour valider la responsabilité de l agent actif 2. un mécanisme de contrôle d accès utilisant des données d autorisation associées au signalétique applicatif d utilisateur U k pour valider le droit d exécuter la transaction métier concernée sur l objet métier concerné On peut bien entendu généraliser à des transactions impliquant plusieurs objets métier, chacun appartenant à une collection identifiée. Page 6/24
2.2. MECANISME D AUTHENTIFICATION On peut caractériser le mécanisme d authentification par trois aspects pour classifier les différentes applications : 1. le lieu de l activation : l authentification se fait-elle à l extérieur de l application, échappant ainsi à son contrôle, ou à l intérieur de l application, tributaire de son bon comportement ; 2. le service implémentant la méthode d authentification : l implémentation de la méthode d authentification est-elle extérieure ou intérieure à l application ; 3. le registre contenant les titres d authentification : le registre est-il à l extérieur ou à l intérieur de l application La combinaison de ces trois aspects donne la classification suivante : Activation Service Données Commentaire Externe Externe Externe Authentification entièrement gérée par CERBERE : c est la plate-forme d exécution qui déclenche l authentification via CERBERE C est la combinaison correspondant normalement aux applications Web développées par l ETNIC. Interne Externe Externe Authentification sous-traitée à un service de CERBERE mais c est l application qui déclenche l exécution. Possible? Service d authentification publiés? via ESB? C est la combinaison correspondant aux applications qui externalisent la procédure d authentification via un appel à un web service externe ou équivalent. Interne Interne Externe Données d authentification gérées par CERBERE et utilisées directement à partir du RIA par l application ; c est l application qui déclenche et qui implémente l authentification ; les titres d authentification stockés dans le RIA doivent être compatibles avec le mécanisme interne de l application. C est la combinaison correspondant normalement aux progiciels «LDAP-enabled» sans référentiel interne d utilisateurs. Dans ce cas, il est recommandé d utiliser un réplicat (partiel) du RIA ou un annuaire LDAP intermédiaire, synchronisé par un connecteur CERBERE, comme registre des données d authentification. Interne Interne Interne Données d authentification gérées par CERBERE et synchronisées via un connecteur d alimentation périodique dans un référentiel interne à l application ; c est l application qui déclenche et qui implémente l authentification ; les titres d authentification synchronisés doivent être compatibles avec le mécanisme interne de l application. C est la combinaison correspondant aux progiciels avec référentiel interne d utilisateurs. Dans tous les cas CERBERE garde le contrôle de la gestion des titres d authentification. Cependant ce contrôle est dépendant pour les trois derniers cas du bon comportement de l application ; la Page 7/24
confidentialité des titres d authentification est aussi dépendante du bon comportement de l application. Les deux derniers cas nécessitent aussi une compatibilité des titres d authentification avec le mécanisme d authentification interne à l application. Page 8/24
2.3. MECANISME DE CONTROLE D ACCES On peut utiliser les mêmes aspects pour caractériser le mécanisme de contrôle d accès basé sur les profils applicatifs (permissions d entreprise). Cependant il faut bien se rendre compte des contraintes induites. Activation Service Données Commentaire Externe Externe Externe Contrôle d accès aux URL protégées entièrement géré par CERBERE : c est la plate-forme d exécution qui déclenche le contrôle d accès. Cela signifie aussi que la structure des URL utilisées détermine la granularité du contrôle d accès externe à l application. Voir section 4.1.1.1. Interne Externe Externe Contrôle d accès sous-traité à CERBERE mais c est l application qui déclenche l exécution. Cette option n est pas supportée par CERBERE V2. Elle pourrait être supportée par l intégration d un composant G&CIA supplémentaire souvent appelé «Entitlement Manager». Ce type de composant est un mécanisme d évaluation de règles faisant référence à des attributs du signalétique d utilisateur, de la requête, etc. ; c est en fait une extension du CAW. Ce type de composant pourrait supporter à la fois le contrôle d accès au niveau des permissions d entreprise et au niveau des autorisations fines. Interne Interne Externe Données d autorisation gérées par CERBERE mais c est l application qui déclenche et qui implémente le contrôle d accès ; l application doit interpréter les données d autorisation CERBERE (les instances de profils applicatifs, y compris les valeurs de paramètres). Dans ce cas, il est recommandé d utiliser un réplicat (partiel) du RIA ou un annuaire LDAP intermédiaire, synchronisé par un connecteur CERBERE, comme registre des données d authentification. Interne Interne Interne Données d autorisation gérées par CERBERE et injectées dans un référentiel spécifique à l application via un connecteur d alimentation périodique mais c est l application qui déclenche et qui implémente l authentification ; les données d autorisation CERBERE (les instances de profils applicatifs, y compris les valeurs de paramètres) doivent être transposées dans le modèle de contrôle des accès interne à l application. Page 9/24
2.4. ACCES AU SIGNALETIQUE APPLICATIF En terme d intégration, il y a au moins deux cas à considérer : 1. Accès au signalétique applicatif responsable de la transaction à exécuter 2. Accès à un signalétique applicatif arbitraire L accès au signalétique applicatif responsable de l interaction dépend de l architecture technique de l application et de la manière dont l application a été intégrée avec l infrastructure CERBERE. Les cas les plus fréquents sont : 1. via les paramètres de la requête HTTP 2. via une variable de session initialisée par l enveloppe de sécurité 3. via une clé d identification pointant dans un référentiel accessible à l application a. référentiel des utilisateurs, interne à l application ou partagé entre applications d un même domaine applicatif b. référentiel métier des intervenants, interne à l application ou partagé entre applications d un même domaine applicatif L accès à un signalétique applicatif arbitraire n est pas un service standard de l infrastructure CERBERE. Quand il est requis, il sera supporté soit via un mécanisme de publication de CERBERE vers un référentiel applicatif (projet LIENS) soit via le référentiel des utilisateurs ou des intervenants, interne à l application ou partagé entre applications d un même domaine applicatif. 2.5. ACCES AUX DONNEES DE CONTEXTE LIEES AU SIGNALETIQUE APPLICATIF Si le signalétique applicatif contient des références vers des données de contexte CERBERE,l application doit pouvoir accéder à ces données de contexte. En terme d intégration, il y a au moins deux cas à considérer : 1. Données de contexte synchronisées avec une source authentique accessible à l application 2. Données de contexte synchronisées avec une source authentique inaccessible à l application Si la source authentique n est pas accessible à l application, un mécanisme de publication doit être mis en place pour rendre les données de référence accessibles à l application. 2.6. ASSOCIATION DE DONNEES SPECIFIQUES A UN UTILISATEUR RECONNU En terme d intégration, il y a au moins deux cas à considérer : 1. Absence de données spécifiques gérées par l application 2. Besoin de données spécifiques gérées par l application Page 10/24
3. INTEGRATION DES UTILISATEURS 3.1. PROCEDURE D AUTHENTIFICATION L authentification est la procédure qui permet de vérifier que l agent actif émettant la requête d accès est bien en droit d utiliser le compte concerné. La vérification est basée sur la présentation par l agent actif de titres d authentification ; ces titres doivent correspondre à ceux associés au compte concerné dans le RIA de CERBERE. 3.1.1. Application web sous le contrôle de CAW-IU L authentification est réalisée à l extérieur de l application par le CAW-IU sur base des titres d authentification stockés dans le RIA : le code applicatif ne doit donc pas s en préoccuper. Le code applicatif n est exécuté que si l authentification est exécutée avec succès. Quand le code applicatif est exécuté, il reçoit le signalétique applicatif correspondant au compte qui a été authentifié. Un des attributs transmis correspond à l attribut employeenumber du RIA (chaîne globalement unique de 8 caractères dérivée par CERBERE de l attribut cn du RIA), qui permet l identification du compte CERBERE responsable de la requête. D autres attributs sont transmis ; la liste exacte dépend de la population CERBERE concernée. Question. Comment le niveau d assurance d identification de l accès est-il transmis au code applicatif? 3.1.2. Service web sous le contrôle de CAW-S [Input de Lilian Duchêne et/ou Stéphane Tongres requis] L authentification est réalisée à l extérieur de l application par le CAW-S sur base des titres d authentification stockés dans le RIA : le code applicatif ne doit donc pas s en préoccuper. Le code applicatif n est exécuté que si l authentification est exécutée avec succès. Question. Qui est vraiment authentifié? Le compte technique de l application remote? ou un compte individuel? Quand le code applicatif est exécuté, il reçoit le signalétique applicatif correspondant au compte qui a été authentifié. Un des attributs transmis correspond à l attribut employeenumber du RIA (chaîne globalement unique de 8 caractères dérivée par CERBERE de l attribut cn du RIA), qui permet l identification du compte CERBERE responsable de la requête. D autres attributs sont transmis ; la liste exacte dépend de la population CERBERE concernée. Question. Comment le niveau d assurance d identification de l accès est-il transmis au code applicatif? 3.1.3. Application indépendante du CAW mais intégrée à CERBERE Dans ce cas c est l application (ou son environnement d exécution) qui est responsable de l exécution de la procédure d authentification. Il y a principalement deux cas à considérer : 1. Le référentiel utilisé par la procédure d authentification est le RIA de CERBERE 2. Le référentiel utilisé par la procédure d authentification n est pas le RIA de CERBERE 3.1.3.1. La procédure d authentification accède au RIA Page 11/24
Ce cas correspond souvent à une application acquise sur le marché qui est déclarée «LDAPenabled». Cela signifie que la procédure d authentification interne à l application suppose qu un annuaire LDAP externe est accessible. Cet annuaire externe peut être le RIA de CERBERE ou mieux des réplicats dédiés à des requêtes d authentification. Recommandation. Déterminer quelles méthodes d authentification sont supportées. Collecter les contraintes techniques à satisfaire pour que la procédure interne d authentification soit capable d utiliser l annuaire externe. Vérifier si ces contraintes sont compatibles avec le RIA. Tester sur un environnement de développement la réalité des résultats de cette analyse technique. Recommandation. Investiguer comment, en cas d authentification réussie, l application reçoit l identification du compte authentifié ainsi que le niveau d assurance d identification de l accès. Note. L utilisation de plusieurs réplicats dédiés permet de découpler la charge due à la gestion des utilisateurs de la charge due au contrôle d accès. Les besoins en connectivité peuvent aussi être différents. Note. La possibilité d utiliser directement le RIA de CERBERE dépend aussi des conclusions tirées lors des investigations basées sur les sections suivantes. 3.1.3.2. La procédure d authentification n accède pas au RIA Ce cas se présente dans les contextes suivants : 1. les contraintes techniques imposées par le produit ne sont pas compatibles avec le RIA ; un référentiel intermédiaire doit donc être utilisé ; 2. le produit utilise nécessairement un référentiel interne pour l authentification Dans ces deux contextes, il y a lieu de mettre en oeuvre un connecteur CERBERE capable de synchroniser à partir du RIA les titres d authentification requis par la procédure d authentification spécifique à l application. Ce connecteur CERBERE devra pouvoir interagir avec le référentiel accessible à l application. Recommandation. Déterminer quelles méthodes d authentification sont supportées. Collecter les contraintes techniques à satisfaire pour que la procédure interne d authentification soit capable d utiliser les titres d authentification disponibles dans le RIA. Vérifier si ces contraintes sont compatibles avec le RIA. Tester sur un environnement de développement la réalité des résultats de cette analyse technique. Recommandation. Investiguer comment, en cas d authentification réussie, l application reçoit l identification du compte authentifié ainsi que le niveau d assurance d identification de l accès. Recommandation. Déterminer avec l équipe CERBERE l impact sur le planning : développer un nouveau connecteur requiert l intervention de l équipe CERBERE et donc dépend de sa disponibilité. 3.2. ACCES AUX DONNEES DE L UTILISATEUR RESPONSABLE L accès aux données relatives à l utilisateur responsable de la requête correspond au dispositif par lequel le code applicatif peut consulter les valeurs des attributs du signalétique applicatif relatif à l utilisateur authentifié et autorisé. Le signalétique applicatif doit comprendre au minimum : 1. l identification du compte CERBERE concerné (en pratique l attribut employeenumber, dérivé de l attribut cn du RIA) 2. la liste des instances de profils applicatifs assignés au compte CERBERE concerné Suivant les populations, d autres attributs sont disponibles. Page 12/24
Note. Il se peut que les utilisateurs d une application soient distribués sur plusieurs populations CERBERE. Dans ce cas il faut savoir que le signalétique (ensemble des attributs disponibles) est spécifique à la population. Exemple. Les utilisateurs de l application «Contrôle de l obligation scolaire» seront : 1. des agents du MCF, logés dans la population MCF 2. des citoyens, parents d élève, logés dans la population CITOYENS 3. des agents d administrations communales, logés dans la population A2A 3.2.1. Application web sous le contrôle de CAW-IU Le mécanisme normal utilisé dans ce cas est l injection des attributs du signalétique applicatif comme paramètres de la requête HTTP. Cette injection est réalisée par le CAW-IU. La manière utilisée par le code applicatif pour consulter la valeur de ces attributs dépend de la technologie de programmation de l application Web. Pour les applications développées à l ETNIC en utilisant le langage EGL, c est l enveloppe de sécurité ACEGI qui détermine la manière dont les attributs sont présentés au code applicatif. Référence à une documentation technique de l enveloppe de sécurité ACEGI disponible. La médiation de l enveloppe ACEGI est-elle obligatoire? Si la technologie de développement est PHP, Python ou Ruby? 3.2.2. Service web sous le contrôle de CAW-S [Input de Lilian Duchêne et/ou Stéphane Tongres requis] Le mécanisme utilisé est basé sur Layer 7 XML Gateway et l ESB déployés sur la plate-forme d exécution des services web. Référence à une documentation technique sur l intégration via Layer 7 et l ESB. 3.2.3. Application indépendante du CAW mais intégrée à CERBERE Les accès à l application n étant pas sous le contrôle du CAW de CERBERE, l accès aux données relatives à l utilisateur authentifié et autorisé est entièrement spécifique à l application. La liste des attributs disponibles dépendra aussi de la manière dont le référentiel sous-jacent à l application est synchronisé avec CERBERE. Il ne faut pas perdre de vue que les utilisateurs de l application peuvent être distribués sur plusieurs populations CERBERE. 3.3. ACCES AUX DONNEES D UN UTILISATEUR ARBITRAIRE L accès aux données relatives à un utilisateur arbitraire correspond au dispositif par lequel le code applicatif peut consulter les valeurs des attributs du signalétique applicatif relatif à un utilisateur enregistré dans le RIA comme utilisateur potentiel de l application. Comme ces utilisateurs sont différents de l utilisateur responsable de la requête, les méthodes de contrôle d accès n ont que peu d impact sur le dispositif de consultation. Le dispositif dépend essentiellement de l architecture technique de l application, et notamment des méthodes d accès aux données persistantes. Page 13/24
3.3.1. Applications «LDAP-enabled» Ces applications, souvent d origne libre (open source), utilisent un référentiel d utilisateurs implémenté sur base d un annuaire LDAP. Sur base d un identifiant de l utilisateur, elles peuvent retrouver l entrée LDAP correspondante et consulter les attributs enregistrés. Suivant les choix d architecture technique, l annuaire sera : 1. le RIA de CERBERE (attributs CERBERE suffisants ; option non recommandée) 2. un réplica partiel du RIA de CERBERE (attributs CERBERE suffisants) 3. un annuaire LDAP externe à CERBERE (attributs CERBERE insuffisants) 3.3.2. Applications utilisant des tables relationnelles Les développeurs de pareilles applications maîtrisent d avantage les requêtes SQL que les requêtes LDAP ; de plus si toutes les données sont enregistrées selon le modèle relationnel, on peut définir des jointures. Il y a donc un intérêt certain à rendre disponible les données du signalétique applicatif des utilisateurs enregistrés sous la forme de tables relationnelles. 3.3.3. Méthode de constitution du référentiel externe à CERBERE Il y a essentiellement deux méthodes : 1. via un connecteur de publication sur base du RIA de CERBERE ; 2. via un enregistrement à la volée par l application du signalétique des utilisateurs lors d une requête d accès autorisée (seulement possible pour les applications contrôlées par le CAW). Le choix sera réalisé en étudiant les avantages et les désavantages des deux options dans le contexte spécifique de l intégration à réaliser. 3.3.4. Utilisateur et intervenant Par rapport à une application, les personnes physiques peuvent être classées en deux catégories complémentaires : 1. utilisateur : une personne qui interagit de manière électronique et directe avec l application 2. intervenant : une personne qui est enregistrée au sein de l application ; elle n est pas nécessairement un utilisateur ; elle peut avoir adressé un courrier ou un coup de téléphone qui a donné lieu à un dossier Si les utilisateurs sont d abord connus comme intervenants au niveau de l application, le référentiel des utilisateurs devient un sous-ensemble du référentiel des intervenants. Ce référentiel des utilisateurs ou des intervenants peut être : 1. spécifique à l application 2. partagé entre les applications d un domaine applicatif Cette question devrait sans doute être élaborée au niveau de l architecture d entreprise. 3.4. ASSOCIATIONS DE DONNEES «METIER» A UN UTILISATEUR Comme expliqué dans le Guide pour l analyse fonctionnelle, le RIA de CERBERE n a pas pour mission de consolider toutes les données «métier» utiles aux applications du MCF. Il faut donc envisager le cas où l application doit associer des données supplémentaires relatives à ses utilisateurs. On se retrouve dans un cas où un référentiel externe à CERBERE doit être utilisé. Selon l architecture technique de l application, le référentiel sera un annuaire LDAP ou une base de données relationnelle. Normalement, une partie des données sera synchronisée sur base du RIA de CERBERE tandis que les données «métier» spécifiques seront gérées par l application elle-même. Page 14/24
La constitution du référentiel pourra se faire comme décrit à la section 3.3.3, soit à la volée soit via un connecteur CERBERE. Le référentiel résultant pourra être spécifique à l application ou partagé entre les applications d un même domaine applicatif, comme déjà observé à la section 3.3. Page 15/24
4. INTEGRATION DES DROITS D ACCES 4.1. PROCEDURE D AUTORISATION : PERMISSIONS D ENTREPRISE L autorisation est la procédure qui permet de vérifier que le compte authentifié comme responsable de la requête d accès est bien en droit d exécuter la requête concernée. Au niveau de l entreprise, la vérification est basée sur (un sous-ensemble de) la liste des instances de profils applicatifs assignés au compte concerné dans le RIA de CERBERE. Note. Voir section 3 du [CERB-GD-AF]. Cette section doit être assimilée avant d aborder le reste du chapitre. 4.1.1. Application web sous le contrôle de CAW-IU L autorisation d accès à l URL demandée est réalisée à l extérieur de l application par le CAW-IU sur base des instances de profils applicatifs assignés au compte CERBERE responsable de la requête : le code applicatif ne doit donc pas s en préoccuper. Le code applicatif n est exécuté que si la procédure d autorisation est exécutée avec succès. Quand le code applicatif associé à l URL demandée est exécuté, il reçoit le signalétique applicatif correspondant au compte CERBERE responsable de la requête après qu il aie été authentifié et autorisé avec succès. Un des attributs transmis correspond à l attribut cfwbprofile du RIA, qui donne la liste des instances de profils applicatifs assignés au compte CERBERE responsable de la requête. D autres attributs sont transmis ; la liste exacte dépend de la population CERBERE concernée. Note. L autorisation acquise via le CAW-IU ne porte que sur les permissions d entreprise. Le code applicatif doit encore interpréter celles-ci pour en dériver les autorisations fines correspondantes. Voir section 3.6 du [CERB-GD-AF]. 4.1.1.1. Impact de l espace des URL à protéger sur la granularité des autorisations La procédure d autorisation du CAW-IU porte sur le droit d accès à des URL protégées. Dans les règles implémentées par le CAW-IU, les URL protégées sont spécifiées via des patrons («pattern») qui sont mis en correspondance avec l URL de la requête à autoriser. Vu le mécanisme, la structure de l espace d URL représentant les points d entrée de l application ainsi que l association des URL aux différents écrans et aux différentes transactions a toute son importance pour le partage opérationnel de responsabilité entre le CAW-IU et le code applicatif en termes de contrôle d accès. Typologie des patrons d URL à protéger Un seul patron d URL caractérise tous les points d entrée à protéger de l application. Exemple : https://dom-d/application-x/* Un patron d URL caractérise les points d entrée autorisés pour un profil applicatif spécifique à l application. Contrôle d accès Le CAW-IU vérifie que le compte possède au moins un des profils applicatifs spécifiques à l application. Le CAW-IU vérifie que le compte possède une instance du profil applicatif requis pour l URL de la requête. Exemple : https://dom-d/application-x/profil-p/* Page 16/24
Typologie des patrons d URL à protéger Un patron d URL caractérise les points d entrée autorisés pour un profil applicatif spécifique à l application et pour un contexte possible. On supposera par exemple que le contexte est représenté par la valeur du premier paramètre de l instance de profil applicatif. Exemple : https:// dom-d/application-x/profil-p/contexte-c/* Un patron d URL caractérise une catégorie de transactions disponibles à travers l application. Exemple : https:// dom-d/application-x/transaction-t/* Un patron d URL caractérise une catégorie de transactions et une collection d objets métier accessibles On supposera par exemple que le contexte est représenté par la valeur du premier paramètre de l instance de profil applicatif. Exemple : https:// dom-d/application-x/transaction-t/contexte-c/* Contrôle d accès Le CAW-IU vérifie que le compte possède une instance du profil applicatif requis pour l URL de la requête ainsi que le bon contexte. Note. Si le nombre de contextes est grand ou dynamique, cette option n est pas recommandée. Le CAW-IU vérifie que le compte possède une instance de l un des profils autorisés à exécuter la catégorie de transactions Le CAW-IU vérifie que le compte possède une instance de l un des profils autorisés à exécuter la catégorie de transactions ainsi que le bon contexte. Note. Si le nombre de contextes est grand ou dynamique, cette option n est pas recommandée. Le but de cette table est de montrer que la structure des URL a un impact important sur la granularité de l autorisation accordée par le CAW-IU, et donc, sur les hypothèses que le code applicatif peut considérer comme déjà validées. 4.1.2. Service web sous le contrôle de CAW-S [Input de Lilian Duchêne et/ou Stéphane Tongres requis] L autorisation d accès à l URL demandée est réalisée à l extérieur de l application par le CAW-S sur base des instances de profils applicatifs assignés au compte CERBERE responsable de la requête : le code applicatif ne doit donc pas s en préoccuper. Le code applicatif n est exécuté que si l autorisation est exécutée avec succès. Quand le code applicatif associé à l URL demandée est exécuté, il reçoit le signalétique applicatif correspondant au compte CERBERE responsable de la requête après qu il aie été authentifié et autorisé avec succès. Un des attributs transmis correspond à l attribut cfwbprofile du RIA, qui donne la liste des instances de profils applicatifs assignés au compte CERBERE responsable de la requête. D autres attributs sont transmis ; la liste exacte dépend de la population CERBERE concernée. Note. L autorisation acquise via le CAW-IU ne porte que sur les permissions d entreprise. Le code applicatif doit encore interpréter celles-ci pour en dériver les autorisations fines correspondantes. Voir section 3.6 du [CERB-GD-AF]. Règles de bonne pratique? Sur quoi portent les règles? l URL, le contenu de l enveloppe SOAP? 4.1.3. Application indépendante du CAW mais intégrée à CERBERE Dans ce cas c est l application (ou son environnement d exécution) qui est responsable de l exécution. Il y a principalement deux cas à considérer : Page 17/24
1. Le référentiel utilisé par la procédure d autorisation est le RIA 2. Le référentiel utilisé par la procédure d autorisation n est pas le RIA 4.1.3.1. La procédure d autorisation accède au RIA Ce cas correspond souvent à une application acquise considérée comme «LDAP-enabled». Cela signifie que la procédure d autorisation interne à l application suppose qu un annuaire LDAP externe est accessible. On peut sans doute imaginer qu une application développée sur mesure puisse utiliser directement la représentation CERBERE des instances de profils applicatifs. Par contre, il n y a aucune chance qu une application acquise sur le marché le fasse. Recommandation. Déterminer quelles méthodes d autorisation sont supportées. Collecter les contraintes techniques à satisfaire pour que la procédure interne d autorisation soit capable d utiliser l annuaire externe. Vérifier si ces contraintes sont compatibles avec le RIA. Tester sur un environnement de développement la réalité des résultats de cette analyse technique. 4.1.3.1.1. Autorisation basée sur les groupes de sécurité De manière traditionnelle, les méthodes d autorisation basées sur un annuaire LDAP utilise la notion de groupe LDAP. Les autorisations fines sont alors liées à (agrégées sur) ces groupes ; les comptes pouvant en bénéficier doivent donc être membres de ces groupes. Dans cette situation, il y a lieu 1. de définir un espace de valeurs dans le RIA pour stocker les groupes concernés, sans doute un groupe par instance de profil applicatif 2. de mettre en place un connecteur CERBERE pour traduire le bénéfice d instances de profils applicatifs en l appartenance dans les groupes correspondants. Recommandation. Cette situation n est pas recommandée dans la mesure où le RIA de CERBERE devient aussi (du moins en partie) un référentiel dédié aux besoins d une application particulière. Il vaut sans doute mieux mettre en oeuvre un annuaire intermédiaire, dédié à l application ou à un ensemble d applications qui utilisent les mêmes conventions. Note. Souvent dans ce contexte, la notion de groupe imbriqué est utilisée pour implémenter partiellement les autorisations fines. En effet, si le bénéfice d une instance de profil applicatif est représentée par l appartenance au groupe correspondant et si l accès à une transaction dans un contexte spécifique est aussi représenté par un groupe, alors les groupes représentant les instances de profils applicatifs autorisées pour la transaction peuvent être imbriqués dans le groupe représentant l accès à la transaction protégée. 4.1.3.1.2. Autorisation basée sur les attributs associés au compte responsable De plus en plus, on voit apparaître des approches basées sur un service d exécution de règles d autorisation faisant intervenir les valeurs de certains attributs liées au compte responsable de la requête ; c est l approche basée sur le modèle ABAC («attribute-based access control», contrôle des accès basé sur les attributs). Ces attributs peuvent faire partie du signalétique applicatif en provenance de CERBERE ; certains cependant pourraient être spécifiques à l application et non disponibles dans le RIA de CERBERE. Dans ce cas il faudrait ajouter un dispositif intermédiaire d acquisition des valeurs d attributs : c est la mission des composants du type «virtual directory». Les règles elles-mêmes peuvent être encodées directement dans le code applicatif ou externalisées dans un référentiel de règles ;cette base de règles est exécutable par un composant spécialisé, souvent appelé de «entitlement manager». Page 18/24
Quand ce type de règle est utilisé, alors ces règles d autorisation peuvent aussi être utilisées pour la spécification des autorisations fines. Recommandation. Cette situation n est pas recommandée dans la mesure où le RIA de CERBERE devient aussi (du moins en partie) un référentiel dédié aux besoins d une application particulière. Il vaut sans doute mieux mettre en oeuvre un annuaire intermédiaire, dédié à l application ou à un ensemble d applications qui utilisent les mêmes conventions. Note. Dans l infrastructure CERBERE, il n y a pas de composant de type «entitlement manager» ni de type «virtual directory». Si ces composants étaient acquis en même temps que l application à protéger, on peut adopter deux approches : 1. utiliser les nouveaux composants uniquement pour la nouvelle application 2. intégrer les nouveaux composants dans l infrastructure CERBERE à disposition de toute application qui le voudrait C est typiquement une question à explorer au niveau de l architecture d entreprise. 4.1.3.2. La procédure d autorisation n accède pas au RIA Ce cas se présente dans les contextes suivants : 1. les contraintes techniques imposées par le produit ne sont pas compatibles avec le RIA ; un référentiel intermédiaire doit donc être utilisé ; 2. le produit utilise nécessairement un référentiel interne pour l authentification Dans ces deux contextes, il y a lieu de mettre en oeuvre un connecteur CERBERE capable de synchroniser à partir du RIA les données d autorisation requises par la procédure d autorisation spécifique à l application. Ce connecteur CERBERE devra pouvoir interagir avec le référentiel accessible à l application. Recommandation. Déterminer quelles méthodes d autorisation sont supportées. Collecter les contraintes techniques à satisfaire pour que la procédure interne d autorisation soit capable d utiliser les données d autorisation disponibles dans le RIA. Tester sur un environnement de développement la réalité des résultats e cette analyse technique. Exemple 1. L application cible est un Active Directory qui gère l accès aux systèmes de fichiers et aux imprimantes. Les autorisations fines sont agrégées sur des groupes de sécurité dont les comptes doivent être membre pour en bénéficier. L intégration dans CERBERE de cet AD doit se faire sur base d un catalogue de profils applicatifs ; chaque instance de profil applicatif doit être mise en correspondance avec un groupe de sécurité dans l AD ; le groupe de sécurité de l AD sera le bénéficiaire des autorisations fines donnant l accès aux répertoires, fichiers et imprimantes. Exemple 2. L application cible est un module SAP. Dans ce cas, on utilise des rôles dans SAP pour agréger les autorisations fines donnant l accès aux transactions et aux données internes ; ces rôles serviront de base au catalogue de profils applicatifs CERBERE dont les instances seront mises en correspondance avec un rôle SAP distinct. Page 19/24
4.2. PROCEDURE D AUTORISATION : AUTORISATIONS FINES L autorisation est la procédure qui permet de vérifier que le compte authentifié comme responsable de la requête d accès est bien en droit d exécuter une transaction donnée sur un objet métier donné. Comme au niveau de l entreprise, la vérification est basée sur (un sous-ensemble de) la liste des instances de profils applicatifs assignés au compte concerné dans le RIA de CERBERE ; cependant elle peut aussi tenir compte d attributs supplémentaires, gérés par CERBERE ou par l application ellemême. Ce type de procédure peut être généralisé au cas de transactions qui porteraient sur plusieurs objets métier. 4.2.1. Interprétation des valeurs de paramètres des instances de profils applicatifs Les mécanismes d interprétation des valeurs de paramètres qualifiant les instances de profils applicatifs assignés au compte responsable de la requête ont pour but principal de sélectionner un sous-ensemble d objets métier parmi tous les objets métier gérés par l application et parfois de restreindre certaines propriétés de la transaction elle-même, comme un montant maximum autorisé. Le plus souvent les valeurs de paramètres proviennent d espaces de valeurs CERBERE eux-mêmes synchronisés avec des référentiels métier gérés par l application ou par d autres applications. Le filtrage des objets métier est possible parce que leur représentation possède au moins un attribut faisant référence aux mêmes référentiels métier concernés. Dans le cas contraire, un mécanisme «ad hoc» d interprétation doit être prévu du côté de l application, éventuellement basé sur des tables de transcodage. 4.2.2. Règles d autorisation Une règle d autorisation doit essentiellement décider quand l exécution de la transaction T sur l objet métier O appartenant à la collection C est autorisée pour l utilisateur U bénéficiant de l instance de profil applicatif P. Les explications de la section 4.1.3.1.2 s appliquent ici. Page 20/24
5. INTEGRATION DES DONNEES DE CONTEXTE 5.1. ACCES AUX DONNEES DE CONTEXTE L accès aux données de contexte associées à un utilisateur est le dispositif qui permet à l application de consulter les attributs des entités de contexte (organisations, unités organisationnelles, sites d implantation, etc.) auxquelles un utilisateur est associé, dans CERBERE ou ailleurs. Comme ces utilisateurs sont le plus souvent différents de l utilisateur responsable de la requête, les méthodes de contrôle d accès n ont que peu d impact sur le dispositif de consultation. Le dispositif dépend essentiellement de l architecture technique de l application, et notamment des méthodes d accès aux données persistantes, ainsi que des clés d identification utilisées. L application doit avant tout être capable de faire correspondre les clés d identification des entités de contexte en provenance de CERBERE avec les clés primaires dans les référentiels accessibles contenant les signalétiques des entités de contexte. Comme les entités de contexte enregistrées dans CERBERE proviennent normalement d un référentiel métier, cela ne devrait pas poser de problème. Quand les entités de contexte proviennent d un référentiel externe, elles devront être publiées, par CERBERE ou mieux par un mécanisme d entreprise de partage de données, dans un référentiel accessible aux applications concernées. 5.2. ACQUISITION DES DONNEES DE CONTEXTE Si lors de l analyse fonctionnelle on constate qu il n y a pas de source disponible pour certaines données de contexte considérées comme requises pour la gestion des utilisateurs, le projet d acquisition de la nouvelle application doit implémenter les sources authentiques requises ainsi que les processus d acquisition et de mise à jour des données. Les sources authentiques étant implémentées, des connecteurs CERBERE alimenteront les espaces de valeurs CERBERE correspondants. Ces espaces permettront pour une population donnée soit de positionner les utilisateurs soit de qualifier les profils applicatifs soit les deux. Il est impératif que les sources authentiques alimentant les espaces de valeurs CERBERE soient des référentiels «métier» accessibles aux applications. Sinon, comment les applications peuvent-elles interpréter les valeurs de paramètre des instances de profils applicatifs CERBERE ou les données de contexte associées aux signalétiques applicatifs. Page 21/24
6. QUELQUES CONSIDERATIONS 6.1. SITUATION : ANNUAIRE LDAP EXTERNE A L APPLICATION Il est tentant d utiliser directement les populations CERBERE comme registre des utilisateurs. Avant de se décider il faut analyser les contraintes imposées par l application. Les points suivants sont importants : 1. des extensions de schéma sont requises 2. des attributs sont modifiables par le progiciel acquis 3. la charge induite par les requêtes exécutées par le progiciel est significative 4. le modèle d autorisation spécifique au progiciel demande des développements spécifiques Recommandation. Il est souvent plus sage de mettre en place un annuaire dédié qui supportera les contraintes et la charge spécifiques au progiciel acquis et qui sera alimenté périodiquement par un connecteur CERBERE. 6.2. SITUATION : REFERENTIEL DES UTILISATEURS INTERNE A L APPLICATION Il faut constituer un registre des utilisateurs selon les spécifications du progiciel acquis et l alimenter périodiquement avec un connecteur CERBERE. Voir section Error! Reference source not found.. Recommandation. Analyser le modèle de données des signalétiques requis. Recommandation. Analyser les mécanismes d authentification possibles. Recommandation. Analyser les mécanismes de contrôle d accès et le modèle de données d autorisation. Cette analyse est requise pour comprendre comment on peut importer les données d autorisation qui régiront le contrôle d accès à l intérieur du progiciel. Sans une compréhension du modèle opératoire des mécanismes internes, il ne sera pas possible de concevoir l assujettissement de ces mécanismes aux données d autorisation provenant de CERBERE. On sera particulièrement attentif à la transposition du signalétique et surtout à la transposition des instances de profils applicatifs dans le modèle d autorisation spécifique au progiciel acquis qui servira de base au mécanisme de contrôle d accès du progiciel. 6.3. PROCEDURE D AUTORISATION INTERNE A LA RESSOURCE Le catalogue CERBERE des profils applicatifs spécifiques à une application est une vue agrégée et externalisée : l objectif est de ne montrer à l extérieur que des agrégats orientés métier des autorisations fines régissant le contrôle interne des accès. Cependant, dépendant de l architecture de l application, le dispositif de vérification interne peut être très différent. On peut toutefois considérer deux grandes catégories. Recommandation. Pour les progiciels, analyser les mécanismes possibles d agrégation des autorisations fines supportées par l application. Pour un développement sur mesure, investiguer ce qui est le plus compatible avec la situation à traiter. 6.3.1. Dispositif d autorisation basé sur l association à un agrégat identifié Page 22/24
Souvent, les progiciels utilisent une notion de groupe ou de rôle qui permet l agrégation statique d autorisations fines représentant l accès aux transactions et aux collections d objets métier disponibles. C est une approche basée sur le modèle RBAC. Règle. Le groupe ou le rôle au niveau de la ressource seront mis en correspondance avec l instance de profil applicatif CERBERE correspondant via un connecteur CERBERE. 6.3.2. Dispositif d autorisation basé sur une règle exécutable Certains progiciels peuvent utiliser un approche plus dynamique basée sur un modèle ABAC (attribute-based access control : contrôle des accès basé sur les attributs caractérisant l utilisateur responsable de la requête ou même les circonstances concommitentes). Les règles de validation (spécifiant la combinaison de valeurs d attributs permettant d exécuter un transaction sur les objets métier d une collection spécifique) peuvent être encodés «en dur» dans le code applicatif ou externalisées dans un format (exemple XACML) supporté par un moteur d autorisation ( «entitlement manager»). Le dispositif d exécution de ces règles doit pouvoir accéder la valeur des attributs requis. Note. Pour s intégrer correctement avec CERBERE, les règles de vérification doivent utiliser au moins une instance de profil applicatif comme prérequis. 6.3.3. Applications développées sur mesure Recommandation. Investiguer le modèle de contrôle d accès sur base duquel les nouvelles applications développées sur mesure seront conçues : RBAC ou ABAC. Recommandation. Une fois le modèle choisi, développer un composant qui sera réutilisée dans chaque application. 6.4. TRAÇABILITE Exemple. Les champs traditionnels de traçabilité dans les référentiels métiers : 1. agent actif responsable de la création de l enregistrement 2. agent actif responsable de la dernière modification de l enregistrement Exemple. La génération de journaux en vue d audit interne ou externe. La clé d identification doit permettre d identifier le compte CERBERE responsable de la transaction métier de manière fiable. Les données non requises, surtout si elles sont sensibles, doivent être omises. En terme d intégration, il y a au moins deux cas à considérer : 1. La clé d identification est l identifiant unique du compte CERBERE 2. La clé d identification n est pas l identifiant unique du compte CERBERE Recommandation. Dans la mesure du possible, utiliser l identifiant unique du compte CERBERE. Sinon, documenter la procédure de mise en correspondance de la clé d identification utilisée avec l identifiant unique du compte CERBERE. Note. Dans le domaine applicatif, l identifiant du compte CERBERE est l attribut employeenumber de CERBERE, dont les valeurs sont garanties uniques et ont une taille de huit caractères. Page 23/24