Impersonation and CLR Integration Security
When managed code accesses external resources, SQL Server does not automatically impersonate the current execution context under which the routine is executing. Code in EXTERNAL_ACCESS and UNSAFE assemblies can explicitly impersonate the current execution context.
Note
For information on behavior changes in impersonation, see Breaking Changes to Database Engine Features in SQL Server 2012.
The in-process data access provider provides an application programming interface, SqlContext.WindowsIdentity, that can be used to retrieve the token associated with the current security context. Managed code in EXTERNAL_ACCESS and UNSAFE assemblies can use this method to retrieve the context and use the .NET Framework WindowsIdentity.Impersonate method to impersonate that context. The following restrictions apply when user code explicitly impersonates:
In-process data access is not allowed when managed code is in an impersonated state. Code can undo impersonation and then call in-process data access. Note that this requires storing the return value (a WindowsImpersonationContext object) of the original Impersonate method, and calling the Undo method on this WindowsImpersonationContext.
This restriction means that when in-process data access occurs, it is always in the context of the current security context in effect for the session. It cannot be modified by explicit impersonation within managed code.
For managed code executing asynchronously (for example, through UNSAFE assemblies creating threads and running code asynchronously), in-process data access is never allowed. This is true whether or not there is impersonation.
When code is running in an impersonated context that is different from SQL Server, it cannot perform in-process data access calls; it should undo the impersonation context before making in-process data access calls. When in-process data access is made from managed code, the original execution context of the Transact-SQL entry point into the managed code is always used for authorization.
Both EXTERNAL_ACCESS assemblies and UNSAFE assemblies access operating system resources with the SQL Server service account, unless they voluntarily impersonate the current security context as previously described. Because of this, the authors of EXTERNAL_ACCESS assemblies require a higher level of trust than those of SAFE assemblies, which is specified by the EXTERNAL ACCESS login-level permission. Only logins who are trusted to run code under the SQL Server service account should be granted the EXTERNAL ACCESS permission.