these doctorat une architecture de securité

Section 3.3. CORBA
// recuperation du stub.
JournalIntimePortType journalIntime = journalIntimeGL.getJournalIntimePort(new URL
("http://noadcoco.inria.fr/myservices/journalIntime");
// configuration du stub
// ces deux lignes dependent de la configuration du service que represente
// l’objet local stub
Stub stub = (Stub)journalIntime;
stub._setProperty(Constants.GSI_SEC_CONV, Constants.SIGNATURE);
stub._setProperty(Constants.GSI_SEC_CONV, Constants.ENCRYPTION);
// envoi du message
journalIntime.ajoutEntree("la pensee du jour"));
En conclusion, la flexibilité semble être le maître mot de l’approche. Cependant, le support de
l’éventail des possibilités offertes par l’utilisation des web services introduit une complexification
importante du déploiement de l’application. La transparence des mécanismes de sécurité est
gérée de manière asymétrique : une simple gestion des droits d’accès pour le serveur tandis que le
client doit configurer des variables du stub qu’il récupère en fonction de la politique exprimée par
le serveur. Il n’existe pas à notre connaissance de moyen permettant la configuration automatique
des paramètres de sécurité au niveau des stubs.
tel-00239252, version 1 - 5 Feb 2008
3.3 CORBA
La spécification CORBA (Common Object Request Broker Architecture) fait partie de l’Object
Management Architecture qui a été définie par l’Object Group Management (OMG) [96]. Elle
résulte du besoin de normalisation intrinsèque aux applications distribuées. Cette norme permet
ainsi de créer une interopérabilité entre toutes les applications distribuées qui la respectent.
Les intergiciels de communication permettent aux objets d’une application de faire, de manière
transparente, des appels de méthodes sur d’autres objets disséminés sur le réseau. Cette
transparence est rendue possible en déléguant les appels de méthodes distants à un bus logiciel,
l’Object Request Broker (ORB) ou courtier d’objets (figure 3.6). Cet ORB permet d’abstraire les
protocoles réseaux du code application et fournit une interface de nommage générique pour les
objets. Un ORB sert essentiellement à acheminer les messages d’un objet à l’autre. L’empaquetage/dépaquetage
des messages est assuré par le biais d’interfaces d’invocations. Les interfaces
des objets CORBA sont standardisées et décrites grâce à un langage commun : l’Interface Definition
Language (IDL). La localisation des objets est assurée par l’Interoperable Object References
(IOR).
En complément des fonctions de base de l’ORB, il existe un ensemble de services permettant
l’utilisation de services additionnels, les CORBAServices, tels que le nommage, les évènements,
la persistance et celui qui nous intéresse tout particulièrement, le service de sécurité.
La spécification du Service de Sécurité de CORBA [9, 29, 18] décrit les diverses caractéristiques
du service de sécurité, à savoir l’authentification, la protection des messages, l’autorisation,
l’audit et la non-répudiation des messages. Les objectifs de CorbaSec [2] sont de fournir à
un ORB les fonctionnalités de sécurité nécessaires sous la forme d’un service. Ses buts sont :
– Assurer que chaque invocation sur un objet est protégée comme requis par la politique de
sécurité
– Exiger qu’un contrôle d’accès soit effectué sur chaque invocation
– Empêcher les objets d’une application d’interférer avec ceux d’une autre application.
Plutôt que d’implémenter directement tous ces composants, le service de sécurité présente une
interface uniforme aux utilisateurs et utilise des passerelles vers des mécanismes de sécurité
déjà existants tels que Kerberos [112], SESAME ou SPKM [1]. L’interface est normalisée suivant
la recommandation RFC 2743 GSS-API [75].
35