Emprunt d’identité et délégation du client
Dans certains cas, une application serveur doit présenter l’identité d’un client aux ressources auxquelles il accède au nom du client, généralement pour provoquer l’exécution de vérifications d’accès ou d’authentification par rapport à l’identité du client. Dans une certaine mesure, le serveur peut agir sous l’identité du client, une action appelée emprunt d’identité du client.
emprunt d’identité est la capacité d’un thread à s’exécuter dans un contexte de sécurité différent de celui du processus propriétaire du thread. Le thread de serveur utilise un jeton d’accès représentant les informations d’identification du client et, avec cela, il peut accéder aux ressources auxquelles le client peut accéder.
L’utilisation de l’emprunt d’identité garantit que le serveur peut faire précisément ce que le client peut faire. L’accès aux ressources peut être limité ou étendu, selon ce que le client a l’autorisation de faire.
Vous pouvez choisir d’emprunter l’identité d’un serveur lors de la connexion à une base de données afin que la base de données puisse s’authentifier et autoriser le client lui-même. Ou, si votre application accède aux fichiers protégés par un descripteur de sécurité et pour permettre au client d’obtenir un accès autorisé aux informations contenues dans ces fichiers, l’application peut emprunter l’identité du client avant d’accéder aux fichiers.
Comment implémenter l’emprunt d’identité
L’emprunt d’identité nécessite la participation du client et du serveur (et, dans certains cas, les administrateurs système). Le client doit indiquer sa volonté de laisser le serveur utiliser son identité et le serveur doit supposer explicitement l’identité du client par programmation. Pour plus d’informations, consultez les rubriques Client-Side Conditions requises pour l’emprunt d’identité et Server-Side Conditions requises pour l’emprunt d’identité.
Exigences administratives pour l’emprunt d’identité Delegate-Level
Pour utiliser efficacement la forme la plus puissante d’emprunt d’identité, délégation, qui est l’emprunt d’identité des clients sur le réseau, les comptes d’utilisateur client et serveur doivent être correctement configurés dans le service Active Directory pour le prendre en charge (en plus de l’autorité d’octroi du client pour effectuer l’emprunt d’identité au niveau délégué), comme suit :
- L’identité du serveur doit être marquée comme « Approuvé pour la délégation » dans le service Active Directory.
- L’identité du client ne doit pas être marquée comme « Le compte est sensible et ne peut pas être déléguée » dans le service Active Directory.
Ces fonctionnalités de configuration donnent à l’administrateur de domaine un degré élevé de contrôle sur la délégation, ce qui est souhaitable, en fonction de la quantité d’approbation (et donc de risque de sécurité) impliqué. Pour plus d’informations sur la délégation, consultez délégation et emprunt d’identité.
Dissimulation
En plus de l’autorité qu’un client accorde à un serveur par le biais du niveau d’emprunt d’identité, la fonctionnalité de masquetage du serveur détermine en grande partie le comportement de l’emprunt d’identité. Le cloaking affecte l’identité qui est réellement présentée par le serveur lorsqu’il effectue des appels au nom du client , son propre ou celui du client. Pour plus d’informations, consultez Cloaking.
Implications en matière de performances
L’emprunt d’identité peut affecter considérablement les performances et la mise à l’échelle. Il est généralement plus coûteux d’emprunter l’identité d’un client sur un appel que de passer directement l’appel. Voici quelques-unes des questions à prendre en compte :
- Surcharge de calcul du passage de l’identité dans des modèles complexes, en particulier si le masquage dynamique est activé.
- La complexité générale de l’application d’un contrôle de sécurité redondant dans de nombreux endroits, au lieu d’être centralisée dans le niveau intermédiaire.
- Les ressources telles que les connexions de base de données, lors de l’ouverture de l’identité d’un client, ne peuvent pas être réutilisées sur plusieurs clients, un obstacle très important à la mise à l’échelle.
Parfois, la seule solution efficace à un problème consiste à utiliser l’emprunt d’identité, mais cette décision doit être soigneusement pesée. Pour plus d’informations sur ces problèmes, consultez sécurité des applications multiniveau.
Composants mis en file d’attente
composants mis en file d’attente ne prennent pas en charge l’emprunt d’identité. Lorsqu’un client effectue un appel à un objet mis en file d’attente, l’appel est effectivement effectué à l’enregistreur, qui l’empaquette dans le cadre d’un message sur le serveur. L’écouteur lit ensuite le message de la file d’attente et le transmet au lecteur, qui appelle le composant serveur réel et effectue le même appel de méthode. Par conséquent, lorsque le serveur reçoit l’appel, le jeton client d’origine n’est pas disponible via l’emprunt d’identité. Toutefois, la sécurité basée sur les rôles s’applique toujours et la sécurité programmatique à l’aide de l’interface ISecurityCallContext fonctionne. Pour plus d’informations, consultez sécurité des composants mis en file d’attente.
Rubriques connexes
-
Role-Based d’administration de la sécurité
-
à l’aide de la stratégie de restriction logicielle dans com+