Utilizzo di EXECUTE AS nei moduli
EXECUTE AS consente di definire il contesto di esecuzione di moduli definiti dall'utente quali funzioni, procedure, code e trigger. Ad esempio, è possibile cambiare il contesto di esecuzione dal chiamante al proprietario del modulo o a un utente specificato. Nelle versioni precedenti di SQL Server, questi moduli vengono sempre eseguiti nel contesto del chiamante del modulo.
L'impostazione del contesto di esecuzione del modulo consente di controllare l'account utente utilizzato dal Motore di database per la convalida delle autorizzazioni relative a qualsiasi oggetto a cui viene fatto riferimento nel modulo. Ciò consente una maggiore flessibilità e un maggiore controllo nella gestione delle autorizzazioni per la catena di oggetti esistente tra i moduli definiti dall'utente e gli oggetti a cui viene fatto riferimento nei moduli. Gli utenti del modulo devono disporre unicamente delle autorizzazioni per l'esecuzione del modulo e non di autorizzazioni esplicite per gli oggetti ai quali viene fatto riferimento. Solo l'utente che esegue il modulo deve disporre delle autorizzazioni per gli oggetti ai quali accede il modulo.
EXECUTE AS CALLER
EXECUTE AS CALLER specifica che le istruzioni del modulo vengono eseguite nel contesto del chiamante del modulo.
Utilizzare EXECUTE AS CALLER negli scenari seguenti:
Se si desidera che le istruzioni nel modulo vengano eseguite dall'utente chiamante.
Se si desidera che la verifica delle autorizzazioni per le istruzioni del modulo sia basata sull'utente chiamante e che per ignorare la verifica delle autorizzazioni sugli oggetti sottostanti sia possibile basarsi unicamente sul concatenamento della proprietà. Tenere presente che il concatenamento della proprietà è valido solo per le istruzioni DML. Per ulteriori informazioni sul concatenamento della proprietà, vedere Catene di proprietà.
Se l'applicazione non richiede che gli oggetti sottostanti ai quali viene fatto riferimento siano nascosti all'utente oppure si fa riferimento unicamente a oggetti dello stesso proprietario e pertanto è possibile nascondere lo schema utilizzando il concatenamento della proprietà.
Se si desidera mantenere il tipo di funzionamento di SQL Server 2000.
Scenario per EXECUTE AS CALLER
Mary crea una stored procedure che fa riferimento a una tabella di cui non è proprietaria ma per la quale dispone di autorizzazioni SELECT. Specifica quindi EXECUTE AS CALLER nell'istruzione CREATE PROCEDURE, come illustrato nell'esempio seguente:
CREATE PROCEDURE AccessTable
WITH EXECUTE AS CALLER
AS SELECT * FROM dbo.SomeTable;
Mary concede quindi le autorizzazioni EXECUTE per la stored procedure a Scott. Quando Scott esegue la stored procedure, Motore di database verifica che Scott (il chiamante) disponga dell'autorizzazione per l'esecuzione della stored procedure. Scott dispone dell'autorizzazione EXECUTE, ma poiché Mary non è il proprietario della tabella a cui viene fatto riferimento, Motore di database controlla se Scott dispone di autorizzazioni per la tabella. Se Scott non dispone di autorizzazioni, l'istruzione della stored procedure ha esito negativo.
EXECUTE AS user_name
EXECUTE AS user_name specifica che le istruzioni nel modulo vengono eseguite nel contesto dell'utente specificato in user_name.
Utilizzare EXECUTE AS user_name negli scenari seguenti:
Se si desidera che le istruzioni nel modulo vengano eseguire nel contesto di un utente specificato.
Se non è possibile utilizzare il concatenamento della proprietà (ad esempio, se il modulo accede a oggetti con proprietari diversi) per nascondere lo schema sottostante e si desidera evitare di concedere autorizzazioni per gli oggetti ai quali viene fatto riferimento.
Se si desidera creare un set di autorizzazioni personalizzato, ad esempio per concedere autorizzazioni relative a operazioni DDL per le quali in genere non è possibile concedere autorizzazioni specifiche. Per ulteriori informazioni, vedere Utilizzo di EXECUTE AS per la creazione di set di autorizzazioni personalizzati.
[!NOTA]
Non è possibile eliminare un utente che è stato definito come contesto di esecuzione di un modulo fino a quando non si cambia tale contesto.
Scenario per EXECUTE AS user_name
Mary crea una stored procedure che fa riferimento a una tabella di cui non è proprietaria ma per la quale dispone di autorizzazioni SELECT. Specifica quindi EXECUTE AS 'Mary' nell'istruzione CREATE PROCEDURE, come illustrato nell'esempio seguente:
CREATE PROCEDURE AccessMyTable
WITH EXECUTE AS 'Mary'
AS SELECT * FROM dbo.MyTable;
Mary concede le autorizzazioni EXECUTE per la stored procedure a Scott. Quando Scott esegue la stored procedure, Motore di database controlla che Scott disponga dell'autorizzazione per l'esecuzione della stored procedure. Vengono tuttavia controllate le autorizzazioni di Mary per la tabella a cui viene fatto riferimento. In questo scenario, anche se Scott non dispone direttamente delle autorizzazioni SELECT per la tabella, può tuttavia accedere ai dati tramite la procedura perché la procedura viene eseguita nel contesto di Mary, che dispone delle autorizzazioni per l'accesso ai dati della tabella.
EXECUTE AS SELF
EXECUTE AS SELF equivale a EXECUTE AS user_name, dove l'utente specificato è la persona che crea o modifica il modulo.
Utilizzare EXECUTE AS SELF negli scenari seguenti:
Se si desidera utilizzare una forma abbreviata per specificare che le istruzioni del modulo che si sta creando o modificando devono essere eseguite nel contesto dell'utente corrente.
Si utilizza un'applicazione che crea moduli per gli utenti che eseguono chiamate e si desidera che per la creazione di tali moduli venga utilizzato il contesto di esecuzione di tali utenti. In questo scenario, il nome dell'utente chiamante non è noto durante la fase di progettazione.
EXECUTE AS OWNER
EXECUTE AS OWNER specifica che le istruzioni nel modulo vengono eseguite nel contesto del proprietario corrente del modulo. Se per il modulo non è stato specificato un proprietario, verrà utilizzato il proprietario dello schema del modulo.
Utilizzare EXECUTE AS OWNER negli scenari seguenti:
- Se si desidera avere la possibilità di cambiare il proprietario del modulo senza che sia necessario modificare il modulo. OWNER esegue automaticamente il mapping al proprietario corrente del modulo in fase di run-time.
OWNER rappresenta il proprietario esplicito del modulo oppure, se non è disponibile un proprietario esplicito, rappresenta il proprietario dello schema del modulo durante la fase di esecuzione del modulo stesso. OWNER deve essere un account singleton e non un gruppo o un ruolo. Non è possibile modificare la proprietà del modulo in un gruppo o in un ruolo se il modulo specifica EXECUTE AS OWNER e ha un proprietario esplicito. Non è possibile modificare la proprietà di uno schema in un ruolo o in un gruppo se nello schema è presente un modulo che specifica EXECUTE AS OWNER e per il quale non è disponibile un proprietario esplicito.
Scenario per EXECUTE AS OWNER
Mary crea una stored procedure che fa riferimento a una tabella di cui è proprietaria. Specifica quindi EXECUTE AS OWNER nell'istruzione CREATE PROCEDURE, come illustrato nell'esempio seguente:
CREATE PROCEDURE Mary.AccessMyTable
WITH EXECUTE AS OWNER
AS SELECT * FROM Mary.MyTable;
Mary concede le autorizzazioni EXECUTE per la stored procedure a Scott. Quando Scott esegue la stored procedure, Motore di database controlla che Scott disponga dell'autorizzazione per l'esecuzione della stored procedure. Vengono tuttavia controllate le autorizzazioni di Mary per la tabella a cui viene fatto riferimento, perché Mary è il proprietario corrente della procedura. Mary decide di lasciare la società e cambia la proprietà della procedura e della tabella passandola a Tom. Quando Scott esegue la stored procedure dopo il cambiamento della proprietà, è ancora in grado di accedere ai dati tramite la procedura perché OWNER viene automaticamente mappato a Tom.