Emprunt d’identité et délégation du client
Dans certaines circonstances, une application serveur doit présenter l’identité d’un client aux ressources auxquelles il accède pour le compte du client, généralement pour que des vérifications d’accès ou une authentification soient effectuées sur l’identité du client. Dans une certaine mesure, le serveur peut agir sous l’identité du client, action appelée emprunt d’identité du client.
L’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, ce qui lui permet d’accéder aux ressources auxquelles le client peut accéder.
L’utilisation de l’emprunt d’identité garantit que le serveur peut faire exactement ce que le client peut faire. L’accès aux ressources peut être restreint ou étendu, en fonction de ce que le client a l’autorisation de faire.
Vous pouvez choisir de demander à un serveur d’emprunter l’identité d’un client lors de la connexion à une base de données afin que la base de données puisse authentifier et autoriser le client pour elle-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, des administrateurs système). Le client doit indiquer sa volonté de laisser le serveur utiliser son identité, et le serveur doit assumer explicitement l’identité du client par programmation. Pour plus d’informations, consultez les rubriques Exigences côté client pour l’emprunt d’identité et Exigences côté serveur 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é, la délégation, qui est l’emprunt d’identité de 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’autorisation d’octroi du client pour effectuer l’emprunt d’identité au niveau des délégués), 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é » dans le service Active Directory.
Ces fonctionnalités de configuration donnent à l’administrateur de domaine un haut degré de contrôle sur la délégation, ce qui est souhaitable, compte tenu de la confiance (et donc du 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 via le niveau d’emprunt d’identité, la capacité de camouflage du serveur détermine en grande partie le comportement de l’emprunt d’identité. Le mastruage affecte l’identité qui est réellement présentée par le serveur lorsqu’il effectue des appels pour le compte du client ( son propre ou celui du client). Pour plus d’informations, consultez Cloaking.
Impact sur les 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 lors d’un appel que d’effectuer l’appel directement. Voici quelques-uns des problèmes à prendre en compte :
- Surcharge de calcul de la transmission de l’identité dans des modèles complexes, en particulier si le maquage dynamique est activé.
- La complexité générale de l’application de la vérification de sécurité redondante à de nombreux endroits, au lieu de simplement centraliser dans le niveau intermédiaire.
- Les ressources telles que les connexions de base de données, lorsqu’elles sont ouvertes en empruntant l’identité d’un client, ne peuvent pas être réutilisées sur plusieurs clients, ce qui est un obstacle très important à la bonne 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
Les 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 en fait effectué à l’enregistreur, qui le package dans le cadre d’un message au serveur. L’écouteur lit ensuite le message à partir 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é par programme à l’aide de l’interface ISecurityCallContext fonctionnera. Pour plus d’informations, consultez Sécurité des composants mis en file d’attente.
Rubriques connexes