Soutenance mémoire
LE MODÈLE DE SÉCURITÉ DE JAVA
LA PROGRAMMATION PAR VUE
Introduction
Après un certain temps, un système informatique peut évoluer dans ses comportements et ses rôles. De nouvelles fonctionnalités sont, à travers son cycle de vie, ajoutées ou supprimées, activées ou désactivées [Mili et al., 2002] [Mcheick, 06]. Aussi, chacun des clients du système, autant les usagers humains que les systèmes informatiques externes, ont des besoins variables qui peuvent exiger un changement de vocation du système utilisé. Le système doit être évolutif pour y répondre. À plus petite échelle, on peut dire que plusieurs clients observent et utilisent des aspects distincts du même objet. Afin de permettre l’utilisation adéquate de l’objet, il convient d’insérer des
mécanismes de gestion et de sécurité. Une série de mécanismes de gestion existent déjà dans la plupart des langages objet (ex. : gestionnaire de sécurité de Java, polymorphisme). Beaucoup de leurs fonctionnalités techniques sont bien connues et bien documentées. Toutefois, il devrait être possible de pouvoir regarder l’objet de base sous un angle plus fonctionnel que technique. Prenons
l’exemple d’un dossier étudiant qui serait représenté par une classe InfoEtudiant.
LA PROGRAMMATION PAR VUE
Dynamiquement, on devrait être en mesure de décider si les informations de l’étudiant existeraient en tant qu’ensemble de données nécessaire à la création d’un rapport ou encore à la génération d’un bordereau de paie. De plus, à un moment ultérieur, la classe Info Etudiant pourrait être utilisée pour créer et tenir à jour un profil d’apprentissage dynamique dans un site en ligne. Dans cette mise en situation, l’objet de base InfoEtudiant ne devrait pas subir de modifications à chaque apparition d’un nouveau besoin. Il serait même préférable qu’il ne soit pas conscient de toutes ces modifications de besoin. On arrive rapidement à la limite des interfaces conventionnelles dont l’utilisation est fixée à la compilation de la classe.
Tour d’horizon
Dans le but de faire évoluer le rôle de l’objet et de permettre son adaptation, diverses solutions ont été apportées au fil des ans. Parmi les approches existantes, nous distinguons notamment la programmation par sujet (Subject-Oriented Programming SOP) [CSS, 01], la programmation par aspect (Aspect Oriented Programming AOP) [DotNetGuru, 03] et la programmation par vue (View oriented Programming VOP) [Mili et al., 99]. La première et la plus ancienne, la programmation par sujet, permet de fusionner des applications ayant une interface semblable et offrant une implementation différente de la même entité. Par exemple, deux applications PI et P2 ayant chacune une interface Employe. La programmation par sujet propose de les combiner afin d’obtenir une interface unique (Employe_Pl 0 Employe_P2 -> Employe) [Harrison et Ossher, 1993]. Cette approche permet d’élargir et de compléter les rôles de chaque objet. Avec la programmation par aspect, la séparation des préoccupations peut être utilisée comme une solution permettant d’identifier, d’encapsuler et de manipuler les parties d’un logiciel qui sont pertinentes pour un domaine particulier. Ces dernières sont ensuite composées grâce à des points de jointure selon l’approche utilisée. La séparation entre les préoccupations (rôles) qu’un objet peut jouer facilite la maintenance, la compréhension, la réutilisation des applications et permet la modularité [Kiczales et al., 97]. Par exemple, on pourrait identifier une préoccupation reliée à la sécurité, définir un code de gestion en Java et l’intégrer à des points de jointure prédéfinis à l’aide d’outils (ex : AspectJ [Eclipse, 03]) La programmation par vue est l’approche qui sera utilisée pour cette étude. On suppose qu’une entité peut jouer différents rôles fonctionnels à différents moments de sa vie [Mcheick, 06]. La prochaine section aborde en détail la programmation par vue.
Allant de pair avec la gestion des comportements, il faut aussi considérer la gestion des accès. Plusieurs approches existent mais deux ont particulièrement retenues notre attention : RBAC et JAAS. La gestion des accès par rôle (RBAC), reposant à la base sur une solution développée par le département de la justice américain [NIST, 09], a été habilement implémentée dans un contexte client-serveur reposant sur l’infrastructure CORBA [Fink et al., 03]. Le principe peut être résumé simplement. Un client est en relation avec un serveur (ex : Tomcat) offrant des accès à des services Web. Le serveur permet l’authentification des usagers, mais le processus d’autorisation se limite à permettre d’utiliser ou non un service Web. À l’aide d’un langage basé sur le XML (View Policy Language (VPL)) et d’outils de configuration, la solution permet de prendre le relai et de gérer les accès au niveau des méthodes. Ceci étant, chaque rôle se voit attribuer des droits d’accès à certaines méthodes. Ce modèle est notamment implémenté dans le logiciel Microsoft Exchange Server 2010 où il permet d’effectuer la gestion des permissions [Microsoft, 09]. Notre modèle de sécurité ne suivra toutefois pas cette approche, quoique très intéressante, car elle est trop lourde (service Web, Corba ou EJB) et contraignante (client-serveur) pour une communication simple entre deux objets (Objet de base et objet d’application) Le modèle de sécurité de notre solution fera usage de JAAS (Java Authentication and Authorization Service), une librairie de développement gratuite standardisée par Sun Microsystems. Le chapitre 3 y est entièrement consacré.
Description
La programmation par vue est une alternative à la programmation par aspect. On cherche à voir le système, et la classe à moindre échelle, comme une entité qui pourrait jouer différents rôles fonctionnels à différents moments de sa vie. On ne tente pas de s’insérer à travers les entités à l’aide de coupes transversales plutôt techniques, ce qui est déjà réalisé par la programmation par aspect. Une approche fonctionnelle avec un certain degré de recul est privilégiée. On doit définir une méthode d’utilisation de l’objet, sans intervention dans le code ni dans le processus déjà en place. Continuons avec l’exemple de la classe InfoEtudiant qui existe, compilée, dans un système. L’ajout d’un module d’archivage ou d’administration pourrait réclamer de nouvelles fonctionnalités à la classe. Par exemple, InfoEtudiant pourrait être initialement instanciée comme un objet d’administration et pourrait, à tout moment, devenir un objet archivable avec les méthodes spécifiques appropriées. Pour réussir ce tour de force, on doit encapsuler l’utilisation de la classe InfoEtudiant afin de permettre son emploi sous une autre facette tout en gardant son intégralité. Nous fournirons donc à l’utilisateur de ce nouvel objet une interface adaptée à ses besoins fonctionnels indépendante ou en complément à l’objet lui-même. La programmation par vue a pour objectif de supporter cette évolution de comportement des objets dans le langage hôte.
Principes de base
On suppose que chaque objet du domaine d’application prend en charge un ensemble de fonctionnalités de base offertes à tous les programmes utilisateur et d’autres fonctionnalités qui sont spécifiques à certains autres usagers de l’objet. Cette supposition généralise les interfaces de visibilité (privées, protégées, publiques, package) dans les langages de programmation objet tels que Java ou C#. Les interfaces peuvent aussi correspondre à des domaines fonctionnels différents ayant leurs propres attributs et méthodes non offerts par l’objet de base. En fait, les interfaces, en ce sens, procurent un rôle particulier à un objet de base plutôt qu’une simple restriction d’accès. La programmation par vue définit les principes de base suivants qui devront conserver leur véracité tout au cours de notre étude : • Un objet peut changer de comportement durant l’exécution, en acquérant et perdant des fonctionnalités durant l’exécution (dynamisme) • On doit pouvoir utiliser l’objet de façon transparente indépendamment du fait qu’il offre présentement la fonctionnalité ou non (transparence) • On doit être capable d’accéder à plusieurs vues simultanément (simultanéité)
• Chaque comportement/vue doit avoir ses propres données qui doivent être préservées entre les activations (permanence) • Lorsqu’un comportement est pris en charge par plusieurs vues, toutes les versions de ce comportement sont invoquées selon la composition précisée au développement (structure) • La programmation par vue repose sur le concept de points de vue qui sont des patrons génériques. Ces patrons sont applicables sur un domaine d’application donné pour obtenir une vue (abstraction) Reprenons l’exemple de notre classe InfoEtudiant représentant des informations reliées au profil étudiant. Supposons que l’on veuille vérifier si l’étudiant est endetté, mais que cette fonctionnalité n’existe pas dans l’objet InfoEtudiant. On prend la liberté d’ajouter une méthode enDette(…) afin de questionner adéquatement l’objet de base. Cette méthode ne sera pas définie dans l’objet lui-même, mais ajoutée à travers 1’implementation des vues. Avec cette nouvelle utilisation, on ajoute une couche d’abstraction. De ce fait, on n’aura peut-être plus accès, par choix de 1’implementation, à l’ensemble des méthodes de la classe InfoEtudiant. Au besoin, cette dernière pourra toujours être utilisée sous sa forme originale.
La programmation par vue prévoit également qu’un client puisse utiliser, à sa guise, la classe InfoEtudiant. Il pourra être un client administratif pour un instant et devenir un outil de génération de rapport financier ou même encore les deux à la fois. La section 2.4.5 traite des méthodes d’accès simultanés à l’objet.
|
Table des matières
INTRODUCTION
1.1 ÉNONCÉ DE LA PROBLÉMATIQUE
1.2 PRINCIPE DE SOLUTION
1.3 CONTRIBUTION
1.4 STRUCTURE DU MÉMOIRE
LA PROGRAMMATION PAR VUE
2.1 INTRODUCTION
2.1.1 Tour d’horizon
2.2 DESCRIPTION
2.3 PRINCIPES DE BASE
2.4 ÉLÉMENTS DE LA PROGRAMMATION PAR VUE
2.4.1 Vue et points de vue
2.4.2 Objet de base et objet d’application
2.4.3 Gestion des vues
2.4.4 La délégation des appels
2.4.5 La composition des vues
2.5 AVANTAGES DE LA PROGRAMMATION PAR VUE
2.6 EXEMPLE
LE MODÈLE DE SÉCURITÉ DE JAVA
3.1 JAVA
3.2 GESTION DES ACCÈS AUX RESSOURCES
3.2.1 Fonctionnement du sandbox
3.2.2 Le gestionnaire de sécurité
3.2.3 Clés et signature
3.3 JAAS (JAVA AUTHENTICATION AND AUTHORIZATION SERVICE
3.4 PROCESSUS D’AUTHENTIFICATION
3.4.1 Entité et identité
3.4.2 Contexte d’authentification
3.4.3 Module d’authentification
3.4.4 Gestionnaire de communication
3.5 PROCESSUS D’AUTORISATION
3.5.1 Les permissions
3.5.2 Les politiques de sécurité
3.5.3 Fonctionnement
3.6 MODÈLE DE SÉCURITÉ EN UML
ÉNONCÉ DE LA PROBLÉMATIQUE
4.1 ÉNONCÉ 55
4.2 APPROCHE ACTUELLE DE LA PROGRAMMATION PAR VUE
4.2.1 Le rôle du client
4.2.2 Persistance des vues
4.2.3 Permanence du profil
4.2.4 Transparence d’utilisation des vues
4.2.5 Évolution dynamique
4.2.6 Problème de droits
4.2.7 Gestion des appels
4.3 LA PROBLÉMATIQUE DE DÉLÉGATION
4.4 LA PROBLÉMATIQUE DE SÉCURITÉ
4.5 LA PROBLÉMATIQUE DE LA SYNCHRONISATION
4.6 LA PROBLÉMATIQUE DE L’EXÉCUTION PARTIELLE
4.7 EN CONCLUSION
LE MODÈLE DE SÉCURITÉ DES VUES
5.1 ANALYSE DE LA SOLUTION
5.1.1 Schéma global de I ‘object conceptuel ObjApp
5.2 IDENTIFICATION DU CLIENT
5.2.1 La classe VOPLogin
5.2.2 La classe Subject.
5.2.3 La classe ObjAppSecure
5.2.4 Diagramme de séquence de l’authentification
5.3 LA COMMUNICATION
5.4 LES VUES
5.4.1 La classe VuePermission
5.4.2 Configuration des vues
5.4.3 Sécurité des vues
5.5 L’OBJET D’APPLICATION
5.5.1 La méthodegetVue
5.5.2 La méthode execute
5.5.3 La classe VOPPrivilegedAction
5.5.4 Implementation
5.5.5 Diagramme de séquences de l’autorisation
5.5.6 Exemples d’exécution d’une méthode sécurisée
5.6 L A SOLUTION AVEC JAVA (JAAS)
5.6.1 Organisation
5.6.2 Implementation
5.7 UTILISATION DES ASPECTS
5.8 L A SOLUTION COMPLÈTE
RÉSULTATS ET ANALYSE
6.1 LA PROPOSITION À LA PROBLÉMATIQUE DE L’APPROCHE ACTUELLE
6.1.1 Le rôle du client
6.1.2 Persistance des vues et permanence duprofil
6.1.3 Transparence d’utilisation des vues
6.1.4 Evolution dynamique
6.1.5 Problèmes de droits
6.1.6 Gestion des appels
6.2 LA PROPOSITION À LA PROBLÉMATIQUE DE DÉLÉGATION
6.3 LA PROPOSITION À LA PROBLÉMATIQUE DE SÉCURITÉ
6.4 LA PROPOSITION À LA PROBLÉMATIQUE DE SYNCHRONISATION
6.5 LA PROPOSITION À LA PROBLÉMATIQUE D’EXÉCUTION PARTIELLE
CONCLUSION
BIBLIOGRAPHIE
ANNEXES
Télécharger le rapport complet
