Description du basculement de contexte

Dans l'exemple suivant, Peter Connelly (un administrateur réseau de Adventure Works Cycles) souhaite créer un compte de connexion SQL Server pour un nouvel employé nommé Jinghao Liuhas. La connexion SQL Server de Peter ne dispose pas de l'autorisation requise au niveau du serveur pour créer des connexions SQL Server, mais elle possède l'autorisation IMPERSONATE sur adventure-works\dan1, une connexion SQL Server qui dispose, elle, de l'autorisation requise au niveau du serveur. Lorsque Peter se connecte à SQL Server, le contexte d'exécution de la session est dérivé de sa connexion SQL Server. Pour créer une connexion SQL Server, Peter adopte temporairement le contexte d'exécution de adventure-works\dan1. Il crée ensuite la connexion. Pour terminer, il abandonne les autorisations qu'il a empruntées.

-- Switch execution context to the adventure-works\dan1 login account.
EXECUTE AS LOGIN = 'adventure-works\dan1';
-- Create the new login account.
CREATE LOGIN Jinghao1 WITH PASSWORD = '3KHJ6dhx(0xVYsdf';
-- Revert to the previous execution context.
REVERT;

Dans l'exemple suivant, François Ajenstat, un administrateur de base de données pour Adventure Works Cycles, souhaite exécuter l'instruction DBCC CHECKDB sur la base de données AdventureWorksDW, mais ne dispose pas des autorisations nécessaires au niveau de la base de données. Cependant, il possède les autorisations IMPERSONATE sur l'utilisateur dan1, compte disposant de l'autorisation requise.

Lorsque François se connecte à la base de données AdventureWorksDW, le contexte d'exécution établit une correspondance à son jeton de sécurité d'utilisateur. Les autorisations d'exécution d'instructions sont vérifiées par rapport aux entités de sécurité principale et secondaire contenues dans son jeton d'utilisateur. Comme il ne dispose pas des autorisations requises pour exécuter l'instruction DBCC CHECKDB, il exécute les instructions ci-dessous.

-- EXECUTE AS USER = 'dan1';
-- Create a table in dan1's default schema
CREATE TABLE t_NewTable( data nvarchar(100) );
go
-- Revert to the previous execution context.
REVERT
go;

Dans l'exemple suivant, Mary est la propriétaire de la table MyTable. Elle veut que l'utilisateur Scott puisse tronquer cette table, mais Scott ne dispose d'aucune autorisation directe sur la table. Elle crée donc la procédure stockée dbo.usp_TruncateMyTable et accorde à Scott les autorisations EXECUTE sur la procédure. Lorsque Scott exécute la procédure stockée, le moteur de base de données vérifie les autorisations de tronquer la table comme si Mary elle-même exécutait cette procédure. Comme elle est la propriétaire de la table, l'instruction réussit, même si Scott ne dispose d'aucune autorisation directe sur la table proprement dite.

CREATE PROCEDURE dbo.usp_TruncateMyTable
WITH EXECUTE AS SELF
AS TRUNCATE TABLE MyDB..MyTable;