these doctorat une architecture de securité

Chapitre 3. Étude d’intergiciels sécurisés pour le calcul distribué
tel-00239252, version 1 - 5 Feb 2008
3.4.1 Modèle de sécurité
Nous venons de voir que la création d’une application à l’aide des EJBs suppose la participation
de plusieurs acteurs avec des préoccupations différentes. Ainsi, pour que le modèle de
sécurité fonctionne, un acteur dans un rôle ne doit pas prendre de décisions trop spécifiques qui
restreindraient l’ensemble d’opérations d’un autre acteur. Par exemple, le fournisseur de Bean
ne doit pas faire de supposition sur l’existence d’un mécanisme précis d’authentification étant
donné que ce rôle incombe au déployeur d’applications qui devra choisir un mécanisme adapté à
l’application.
Afin de supporter ce paradigme de programmation, l’architecture de sécurité des EJBs inclut
les concepts de sécurité suivants :
– Une sécurité basée sur les rôles [22, 76]. Les fournisseurs de Beans et les assembleurs d’application
assignent des privilèges de sécurité à des rôles et non pas à des utilisateurs. À leur
niveau, ils ne peuvent que concevoir les divers mécanismes d’accès autour de divers rôles.
L’assignation des rôles aux utilisateurs ne sera faite que par le déployeur d’application.
– Sécurité déclarative. Un assembleur d’application spécifie de manière déclarative, dans le
descripteur de déploiement, qui (quels rôles) peut accéder à quels EJBs ou à quelles méthodes
d’un EJB. Cette séparation de la logique de l’application et de la politique de sécurité
permet de pouvoir modifier la politique de sécurité d’un EJB sans avoir à modifier son code
source.
– Sécurité par programmation. Le développeur d’un EJB peut en utilisant une API accéder
aux informations de sécurité de l’EJB. Il peut vérifier si l’utilisateur courant appartient à
un groupe précis. Toutefois il se peut que le nom d’un rôle choisi par le concepteur de l’EJB
ne corresponde pas au nom choisi par l’assembleur d’application. Cette situation résulte
notamment de la séparation des préoccupations propre à l’infrastructure des EJBs. Cependant,
le lien entre les deux rôles peut être spécifié dans un descripteur de déploiement.
– Domaines de Protection. Des entités peuvent vouloir communiquer sans passer par les mécanismes
d’authentification. Un domaine de protection est un ensemble d’EJBs qui se font
confiance mutuellement (figure 3.10). Quand un EJB interagit avec un autre au sein du
même domaine de protection, aucune contrainte de sécurité n’est positionnée concernant
l’identité de l’appelant. L’appelant peut propager son identité ou choisir une identité en
fonction des contraintes d’identification de l’appelé. Les domaines de protection sont géné-
FIG. 3.10 – Domaines de protection
ralement liés au conteneur d’EJB. Pour les appels entrants, il est de la responsabilité du
conteneur d’établir l’identité de l’appelant sous la forme d’un certificat X.509 ou d’un ticket
Kerberos. En ce qui concerne les appels sortants, le conteneur est responsable de l’établissement
de l’identité de l’appelant.
– Propagation d’identité ou délégation. L’invocation d’une méthode d’un EJB par un client authentifié,
peut être réalisée sous l’identité de l’appelant (propagation) ou sous une identité
indépendante de l’identité de l’appelant et configurée dans les descripteurs de déploiement
(délégation).
40