Emprunt d'identité
Dernière modification : mercredi 14 avril 2010
S’applique à : SharePoint Foundation 2010
L’emprunt d’identité, fonctionnalité qui avait été ajoutée dans Windows SharePoint Services 3.0, vous permet d’effectuer des actions pour le compte d’un autre utilisateur. Il s’avère utile dans des scénarios tels que des opérations à minuteur qui doivent mettre à jour un élément de manière asynchrone pour le compte d’un utilisateur longtemps après que celui-ci a arrêté d’utiliser le site Web (c’est-à-dire, lorsque leur flux de travail a pris fin).
Notes
Pour plus d’informations sur la suspension de l’emprunt d’identité, voir Éviter de suspendre l’emprunt d’identité de l’utilisateur appelant.
Lorsque vous créez un site SharePoint par programme à l’aide de l’espace de noms Microsoft.SharePoint, vous pouvez fournir un jeton utilisateur qui vous permet de créer des objets dans le contexte d’un utilisateur spécifique. Vous pouvez emprunter l’identité d’un utilisateur en fournissant le jeton utilisateur correspondant à celui-ci, obtenu à partir de l’objet Microsoft.SharePoint.SPUser. Le jeton utilisateur, SPUserToken, est un objet binaire qui contient l’identification et l’appartenance au groupe de domaine d’un utilisateur.
Vous pouvez ainsi utiliser le constructeur Microsoft.SharePoint.SPSite pour instancier un objet de collection de sites qui s’exécute comme si cet utilisateur apportait les modifications.
Il est généralement inutile d’assurer une sécurité complète du stockage des informations d’identification de l’utilisateur. Les informations d’identification peuvent être affichées à l’aide de code s’exécutant avec des privilèges de compte système ou à l’aide de code s’exécutant avec les informations utilisateur appropriées.
Notez que les jetons utilisateur expirent approximativement au bout de 24 heures. Si vous envisagez d’effectuer une opération longue, à retardement, il peut être judicieux d’enregistrer l’ID de l’utilisateur dans une base de données pour le récupérer ultérieurement. Toutefois, la charge de travail consistant à récupérer des informations dans une base de données peut ralentir les performances. Cela peut être évité si vous prévoyez que l’opération soit « légèrement asynchrone », à savoir qu’elle s’exécute cinq minutes plus tard par exemple.
Étant donné que la confiance doit être réciproque, notez également que l'emprunt d'identité n'est pas disponible si le système Web frontal qui interagit avec la base de données SharePoint se trouve sur un serveur situé entre deux autres réseaux. Dans ce scénario, le serveur frontal Web ne dispose que d'une confiance à sens unique. En outre, les ID de sécurité de groupe (SID) ne sont pas filtrés, ce qui peut entraîner des violations de stratégie de filtrage des SID entre les domaines.
Bien que l’emprunt d’identité constitue une technique puissante de gestion de la sécurité, il doit être utilisé avec précaution en veillant à ce que des activités indésirables ne soient pas effectuées par des utilisateurs qui ne devraient pas être habilités à emprunter des identités.
Notes
Pour continuer à travailler avec des objets sur un site après avoir effectué une action d'emprunt d'identité sur le code, vous devez réinstancier l'objet SPSite.
Gestion des jetons utilisateur
SharePoint extrait les informations de jeton utilisateur dans la base de données SharePoint. Si l’utilisateur n’a jamais visité le site ou si le jeton de l’utilisateur a été généré plus de 24 heures auparavant, SharePoint génère un nouveau jeton utilisateur en essayant d’actualiser la liste des groupes auxquels appartient l’utilisateur.
Si le compte de l’utilisateur est un compte NT, SharePoint utilise l’interface AuthZ pour rechercher la propriété TokenGroups dans le service d’annuaire Active Directory. Cette opération peut échouer si SharePoint s’exécute en mode d’extranet et qu’il n’a pas l’autorisation de rechercher cette propriété dans Active Directory.
Si le compte d’utilisateur est un utilisateur d’appartenance, SharePoint interroge RoleManager d’ASP.NET pour connaître tous les rôles auxquels appartient l’utilisateur. Cette opération peut échouer en l’absence de fichier .config approprié pour le fichier exécutable actuel.
Si SharePoint ne réussit pas à obtenir les appartenances de groupe de l’utilisateur dans Active Directory ou <roleManager>, le jeton qui vient d’être généré contient uniquement l’ID de sécurité unique (SID) de l’utilisateur. Aucune exception n’est levée, mais une entrée sera écrite dans le journal du serveur ULS. Le nouveau jeton est également écrit dans la base de données SharePoint de sorte qu’il ne puisse pas être régénéré avant 24 heures.
Lorsque SharePoint a obtenu un nouveau jeton, en le récupérant dans la base de données SharePoint ou en générant un nouveau jeton, SharePoint définit le cachet d’horodatage à l’heure courante, puis le renvoie à l’utilisateur appelant. Cela garantit que le jeton est neuf pour 24 heures.
Une fois que l’objet SPUserToken est renvoyé à l’appelant, il revient à ce dernier de ne pas utiliser le jeton au-delà de sa date d’expiration. Vous pouvez écrire un utilitaire d’aide qui enregistre l’heure à laquelle vous avez obtenu le jeton, puis calcule la différence entre l’heure courante et SPWebService.TokenTimeout, afin de veiller à ne pas dépasser la date et l’heure d’expiration.
Si un jeton ayant expiré est utilisé pour créer un site Web SharePoint, une exception est levée. La valeur d’expiration par défaut des jetons est de 24 heures. Elle est accessible via SPWebService.TokenTimeout.
Vous pouvez également utiliser Stsadm pour obtenir ou définir la valeur de délai d’expiration des jetons. La commande suivante renvoie une valeur depuis le jeton utilisateur :
stsadm -o getproperty -propertyname token-timeout
Le résultat est le suivant :
<Property Exist="Yes" Value="1440" /> // 1440 minutes is 24 hours
La commande suivante définit une valeur de jeton utilisateur :
stsadm -o setproperty -propertyname token-timeout -propertyvalue 720