Anmeldung und Weitergabe der Identität

Der Dienst beantwortet zwei getrennte Fragen: wer anfragt (das Anmeldeverfahren) und als wen die Anweisung in SQL Server läuft (die Weitergabe, je Alias eingestellt). Diese Seite erklärt beide und ihre zulässigen Kombinationen; die Regeln im Einzelnen stehen in HTTP: Anmeldung (Referenz) und in Weitergabe der Identität und Datenbank-Identitäten (Referenz).

• Anmeldung mit Dienstschlüssel, Windows-Konto, SQL-Server-Anmeldung oder persönlichem Schlüssel.
• Zweiter Faktor nach einer Anmelderichtlinie je Verfahren, Bereich und Netz.
• Anweisungen unter der Anmeldung des Alias, der eigenen Anmeldung der Person oder einer zugeordneten Sammelanmeldung; die Person bleibt im Sitzungskontext sichtbar.

Bestandteile: Persons mit Service und Impersonate, die Sperrliste DenyImpersonate mit Netzbedingungen und TrustedProxies, die SQL-Anmeldung per HTTP Basic über ihre eigene Verbindung und die Datenbank-Identitäten aus dem Verwaltungsspeicher.

Leitsatz: Der Dienst verhält sich gegenüber der Datenbank wie eine direkte Verbindung der Person. Gemeint sind drei prüfbare Eigenschaften: Läuft eine Anweisung als Person, liefern USER_NAME(), SUSER_SNAME() und CURRENT_USER die Person, in Spaltenvorgabe, Trigger und Sicht; SQL Server prüft ihre Berechtigungen, und eine Verweigerung kommt als 403 wie die Ablehnung einer direkten Verbindung; eine SQL-Anmeldung prüft SQL Server selbst beim Öffnen ihrer Verbindung. Wo das nicht gilt – Dienstschlüssel, Weitergabe Service –, sieht die Datenbank die Anmeldung des Alias. Dafür trennt der Dienst zwei Fragen:

1. Wer ruft an? Das stellt das Anmeldeverfahren fest.
2. Als wen läuft die Anweisung in SQL Server? Das legt die Konfiguration des Alias fest.

Nötig ist das, weil Datenbanken die Anmeldung selbst auswerten: Spaltenvorgaben belegen einen Wert mit USER_NAME() (etwa „angelegt von“), und Trigger, Sichten und Prozeduren lesen USER_NAME(), CURRENT_USER, SYSTEM_USER oder HOST_NAME(). Mit Service sehen sie alle die Anmeldung des Alias: Ein „geändert von“ nennt das Dienstkonto, und eine Sicht, die CURRENT_USER auswertet, tut das für das Dienstkonto statt für die Person.

Wer ruft an – die Anmeldeverfahren:

Eine Identität, die ein vorgeschalteter Proxy in einer Kopfzeile weitergibt, übernimmt der Dienst nicht: Solange er auch ohne diesen Proxy erreichbar ist, könnte jeder die Kopfzeile selbst setzen.

Als wen läuft die Anweisung – die Weitergabe, eingestellt je Alias:

So wirkt die Einstellung Persons des Alias je Verfahren:

Eine Datenbank-Identität, die eine Person wählt, geht beiden Einstellungen vor (siehe Datenbank-Identitäten).

Die Person ist sichtbar. Meldet sich eine Person der Verwaltung mit ihrem persönlichen Schlüssel an oder wählt sie eine Datenbank-Identität, schreibt der Dienst sie vor jedem Wechsel schreibgeschützt in den Sitzungskontext (SESSION_CONTEXT(N'wkl.person'), dazu wkl.key und wkl.role) – auch unter Service. Bei einer Anmeldung mit dem Windows-Konto oder einer SQL-Anmeldung bleibt wkl.person leer, auch wenn das Konto einer Person zugeordnet ist; dort nennt SQL Server die Person über SUSER_SNAME(), sofern die Anweisung als sie läuft. Eine eigene Einstellung dafür gibt es nicht; die Regeln stehen unter Zeilenweise Einschränkung.

• Rechte: Regeln und Reichweite
• So geben Sie Personen an SQL Server weiter
• So richten Sie die Anmeldung mit dem Windows-Konto ein
• So richten Sie die Anmeldung mit einer SQL-Anmeldung ein