Comment transmettre des données hors-bande (ID utilisateur actuel) à SQL Server 2008

Question

Nous avons une application Web qui utilise l'authentification par formulaire pour authentifier un utilisateur en fonction d'une table utilisateur dans la base de données. (Par exemple, aucun répertoire actif ou compte d'utilisateur du serveur SQL n'est impliqué ici). L'application Web accède au serveur SQL à l'aide d'un compte de service. Cependant, à des fins d'audit, d'autorisation et à d'autres fins, nos procédures stockées doivent savoir pour quel utilisateur une opération donnée est en cours d'exécution.

Dans une vie antérieure, j'ai travaillé avec une situation similaire en utilisant une base de données Oracle. Dans ce scénario, chaque fois que nous avons ouvert une connexion, nous avons d'abord appelé une procédure de génération Oracle pour définir une variable de contexte de portée de connexion. Cette variable contenait l'ID utilisateur de l'utilisateur qui utiliserait la connexion. Ensuite, toutes les procédures stockées qui ont besoin de connaître l'utilisateur actuel vérifieraient la variable de contexte. D'un point de vue conceptuel, cela ressemblait beaucoup à pousser les informations d'utilisateur sur le CallContext avant de passer un appel à distance.

Ma question est, existe-t-il un mécanisme similaire dans Microsoft SQL Server? Obvioulsy, si je dois, je peux passer l'UserId comme argument à chaque procédure stockée, mais c'est exactement ce que j'essaie d'éviter.

Answer 1

Utilisez SET CONTEXT_INFO et CONTEXT_INFO(). Voir Using Session Context Information.

Answer 2

Ce que vous pouvez faire est de créer des utilisateurs dans la base de données (sans les connexions au serveur) et leur donner les autorisations appropriées. Après cela, ce que vous faites est une instruction "execute as", puis le contexte utilisateur pour vos appels de base de données sera comme si l'utilisateur l'appelait. Exemple:

EXECUTE AS USER = 'user2'; 
EXECUTE usp_insert_stuff @params; 
REVERT; 

Inconvénient: vous devez configurer des utilisateurs sécurité et gérer SQL Upside: Les utilisateurs ne peuvent pas se connecter directement à SQL Server et vous obtenez l'audit.

Référence ici: http://msdn.microsoft.com/en-us/library/ms188354.aspx

Voir les exemples vers le bas de la page.