Weitergabe der Identität und Datenbank-Identitäten (Referenz)

Regeln und Antworten, wenn der Dienst Anweisungen unter der Anmeldung einer Person (Impersonate) oder einer zugeordneten Sammelanmeldung ausführt. Das Modell erklärt Anmeldung und Weitergabe der Identität.

"Databases": [
  { "Name": "fachdaten", "Provider": "sqlserver", "ConnectionString": "…",
    "Persons": "Impersonate",       // Service | Impersonate; Vorgabe Service
    "DenyImpersonate": [
      { "Logins": [ "sa", "FIRMA\\Datenbankbetrieb" ] },                 // nie
      { "Roles": [ "sysadmin" ], "ExceptFrom": [ "192.168.0.0/16" ] }    // Sysadmins nur aus dem eigenen Netz
    ] }
],
"Security": {
  "AuthMode": "ApiKey, Windows",
  "TrustedProxies": [ "10.0.0.5" ]  // nur von hier wird X-Forwarded-For geglaubt
}

Die Anmeldung des Alias braucht dazu in SQL Server:

GRANT IMPERSONATE ANY LOGIN TO [<Anmeldung des Alias>];
-- zusätzlich möglich, siehe unten: DENY IMPERSONATE ON LOGIN::[sa] TO [<Anmeldung des Alias>];

Die Antworten bei einer Abweisung nennen keine Regel; welcher Eintrag griff, für wen und von welcher Herkunft, steht als Warnung im Protokoll unter der Korrelationskennung.

In vielen Installationen haben Personen in der Datenbank keine eigenen Berechtigungen. Sie arbeiten über eine gemeinsame Anmeldung je Abteilung, etwa vertrieb oder marketing, deren Kennwort alle kennen. Wer zu welcher Anmeldung gehört, entscheidet der Kunde. Der Dienst bildet es im Verwaltungsspeicher ab: Jede Person meldet sich als sie selbst an, und der Dienst wechselt für sie auf die gemeinsame Anmeldung. Das Kennwort der gemeinsamen Anmeldung braucht dabei niemand.

Zwei Mengen der Verwaltungsschnittstelle:

Identität und Zuordnung haben je einen Schalter Enabled. Eine Person hat zusätzlich eine Vorgabe (DefaultRole in Persons).

Welche Identität gilt – je Anfrage, sobald der Alias feststeht:

Eine Zuordnung trifft über die Person, zu der die Anmeldung gehört (über den Schlüssel oder ihr eigenes Windows-Konto), über den Schlüssel selbst oder über das Windows-Konto und jede seiner Gruppen. Namen in X-Wkl-Role und X-Wkl-Roles sind prozentkodiertes UTF-8 (Au%C3%9Fendienst); die Liste ist durch Kommas getrennt.

Prüfung beim Speichern. Eine eingeschaltete Identität der Art Login speichert der Dienst erst nach einem Probewechsel: Er öffnet eine Verbindung der Datenquelle, wechselt auf die Anmeldung und nimmt den Wechsel sofort zurück. Abgewiesen wird mit 422 und einer Meldung für die Verwaltung, wenn die Anmeldung fehlt (oder eine Windows-Gruppe ist), wenn ein Eintrag von DenyImpersonate sie nennt – beim Speichern zählt jeder Eintrag, auch einer mit Netzbedingung –, wenn sie einer dort genannten Serverrolle angehört, wenn sie keinen Zugang zur Datenbank der Datenquelle hat oder wenn SQL Server den Wechsel verweigert (etwa weil IMPERSONATE fehlt). Die Anmeldung der Datenquelle braucht dafür in SQL Server:

GRANT IMPERSONATE ON LOGIN::[vertrieb] TO [<Anmeldung der Datenquelle>];   -- je Sammelanmeldung

Die Sammelanmeldungen selbst und ihre Berechtigungen legt der Kunde in SQL Server an; der Dienst verwaltet sie nicht. Eine Sammelanmeldung, die sich Personen per Basic mit einem geteilten Kennwort teilen, ist nicht empfohlen: Der Dienst kann die Personen dann nicht unterscheiden.

Clients. Der ODBC-Treiber für OData (Wkl.Data.OData.Odbc) wählt mit dem Schlüsselwort ROLE= oder – wo die Anwendung einen Dialog erlaubt – mit einer Auswahlliste, die die Liste aus X-Wkl-Roles zeigt. Access und DAO teilen eine Verbindung zwischen allen Verknüpfungen eines Prozesses mit gleichem DATABASE-Wert, auch wenn sich ihre ROLE= unterscheiden: Dort gilt die Identität der ersten Verbindung für alle diese Verknüpfungen. Eine zweite Identität in derselben Access-Sitzung braucht einen eigenen DATABASE-Wert in ihrer Verbindungszeichenfolge; die Regel beschreibt die Dokumentation des Treibers (Verbindungsschlüsselwörter).

• So geben Sie Personen an SQL Server weiter
• „So richten Sie Datenbank-Identitäten ein“ (Dokumentation der Verwaltungsanwendung, Administrator-Handbuch)