Identitätswechsel
Letzte Änderung: Mittwoch, 14. April 2010
Gilt für: SharePoint Foundation 2010
Identitätswechsel, ein Feature, das in Windows SharePoint Services 3.0 hinzugefügt wurde, ermöglicht es, Aktionen im Namen eines anderen Benutzers durchzuführen. Identitätswechsel ist beispielsweise bei Zeitgeberaufträgen nützlich, die Daten asynchron im Namen eines Benutzers aktualisieren müssen, lange nachdem der Benutzer die Benutzung der Website bereits eingestellt hat (also nach Abschluss des Workflows).
.gif "Hinweis") Hinweis |
|---|
Weitere Informationen zum Aufheben des Identitätswechsels finden Sie unter Vermeiden des Aussetzens des Identitätswechsels durch den aufrufenden Benutzer. |
Wenn Sie eine SharePoint-Website programmgesteuert unter Verwendung des Microsoft.SharePoint-Namespace erstellen, können Sie ein Benutzertoken bereitstellen, mit dem Sie Objekte im Kontext eines bestimmten Benutzers erstellen können. Sie können die Identität eines Benutzers übernehmen, indem Sie das entsprechende Benutzertoken übergeben, das Sie vom Microsoft.SharePoint.SPUser-Objekt erhalten haben. Das Benutzertoken SPUserToken ist ein binäres Objekt, das die Bezeichnung und Domänengruppenmitgliedschaft eines Benutzers enthält.
Auf diese Weise können Sie den Microsoft.SharePoint.SPSite-Konstruktor nutzen, um ein Websitesammlungsobjekt zu instanziieren, das so ausgeführt wird, als würde der betreffende Benutzer die Änderungen vornehmen.
In der Regel ist es nicht notwendig, umfangreiche Sicherheitsvorkehrungen für die Speicherung der Benutzeranmeldeinformationen zu treffen. Die Anmeldeinformationen können mithilfe von Code angezeigt werden, der mit Systemkontoberechtigungen oder mit den entsprechenden Benutzerinformationsberechtigungen ausgeführt wird.
Beachten Sie, dass Benutzertoken im Allgemeinen nach etwa 24 Stunden ablaufen. Wenn Sie also einen langen, verzögerten Vorgang planen, sollten Sie die Benutzer-ID in einer Datenbank speichern und später abrufen. Dies kann allerdings die Leistung beeinträchtigen, da durch das Abrufen von Informationen aus einer Datenbank zusätzlicher Aufwand entsteht. Bei "leicht asynchronen" Vorgängen sollte dies nicht nötig sein, beispielsweise, wenn der Vorgang nur fünf Minuten später ausgeführt wird.
Der Identitätswechsel erfordert eine bidirektionale Vertrauensstellung. Er ist daher nicht verfügbar, wenn das Web-Front-End, das mit der SharePoint-Datenbank interagiert, sich auf einem Server zwischen zwei anderen Netzwerken befindet. In diesem Fall verfügt der Front-End-Webserver nur über eine unidirektionale Vertrauensstellung. Darüber hinaus werden Gruppen-Sicherheits-IDs (SIDS) nicht gefiltert, was gegen die SID-Filterrichtlinie zwischen Domänen verstoßen könnte.
Der Identitätswechsel ist zwar ein leistungsstarkes Sicherheitsverwaltungsverfahren, sollte aber mit Vorsicht eingesetzt werden, damit keine unerwünschten Aktivitäten von Benutzern durchgeführt werden, die nicht zum Identitätswechsel in der Lage sein sollten.
| Hinweis |
|---|
Damit Sie nach einer Codeaktion mit Identitätswechsel weiter mit den Objekten auf einer Website arbeiten können, müssen Sie das SPSite-Objekt erneut instanziieren. |
Verwalten von Benutzertoken
SharePoint ruft Benutzertokeninformationen aus der SharePoint-Datenbank ab. Wenn der Benutzer die Website noch nie besucht hat oder das Benutzertoken vor mehr als 24 Stunden generiert wurde, erzeugt SharePoint ein neues Benutzertoken. Hierzu wird versucht, die Liste der Gruppen zu aktualisieren, denen der Benutzer angehört.
Wenn es sich bei dem Benutzerkonto um ein NT-Konto handelt, verwendet SharePoint die AuthZ-Schnittstelle, um im Active Directory-Verzeichnisdienst eine Abfrage nach der TokenGroups-Eigenschaft durchzuführen. Hierbei können Fehler auftreten, wenn SharePoint im Extranetmodus ausgeführt wird und nicht über die Berechtigung zum Abfragen von Active Directory nach dieser Eigenschaft verfügt.
Wenn es sich bei dem Benutzerkonto um einen Mitgliedsbenutzer handelt, führt SharePoint in ASP.NET RoleManager eine Abfrage nach allen Rollen aus, denen der Benutzer angehört. Hierbei können Fehler auftreten, wenn keine geeignete .config-Datei für die aktuelle ausführbare Datei vorhanden ist.
Wenn SharePoint die Gruppenmitgliedschaften des Benutzers weder aus Active Directory noch aus <roleManager> abrufen kann, enthält das neu generierte Token nur die eindeutige Sicherheits-ID (SID) des Benutzers. Es wird zwar deshalb keine Ausnahme ausgelöst, aber ein Eintrag in das ULS-Serverprotokoll geschrieben. Das neue Token wird außerdem in die SharePoint-Datenbank geschrieben und kann innerhalb der nächsten 24 Stunden nicht noch einmal neu generiert werden.
Nachdem SharePoint ein neues Token erhalten hat, entweder aus der SharePoint-Datenbank oder ein neu generiertes Token, wird als Zeitstempel der aktuelle Zeitpunkt festgelegt und das Token an den Aufrufer zurückgegeben. So ist sichergestellt, dass das Token 24 Stunden lang aktuell bleibt.
Nachdem das SPUserToken-Objekt an den Aufrufer zurückgegeben wurde, liegt es in dessen Verantwortung, das Token nach seinem Ablauf nicht mehr zu verwenden. Sie können ein Hilfsdienstprogramm zur Verfolgung des Tokenablaufs erstellen, mit dem die Differenz zwischen dem aktuellen Zeitpunkt und dem Zeitpunkt, zu dem das Token abgerufen wurde, mit SPWebService.TokenTimeout verglichen wird.
Wenn ein abgelaufenes Token zum Erstellen einer SharePoint-Website verwendet wird, wird eine Ausnahme ausgelöst. Der standardmäßige Timeoutwert für Token beträgt 24 Stunden. Der Zugriff erfolgt über SPWebService.TokenTimeout.
Sie können den Timeoutwert für Token auch mithilfe von Stsadm abrufen oder festlegen. Mit folgendem Befehl wird ein Wert aus dem Benutzertoken zurückgegeben:
stsadm -o getproperty -propertyname token-timeout
Nachfolgend sehen Sie das Ergebnis:
<Property Exist="Yes" Value="1440" /> // 1440 minutes is 24 hours
Mit folgendem Befehl wird ein Wert für ein Benutzertoken festgelegt:
stsadm -o setproperty -propertyname token-timeout -propertyvalue 720