Délégation

requête
au Server A qui a besoin de données
provenant du Server B. Sous SQL
Server 7.0 et 6.5, Joe peut utiliser un
compte login SQL Server (mais pas son
compte Win2K/NT) pour se connecter
au Server B à  partir du Server A. Dans
SQL Server 6.5, les requêtes adressées
à  des machines à  distance vous obligent à  utiliser les procédures stockées
à  distance. Dans SQL Server 7.0, le
moyen le plus simple de traiter cette situation
consiste à  établir une
connexion de serveur à  distance.
Cependant, SQL Server 2000 peut traiter
les données provenant d’une requête
qui est exécutée sur un serveur à 
distance, comme si elles venaient
d’une table locale. Cette intégration
des sources de données à  distance
dans la syntaxe T-SQL suppose que
SQL Server se connecte à  ces sources
de données sans aucune entrée supplémentaire
de la part de l’utilisateur.

La délégation offre la souplesse
d’avoir de multiples serveurs de bases
de données avec de multiples ensembles
de permissions pour le même
utilisateur. Ainsi, l’utilisateur Joe pourrait
avoir les permissions SELECT, INSERT,
UPDATE et DELETE pour une
base de données sur Server A mais seulement
la permission SELECT pour
une base de données sur Server B.
Avant SQL Server 2000, un moyen courant
de laisser une requête s’exécutant
sur Server A extraire des données du
Server B consistait à  utiliser une procédure
stockée ne permettant que la lecture
des données. Cette technique
demande de changer la programmation
de la procédure stockée pour
chaque serveur, chaque fois que les
droits de l’utilisateur sur les données
sous-jacentes changent. En revanche,
la délégation permet aux administrateurs
de gérer des permissions sur
tous les serveurs en utilisant les commandes
d’autorisation intégrées de
SQL Server. Si vous avez des requêtes
qui accèdent à  des serveurs multiples,
vous constaterez que la délégation allège
beaucoup plus les tâches d’administration
que d’autres solutions
comme les procédures stockées à  distance.

La délégation découle naturellement
de l’authentification Kerberos. Si
Joe transmet au Server A son TGT et la
clé de session qu’il partage avec le DC
(domain controller), Server A peut demander
un ticket pour Server B pour le compte de Joe. Le TGT est déjà  crypté avec la
valeur hachée du DC, donc le DC sait
que le TGT est valide. La clé de session
de Joe qui est partagée avec le DC est
cryptée en utilisant la clé de session
qu’il partage avec Server A. Par conséquent,
si Joe fait suffisamment
confiance à  Server A pour lui donner la
clé de session, le DC sait que Server A
effectue la requête comme si Joe était
connecté à  Server A.

La délégation Kerberos fonctionne
pour un nombre illimité de SQL
Servers, mais aussi pour d’autres services.
Les services XML et .NET Web
dans l’environnement SQL Server offrent
de nouvelles possibilités pour
consulter des données provenant de
sources externes. En outre, Microsoft a
annoncé un add-on SQL Server 2000,
SQLXML (que l’on peut obtenir à 
http://msdn.microsoft.com/downloads
/default.asp?URL=/downloads/sample.
asp?url=/msdn-files/027/001/824/ms
dncompositedoc.xml), qui permet aux
applications .NET d’utiliser des procédures
stockées comme les services
.NET Web. Cette option présente de
nombreuses possibilités pour utiliser
SQL Server comme un intermédiaire
pour d’autres SQL Server ou même
d’autres sources de données non relationnelles.
La délégation, ou le fait que
les références de sécurité de l’utilisateur
passent d’un serveur à  un autre,
est le meilleur moyen d’utiliser ces
nouvelles possibilités.