these doctorat une architecture de securité

Section 5.3. Authentification des entités
de sécurité dépend essentiellement de la façon dont l’application va être déployée. C’est sur cette
catégorie que l’utilisateur final peut agir. Lors du déploiement de son application, il va spécifier
une politique de sécurité. Cette politique de sécurité sera répliquée sur tous les objets composant
l’application.
La deuxième catégorie concerne spécifiquement les runtimes. Si on regarde la définition d’un
runtime, il fournit des services et les applications les utilisent. C’est pourquoi cette catégorie
de politiques de sécurité est nommée Politique du fournisseur. Lorsqu’une application utilise un
runtime, il peut :
– soit avoir été créé spécifiquement pour l’application ; dans ce cas, sa politique de sécurité
sera généralement la même que celle de l’application dont il dépend ;
– soit exister en dehors du contexte de l’application et fournir les ressources nécessaires aux
applications autorisées ; dans ce cas, sa politique de sécurité dépend de paramètres extérieurs.
Dernière catégorie, la Politique des domaines sert essentiellement à la structuration logique
d’organisations virtuelles et au regroupement sous un même domaine des diverses ressources
mises à la disposition des utilisateurs et/ou des fournisseurs de ressources. Elle est essentiellement
réservée aux administrateurs des machines sur lesquelles les runtimes s’exécutent.
tel-00239252, version 1 - 5 Feb 2008
5.2.6 Conclusion
L’approche hiérarchique que nous avons présentée possède deux avantages primordiaux :
– premièrement, elle permet une gestion décentralisée dans la création des politiques de sécurité.
Ce n’est plus à un seul acteur de définir la politique globale d’un site et d’une application
mais à différents acteurs. Un acteur (administrateur d’un site, fournisseur de ressources,
utilisateur final) du niveau n définit sa propre politique de sécurité. Cette politique
sera imposée à tous les acteurs des niveaux inférieurs (n − 1 à 0).
– deuxièmement, cela implique que, pour une interaction donnée, ce n’est pas une seule politique
de sécurité qui va s’appliquer mais un ensemble de politiques de sécurité.
De plus, afin de gérer la décentralisation et la distribution des éléments sécurisés de l’application,
nous avons doté chaque élément sécurisé d’une autonomie dans la prise de décisions de sécurité
grâce à la structuration en entités sécurisées.
Ainsi l’entité sécurisée est le concept fondamental utilisé au sein du modèle de sécurité présenté
dans cette thèse. Maintenant que nous avons une vue d’ensemble de l’architecture de sécurité,
nous pouvons présenter les mécanismes introduits pour gérer l’identification des entités
sécurisées, la manière d’exprimer des politiques de sécurité et comment, à partir d’un ensemble
de politiques de sécurité, les combiner entre elles pour n’en former qu’une seule qui sera appliquée
à une interaction donnée.
5.3 Authentification des entités
Dans cette section, nous allons nous intéresser à l’authentification des entités sécurisées. Lors
d’une interaction, le gestionnaire de sécurité doit pouvoir identifier les entités sécurisées impliquées
afin de rechercher les règles de sécurité concernant cette interaction.
Il faut se rappeler que l’un des buts poursuivis dans notre approche est de proposer une gestion
de la sécurité la plus transparente et configurable possible aussi bien pour l’utilisateur que
pour le développeur. Pour cela, on doit au mieux supprimer ou, dans le pire des cas, minimiser
une interaction entre le code de sécurité et l’utilisateur. Il nous faut une solution technique qui
permette l’automatisation des divers processus entrant en jeu dans la gestion de la sécurité. Dans
le cas qui nous intéresse maintenant, notre solution doit pouvoir créer les objets nécessaires à
l’identification d’une entité automatiquement.
73