Emprunt d'identité et informations d'identification pour les connexions
Dans l'intégration du CLR (Common Language Runtime) SQL Server, l'authentification Windows est complexe à utiliser, mais elle offre une protection supérieure à l'authentification SQL Server. Lorsque vous utilisez l'authentification Windows, gardez à l'esprit les points suivants.
Par défaut, un processus SQL Server qui se connecte à Windows acquiert le contexte de sécurité du compte de service Windows SQL Server. Mais il est possible de mapper une fonction CLR à une identité de proxy afin que ses connexions sortantes aient un contexte de sécurité différent de celui du compte de service Windows.
Dans certains cas, vous pouvez emprunter l'identité de l'appelant à l'aide de la propriété SqlContext.WindowsIdentity plutôt que de fonctionner en tant que compte de service. L'instance de WindowsIdentity, qui représente l'identité du client qui a appelé le code appelant, est uniquement disponible lorsque le client utilise l'authentification Windows. Après avoir obtenu l'instance de WindowsIdentity, vous pouvez appeler Impersonate pour modifier le jeton de sécurité du thread, puis ouvrir des connexions ADO.NET pour le compte du client.
Après avoir appelé SQLContext.WindowsIdentity.Impersonate, vous ne pouvez pas accéder aux données locales ni aux données système. Pour accéder à nouveau aux données, vous devez appeler WindowsImpersonationContext.Undo.
L'exemple suivant montre comment emprunter l'identité de l'appelant à l'aide de la propriété SqlContext.WindowsIdentity.
Visual C#
WindowsIdentity clientId = null;
WindowsImpersonationContext impersonatedUser = null;
clientId = SqlContext.WindowsIdentity;
// This outer try block is used to protect from
// exception filter attacks which would prevent
// the inner finally block from executing and
// resetting the impersonation.
try
{
try
{
impersonatedUser = clientId.Impersonate();
if (impersonatedUser != null)
return GetFileDetails(directoryPath);
else return null;
}
finally
{
if (impersonatedUser != null)
impersonatedUser.Undo();
}
}
catch
{
throw;
}
[!REMARQUE]
Pour plus d'informations sur les différences de comportement au niveau de l'emprunt d'identité, consultez Changements essentiels dans les fonctionnalités du moteur de base de données de SQL Server 2012.
Par ailleurs, si vous avez obtenu l'instance de l'identité Microsoft Windows, vous ne pouvez pas, par défaut, propager cette instance à un autre ordinateur, cette opération étant restreinte par défaut par l'infrastructure de sécurité Windows. Il existe cependant un mécanisme, appelé « délégation », qui permet la propagation d'identités Windows sur plusieurs ordinateurs approuvés. Pour en savoir plus sur la délégation, consultez l'article TechNet suivant : « Kerberos Protocol Transition and Constrained Delegation » (en anglais).