these doctorat une architecture de securité

Section 3.5. La plateforme .NET
}
La sécurité impérative est implémentée directement dans le code. Les programmeurs entreprennent
des actions de sécurité par programme, et l’autorisation est accordée ou refusée selon
l’état de la pile de sécurité. Lorsqu’une méthode émet une demande d’accès à un fichier spécifique,
par exemple, cette demande peut échouer si l’appelant de la méthode (ou tout appelant de
l’appelant) n’a pas reçu les autorisations nécessaires. La sécurité impérative étant implémentée
par programme, les besoins en fonctionnalités dynamiques peuvent être satisfaits. La sécurité
impérative est adaptée lorsque les autorisations ou les informations nécessaires ne sont connues
qu’au moment de l’exécution de l’application.
tel-00239252, version 1 - 5 Feb 2008
void Method()
{
// on recupere le principal associe a la Thread courante
GenericPrincipal myPrincipal = Thread.CurrentPrincipal;
bool isInRole = myPrincipal.IsInRole("Responsable");
if ( isInRole )
{
// code effectue si l’appartenance de l’utilisateur
// au role est confirmee
}
}
3.5.2 Exemple
Pour la création de notre application "journal intime", nous utilisons .NET Remoting l’environnement
pour applications distribuées de la plateforme .Net.
À ce titre, son rôle consiste à fournir toute l’infrastructure nécessaire à la distribution d’objets
à l’aide de divers protocoles comme TCP ou SOAP. Si Remoting présente sur le papier une infrastructure
solide, la construction d’une architecture n-tiers expose quelques lacunes qui semblent
pourtant essentielles dans la création d’une application répartie. Nos remarques concernent tout
d’abord la création des proxies vers les objets distants qui requiert le déploiement de l’assembly
complète du serveur au sein de l’environnement du client. La deuxième remarque concerne l’absence
d’un service de nommage qui impose la prise en charge de la localisation du serveur par le
code de l’application cliente. Heureusement, il est possible de paramétrer la localisation au sein
de fichiers de configuration externes.
.Net Remoting n’offre pas nativement de mécanismes de sécurité intégré, leur gestion est généralement
déléguée à un serveur IIS Internet Information Server et à l’utilisation du protocole
HTTPS. Cependant, dans ce cas précis, nous ne voulons pas nous reposer sur ce serveur afin
d’avoir une application distribuée autonome pouvant gérer ses propres mécanismes de sécurité.
La propagation d’un contexte de sécurité d’une application cliente doit donc être réalisée de façon
ad-hoc. Cette approche est possible grâce à la structure d’une application utilisant .Net Remoting
(figure 3.13). Entre l’objet appelant et l’objet appelé, il existe un ensemble d’objets intermédiaires
permettant de masquer la distribution de l’objet serveur (Remote Proxy) mais aussi d’effectuer
des traitements personnalisés sur les messages échangés (MessageSink). Les MessagesSink se
composent d’une partie cliente et d’une partie serveur.
Quand un utilisateur déploie une application serveur, il peut référencer un fichier de configuration
lui permettant tout d’abord de décrire son application mais aussi d’affiner son comportement
notamment en précisant les divers MessageSink devant être utilisés.
Ingo Rammer, dans son ouvrage Advanced .NET Remoting [101] propose une gestion personnalisée
de l’authentification basée sur l’introduction de ces intercepteurs spécialisés entre les
objets communicants ainsi que sur l’utilisation d’un proxy modifié afin de capturer le contexte de
sécurité de l’appelant. Si l’adaptabilité du mécanisme se révèle bonne via l’utilisation de fichiers
externes, elle n’en demeure pas moins statique, le fichier de configuration d’un client devant être
modifié à chaque fois que la configuration du serveur est modifiée.
45