Gestion de session WIF

Quand un client tente d’abord d’accéder à une ressource protégée qui est hébergée par une partie de confiance, il doit d’abord s’authentifier auprès d’un service d’émission de jeton de sécurité (STS) qui est approuvé par la partie de confiance. Le service STS fournit ensuite un jeton de sécurité au client. Le client présente ce jeton à la partie de confiance, qui accorde l’accès client à la ressource protégée. Toutefois, vous souhaitez éviter au client d’avoir à s’authentifier de nouveau auprès du service STS pour chaque demande, en particulier car il peut même ne pas se trouver sur le même ordinateur ou dans le même domaine que la partie de confiance. Au lieu de cela, avec WIF (Windows Identity Foundation), le client et la partie de confiance établissent une session dans laquelle le client utilise un jeton de sécurité de session pour s’authentifier auprès de la partie de confiance pour toutes les demandes après la première. La partie de confiance peut utiliser ce jeton de sécurité de session, qui est stocké à l’intérieur d’un cookie, afin de reconstruire le System.Security.Claims.ClaimsPrincipal du client.

Le service STS définit l’authentification que le client doit fournir. Toutefois, le client peut avoir plusieurs informations d’identification avec lesquelles il peut s’authentifier auprès du service STS. Par exemple, il peut avoir un jeton Windows Live, un nom d’utilisateur et un mot de passe, un certificat, et un smartkey. Dans ce cas, le service STS accorde au client plusieurs identités, chacune correspondant à l’une des informations d’identification que le client présente. La partie de confiance peut utiliser une ou plusieurs de ces identités quand elle décide du niveau d’accès à accorder au client.

System.IdentityModel.Tokens.SessionSecurityToken est utilisé pour reconstruire le System.Security.Claims.ClaimsPrincipal du client, qui contient toutes les identités du client dans Identities. Chaque System.Security.Claims.ClaimsIdentity dans la collection contient les jetons de démarrage qui sont associés à cette identité.

Si un nouveau jeton de session est émis avec l’ID de session du jeton de session d’origine, System.IdentityModel.Tokens.SessionSecurityTokenHandler ne met pas à jour le jeton de session dans le cache de jeton. Vous devez toujours instancier un jeton de session avec un ID de session unique.

Notes

Session.SecurityTokenHandler.ReadToken lève une exception XmlException s’il reçoit une entrée non valide, par exemple si le cookie qui contient le jeton de session est endommagé. Nous vous recommandons d’intercepter cette exception et de fournir un comportement spécifique à l’application.

Si une page web protégée contient un grand nombre de ressources (telles que des petits graphiques) qui figurent également dans le domaine protégé, le client doit s’authentifier de nouveau auprès de la partie de confiance pour télécharger chacune de ces ressources. L’utilisation d’un jeton d’authentification de session évite d’avoir à s’authentifier auprès du service STS pour chaque demande, mais signifie néanmoins que de nombreux cookies sont envoyés. Vous pouvez configurer la page web afin que les données et les ressources importantes soient stockées dans le domaine protégé, alors que les éléments secondaires sont stockés dans un domaine non protégé et liés à la page web principale. Définissez également le chemin du cookie pour référencer uniquement le domaine protégé.

Pour fonctionner en mode de référence, Microsoft recommande de fournir un gestionnaire pour l’événement SessionSecurityTokenCreated dans le fichier global.asax.cs et de définir la propriété IsReferenceMode sur le jeton passé dans la propriété SessionToken. Ces mises à jour garantissent que le jeton de session fonctionne en mode de référence pour chaque demande et est privilégié par rapport à une simple définition de la propriété IsReferenceMode sur le module d’authentification de session.

Extensibilité

Vous pouvez étendre le mécanisme de gestion de session, par exemple dans le but d’améliorer les performances. Vous pouvez notamment créer un gestionnaire de cookie personnalisé qui transforme ou optimise le jeton de sécurité de session entre son état en mémoire et ce qui entre dans le cookie. Pour ce faire, vous pouvez configurer la propriété SessionAuthenticationModule.CookieHandler de System.IdentityModel.Services.SessionAuthenticationModule pour utiliser un gestionnaire de cookie personnalisé qui dérive de System.IdentityModel.Services.CookieHandler. System.IdentityModel.Services.ChunkedCookieHandler est le gestionnaire de cookie par défaut, car les cookies dépassent la taille autorisée pour le protocole HTTP (Hypertext Transfer Protocol) ; si vous utilisez plutôt un gestionnaire de cookie personnalisé, vous devez implémenter la segmentation.

Pour plus d’informations, consultez exemple ClaimsAwareWebFarm . Cet exemple montre un cache de sessions prêt pour une batterie de serveurs (par opposition à un tokenreplycache) afin que vous puissiez utiliser des sessions par référence au lieu d’échanger des cookies de grande taille. Cet exemple illustre également un moyen plus simple de sécuriser des cookies dans une batterie de serveurs. Le cache de sessions est basé sur WCF. En ce qui concerne la sécurisation de session, l’exemple illustre une nouvelle fonctionnalité dans WIF 4,5 d’une transformation de cookie basée sur MachineKey, qui peut être activée en collant simplement l’extrait de code approprié dans le fichier Web. config. L’exemple lui-même n’est pas « en batterie », mais il montre ce dont vous avez besoin pour préparer votre application à la prise en main de la batterie de serveurs.