2009-06-30 7 views
3

Ich möchte die integrierte Authentifizierung verwenden, um von einem Webpart aus auf eine SQL-Datenbank zuzugreifen. Es sollte die Identität des IIS-Anwendungspools verwenden.SharePoint und <identity impersonate = "false" />

Standardmäßig erhalten Sie die Fehlermeldung erhalten:

System.Data.SqlClient.SqlException: Login failed for user 'SERVER\IUSR_VIRTUALMACHINE'. 

Da in web.config Identitätswechsel auf true gesetzt ist:

<identity impersonate="true" /> 

ich dies auf false gesetzt und die Datenbank-Code arbeiten. Anonym aufgerufene Websites funktionieren ebenfalls. Jede SharePoint-Website, die Authentifizierung verwendet, wird jedoch fehlschlagen, so dass dies nicht wirklich eine Lösung ist.

Um dies zu lösen, müsste ich alle meine Datenbank-Zugriffscode mit erhöhten Privilegien kapseln, ist das wie SharePoint macht es intern? Irgendwie scheint das nicht die performanteste Lösung zu sein. Ist das immer noch der Weg zu gehen, verwenden Sie einfach SQL-Sicherheit für den Zugriff auf Datenbanken von benutzerdefinierten SharePoint-Webparts?

Antwort

4

Die Elemente <identity /> und in der Datei web.config bestimmen gemeinsam das Konto, das für die Verbindung mit SQL Server verwendet wird, wenn die integrierte Authentifizierung verwendet wird.

Wenn <authentication mode="Windows" /> konfiguriert ist, verzögern Sie IIS, um Benutzer zu authentifizieren. Ich schätze, dass Ihre Ihre web.config enthält:

<authentication mode="Windows" /> 
<identity impersonate="true" /> 

und dass IIS für anonyme Benutzer konfiguriert ist. Die Einstellung <identity impersonate="true" /> bewirkt, dass IIS die Identität des anonymen IIS-Zugriffskontos an SQL Server übergibt.

Wie Lars darauf hinweist, wird mit SPSecurity.RunWithElevatedPrivileges erreicht, was Sie wollen. Ich glaube nicht, dass Sie eine spürbare Auswirkung auf die Leistung sehen werden, aber das können Sie testen :-)

+0

Dieser Datenbankzugriff ist auf der gesamten Website ziemlich verbreitet Also würde ich gerne eine informierte Entscheidung treffen. Ist SQL Auth schneller oder langsamer als das Hinzufügen von Identitätswechsel? Ich muss über einen Test nachdenken: - \ – ArjanP

+0

Ich glaube wirklich nicht, dass es einen Unterschied macht (aber das ist immer noch am besten getestet in Ihrer Umgebung). Es wird wahrscheinlich eine vernachlässigbare Leistung mit Identitätswechsel und Kontextwechsel geben, aber ich bezweifle, dass es auffällt.Das Pooling von SQL-Verbindungen ist unabhängig davon, ob SQL-Authentifizierung oder integrierte Sicherheit verwendet wird, und eine einzige Identität, die Identität angenommen hat (dies trifft nicht zu, wenn sich eine Gruppe von verschiedenen Benutzern imitiert). Aus Gründen der Sicherheit halte ich integrierte Sicherheit für den besten Ansatz. – dariom

0

Dies ist falsch. Da <identity impersonate="true" /> auf "True" festgelegt ist, führt ASP.NET/IIS den Thread als den Benutzer aus, der gerade angemeldet ist (also nicht der App-Pool-Account, sondern der tatsächliche Benutzer, der sich bei der Website angemeldet hat).

Hier läuft noch etwas anderes. Können Sie Ihre Verbindungszeichenfolge für die benutzerdefinierte Datenbank bereitstellen? (abzüglich der privaten Daten natürlich)

+0

Nichts besonderes wirklich .. connectionString = "Datenquelle = sqlserver; Erster Katalog = Protokollierung; Trusted_Connection = True" Der Unterschied ist, dass die Seite unter anonymer Authentifizierung steht. Es ist also kein Benutzer auf der Website angemeldet. – ArjanP

3

Verwenden Sie SPSecurity.RunWithElevatedPrivileges, um Ihren Code im Kontext der App-Pool-Identität auszuführen.

+0

Lars, was denkst du über Daniel Larson's Behauptung, dass RunWithElevatedPrives wenn möglich vermieden werden sollte? Er schlägt vor, stattdessen SPUserToken Identitätswechsel zu verwenden und gibt ein Beispiel hier: http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1919.entry?sa=636841091 -Tom –

Verwandte Themen