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?
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
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