GCAX : Module de Génération de Certificat d’Attributs en XML

4.3 Architecture de l’E-IGP

4.3.1 Principe de fonctionnement

4.3.1.1 GCAX : Module de Génération de Certificat d’Attributs en XML

GCAX [SETIT04] est une entité qui a pour but d’accorder des droits aux utilisateurs pour des applications données. Le GCAX est l’interface qui prend en charge la génération de certificats d’attributs en XML suivant une politique donnée. GCAX est une interface interactive utilisant les technologies JSP [JAV] et Servlet [JAV].

Dans cette partie, nous décrivons les étapes que l’utilisateur devra suivre pour avoir un certificat d’attributs pour accéder à une application donnée (voir figure 4-5).

Figure 4-5 GCAX : Module de Génération de Certificat d’Attributs en XML

In te r fa c e s é c u r is é e G C A X : G é n é r a tio n d e C e r tific a t d ’ A t tr ib u ts e n X M L V é r ific a tio n d u c e r tific a t d ’id e n tité D e m a n d e s d e c e rtif ic a ts d ’a ttrib u ts B a s e d e D o n n é e s S i le c e rtific a t d ’id e n tité p ré s e n té e s t v a lid e ,

a ffic h a g e d e la lis te d e s a p p lic a tio n s . R é c u p é ra tio n d e la D T D c o rre s p o n d a n te . A ffic h a g e d u fo rm u la ire .

C ré a tio n d ’u n fic h ie r c o n te n a n t la re q u ê te d u c lie n t e t S to c k a g e d e c e lu i c i d a n s la b a s e d e s d e m a n d e s e n a tte n te . U tilis a te u r

C h o ix d e l’a p p lic a tio n

E n v o i d u fo rm u la ir e re m p li D T D s d e s a p p lic a tio n s L é g e n d e : C e rtific a t d ’id e n tité

a ffic h a g e d e la lis te d e s a p p lic a tio n s . R é c u p é ra tio n d e la D T D c o rre s p o n d a n te . A ffic h a g e d u fo rm u la ire .

C ré a tio n d ’u n fic h ie r c o n te n a n t la re q u ê te d u c lie n t e t S to c k a g e d e c e lu i c i d a n s la b a s e d e s d e m a n d e s e n a tte n te . U tilis a te u r

U tilis a te u r

C h o ix d e l’a p p lic a tio n C h o ix d e l’a p p lic a tio n

E n v o i d u fo rm u la ir e re m p li D T D s d e s a p p lic a tio n s L é g e n d e : C e rtific a t d ’id e n tité L é g e n d e : C e rtific a t d ’id e n tité

Pour que l’utilisateur puisse accéder au GCAX, il se connecte avec son navigateur Web via le protocole HTTPS (HTTP [RFC2616] sécurisé par le protocole SSL [RFC2246]). De ce fait, il utilise le protocole SSL pour ouvrir une connexion sécurisée avec le serveur. A travers SSL, l’utilisateur envoie son certificat d’identité X509 et s’authentifie à notre serveur SSL.

Une fois l’identité assurée et authentifiée, le GCAX visualise à l’utilisateur, à travers une page Web, les différents types d’applications qu’il possède. L’ensemble des applications pour lesquelles il est possible de demander des privilèges, ainsi que les privilèges associés, est référencé dans une base de données. L’utilisateur à travers cette page Web, choisit l’application qu’il désire accéder. Une fois le choix fait, GCAX récupère de sa base de données la grammaire associée à cette application et présente à l’utilisateur une interface qui visualise les différents champs ou options de cette application. C’est l’utilisateur qui précise les valeurs des paramètres de l’application, la date de validité de son certificat d’attributs, les rôles qu’il souhaite avoir ou les délégations (si elles existent) qu’il souhaite fournir à quelqu’un suivant ces besoins, etc.

Une fois que l’utilisateur spécifie l’application, pour laquelle il souhaite recevoir des privilèges particuliers et personnalise sa demande de certificat d’attibuts (voir figure 4-6), cette demande (ou formulaire de demande) est alors stockée dans la base de données des demandes en attente de GCAX qui parviennent automatiquement à l’administrateur. Ce dernier décidera sur l’accord ou le refus d’attribution d’un certificat d’attributs à l’utilisateur suivant sa politique appliquée. Une fois une requête est validée (accord d’attribution), l’administrateur signe et envoie le certificat d’attributs à l’utilisateur.

Figure 4-6 Scénario de création d’une demande de certificat d’attributs

La génération des certificats d’attributs en XML dans l’E-IGP se base essentiellement sur les DTDs (Document Type Definition) [W3CDTD]. La DTD est une grammaire permettant de vérifier la conformité du document XML. En effet, c'est grâce à celle-ci que l'administrateur personnalisera les certificats d'attributs que l'utilisateur pourra demander.

Les DTDs serviront donc de schémas pour la génération des certificats d'attributs en XML. Les données qu'elles contiennent sont extraites, de manière transparente pour l'utilisateur, par un Servlet [JAV] appelé par l'utilisateur (voir figure 4-7).Le formulaire de demande de certificat d'attributs est, par la suite, créé dynamiquement à partir des données contenues dans la DTD choisie. Une option de cette personnalisation permettra de vérifier que les fichiers XML créés (correspondant chacun à une demande de certificat d'attributs) soient bien valides, c’est-à-dire, qu'ils soient bien conformes à la DTD choisie par l'utilisateur.

Récupération des privilèges de l’application choisie par l’utilisateur

Création de la demande de certificats d’attributs

Formulaire de demande

Formatage des privilèges pour obtenir un formulaire

Figure 4-7 Rôle des DTDs

Un certificat d’attribut doit être couplé à un ou plusieurs certificats d’identité valides. Ce certificat d'attributs généré est signé par la clef privée de l’autorité GCAX (l’administrateur). Le format de signature utilisé est le format XML-DSIG (voir figure 4-11) [RFC2807], afin d’éviter la signature en format PKCS#7 [RFC2315] qui est spécifiée en ASN.1.

XML-DSIG permet d’attacher une signature au certificat dans une étiquette, de rendre possible l’inclusion de la signature numérique dans le certificat lui-même, et même de pouvoir inclure le certificat dans l’étiquette de signature numérique.

Une fois ce certificat d’attributs créé, il est envoyé au client. Une trace de ce certificat d’attributs est sauvegardée dans la base de données commune entre les deux modules "GCAX" et "V&CAA".

4.3.1.1.1 Les privilèges variables des applications

La problématique étant de contrôler les droits des utilisateurs lors de leur accès aux applications réseau, nous avons choisi de définir des critères et des niveaux de privilèges que l’on peut donner aux utilisateurs pour chaque application.

Le niveau de privilèges le plus commun correspond à l’administration ou à la simple utilisation de l’application. Ensuite, les privilèges peuvent être très variés, par exemple, ils peuvent correspondre à l'aspect général de l’application, aux options de mise en page, etc.

Ces différents critères sont alors stockés dans une base de données sous forme de DTD. Le rôle d’une DTD est de définir la structure interne de certificat d’attributs. Ainsi, la DTD d’une application permet de structurer les droits qu’elle va accepter de la part des utilisateurs. Le document que ces derniers présenteront sera formaté pour les besoins de l’application.

Chaque application définit ses critères de privilèges variables dans un document qui est stocké dans une base de données de l’E-IGP.

La figure 4-8 représente un exemple de DTD pour une application de convertisseur de devises en ligne: Servlet Servlet Option: Validation du fichier XML Formulaires HTTP : Compta Project Compta <Name> <Organization Unit > <Office> <Phone> _Project <Project Name> <Organization> <Organization Unit> <Project Manager> Grammaires DTD : Fichiers XML : <xml…. DTD compta… <compta> <name> … </name>

<?xml version="1.0" encoding="UTF-8"?>

<!ELEMENT Convertisseur (Langue, Couleur, Droits) > <!ATTLIST Convertisseur URL CDATA #FIXED

"http://localhost:8080/portail/index.jsp"> <!ELEMENT Langue (#PCDATA) >

<!ATTLIST Langue TypeData CDATA #FIXED "list">

<!ATTLIST Langue Values (Français | Anglais) "Français"> <!ATTLIST Langue Label CDATA #FIXED "Langue du convertisseur"> <!ELEMENT Couleur (#PCDATA) >

<!ATTLIST Couleur TypeData CDATA #FIXED "list">

<!ATTLIST Couleur Values (Bleu | Vert | Jaune) "Jaune">

<!ATTLIST Couleur Label CDATA #FIXED "Couleur du convertisseur"> <!ELEMENT Droits (#PCDATA) >

<!ATTLIST Droits TypeData CDATA #FIXED "list">

<!ATTLIST Droits Values (Utilisateur | Administrateur) "Utilisateur"> <!ATTLIST Droits Label CDATA #FIXED "Droits">

Figure 4-8 DTD d’un convertisseur de devices

Cet exemple, très simple, illustre la diversité des privilèges qui peuvent être accordés à un utilisateur.

4.3.1.1.2 L’encodage de la demande de droits en XML

La complexité du codage ASN.1 des certificats d’attributs bien qu’adaptée à la gestion des droits, se révèle complexe à mettre en œuvre. Nous avons donc choisi un encodage en XML [SSGRR03].

Lorsque le formulaire est rempli par l’utilisateur, une demande de droits est créée à partir de ces informations. Cette demande est codée en XML et stockée dans la base de données des demandes en attente. L’intervention de l’administrateur de l’IGP est alors indispensable pour transformer cette demande en certificat d’attributs, qui sera ensuite utilisable auprès du portail d’accès aux applications (voir figure 4-9).

Figure 4-9 Validation des demandes de certificats d’attributs

GCAX: Génération de Certificat d’Attributs en XML GCAX: Génération de Certificat d’Attributs en XML Interface sécurisée Sélection de la demande. Si la demande est acceptée:

- Signature de la demande (= génération du certificat d’attribut).

- Envoi du certificat d ’attribut à son propriétaire par mail.

- Destruction de la demande de la base de données.

@

Administrateur

Si vérification OK, affichage de la liste des demandes de certificat d’attributs en attente. Si vérification OK, affichage de la liste des demandes de certificat d’attributs en attente. Base de Données Demandes de certificats d’attributs DN des administrateurs de la E-IGP Base de Données Demandes de certificats d’attributs DN des administrateurs de la E-IGP Vérification de l’habilitation

Si la demande est rejetée:

- Envoi d’un mail pour informer le demandeur. - Destruction de la demande de la base de données.

Légende: Certificat d’identité Légende: Certificat d’identité

4.3.1.1.3 Importance de XML

XML a pris une importance considérable dans le monde du commerce électronique puisqu’il autorise l’échange de données dont on définit la structure spécifique dans un langage standardisé.

Ainsi, l’approche de spécification des certificats d’attributs en XML bénéficie des avantages suivants relatifs au langage XML [SAR02]:

1. Ce standard promulgué par le W3C [W3C], définit un format universel de représentation des données. XML deviendra en outre le pivot de l’interopérabilité, en permettant l’échange de documents qui ne transitent pas forcément par Internet, tels que ceux générés par les différentes applications bureautiques.

2. A la manière d’ASN.1, XML est un langage extensible de description des données, structuré et indépendant des plates-formes. Un avantage par rapport à ASN.1 est sa lisibilité (le fait qu’il soit en format de texte simple le rend lisible à la fois par les machines et par les utilisateurs. Ainsi, les certificats sont plus explicites pour les utilisateurs et les développeurs informatiques), mais il aurait été tout à fait possible de réaliser avec ASN.1 ce qu’on fait avec XML. L’unicité des OID (Object Identifier) ASN.1 est traitée en XML en faisant des références à des ressources uniques dans des domaines de nommage.

3. XML est un métalangage qui offre la possibilité de définir les balises dont on a besoin et de leur associer une interprétation. XML est flexible, ce qui limite les problèmes d'interopérabilité.

4. XML est un langage orienté objet qui définit sans ambiguïté aussi bien le contenu que la structure d’un document. Il fait la distinction entre la structure d’un document et sa présentation. Orienté vers le monde Internet et web, XML distingue la nature essentielle des données transportées (types, hiérarchie dans le document), de la manière dont l’environnement d’utilisation les traite et les affiche. Il est alors plus facile de créer des agents d’affichage qui sont adaptés aux terminaux et qui optimisent la visualisation des données. Les langages tels que HTML lient intimement les données et leurs fonctions d’affichage, ce qui rend difficile le portage de pages dans des environnements de visualisation contraints.

5. Il nécessite une puissance de calcul pour le traitement beaucoup plus faible que celle de l'ASN.1 (car il est facile de parser un document XML, ce qui n'est pas le cas d'un document ASN.1) [OCTALIS].

6. XML peut être utilisé en parallèle avec les protocoles d'Internet, DTDs et d'autres utilitaires qui peuvent interpréter la sémantique de contenu d'un document XML. Les descriptions des structures de documents, les DTD, sont réutilisables et bénéficient, par principe, de certains concepts de la technologie objet. On peut réutiliser les structures des données et réduire ainsi les durées de développement des logiciels associés.

7. La possibilité de faire des références externes (localisation de documents sur le réseau) et croisées entre section de documents.

Les avantages potentiels de XML comme véhicule de communication sont significatifs. Ces propriétés font de XML un outil de choix pour, d’une part, encapsuler et véhiculer des données de transaction d’une manière souple et, d’autre part, les afficher sur les terminaux variés (ordinateurs, téléphones portables, assistants personnels, etc.). Mais véhiculer des données de transaction sur un réseau appelle automatiquement leur protection. La signature XML [RFC2807] [RFC3275] intervient à ce niveau.

4.3.1.1.4 La création du certificat d’attributs

L’administrateur de l’infrastructure de gestion des privilèges a le rôle d’autorité de confiance pour la signature des demandes de droits.

La consultation des demandes lui permet soit de les rejeter, et dans ce cas l’utilisateur est informé par mail, soit de les accepter.

La signature de la demande codée en XML va produire un certificat d’attributs (voir figure 4-10), lui aussi codé en XML.

La signature XML [RFC3275] [SAR02] de la demande a plusieurs avantages : • Elle est basée sur XML, plus simple que celle basée sur le codage ASN.1.

• Elle permet de signer tout ou une partie du document ou même une partie extérieure référencée par une URI dans le document.

• Elle garantit l’intégrité du contenu du document et confirme l’identité de l’autorité signataire.

• Elle autorise également plusieurs entités à signer les différentes parties d’un même message sans pour autant invalider les autres [RFC2807].

• La signature est embarquée dans le document, «envelopped signature» [RFC3275]. Pour toutes ces raisons, nous avons choisi d’utiliser la signature XML des certificats d’attributs.

Figure 4-10 Format d’un certificat d’attributs en XML

Une fois le certificat d’attributs créé (voir figure 4-11), il est envoyé par mail à son propriétaire. L’utilisateur doit alors l’activer pour pouvoir en faire usage. Pour cela, il s’adresse au vérificateur de droits (V&CAA : Module de Vérification et de Contrôle d’Accès aux Applications).

Lien vers X509 Certificate

reference

Issuer Certificate

reference

Subject depth Delegation Name Ressource Validity Attribute Content Algorithme Signature Version Type CertificateInfo AttributeCertificate Droits Privilèges

Figure 4-11 Exemple d’un certificat d’attributs en XML signé par XMLDSIG

Dans le document Services d'autorisation et Intégration au protocole d'attribution dynamique des adresses (Page 61-67)