Weitere Artikel dieser Serie:

• SharePoint Identitäten und Heraufstufung
• Impersonifizierung von Benutzeridentitäten
• Benutzer und Gruppen
• Berechtigungen und Vererbung
• Sicherung und Wiederherstellung

Im heutigen Artikel zur Serie SharePoint Security werde ich beschreiben, welche Möglichkeiten die Windows SharePoint Services 3.0 liefern, Programmcode zu impersonifizieren, also im Kontext eines anderen Benutzers auszuführen. Klassische Anwendungsfälle ergeben sich durch die Verwendung von Event Receivern oder Workflows, die standardmäßig im Kontext des Worker Prozesses (Identität des Anwendungspools) ausgeführt werden. Sollte zum Beispiel dieser Programmbaustein einen Eintrag innerhalb einer SharePoint-Liste oder Dokumentenbibliothek hinzufügen oder ändern, ist der Autor des Elements jeweils der Benutzer SHAREPOINT\System. Dieses Verhalten kann durch die Impersonifizierung von Programmcode umgangen werden. Folgender Codeschnipsel demonstriert die Implementierung einer WSS-Impersonifizierung.

   1: SPUser userBob = currentSite.RootWeb.SiteUsers["contoso\\bob"];

   2:                    

   3: sing (SPWeb elevatedSite = currentSite.OpenWeb())

   4:                         

   5:    SPUser targetUser = elevatedSite.SiteUsers.GetByID(userBob.ID);

   6:    SPUserToken token = targetUser.UserToken;

   7:  

   8:    using (SPSite impersonatedSiteCollection = new SPSite(currentSite.ID, token))

   9:    {

  10:        using (SPWeb impersonatedSite = impersonatedSiteCollection.OpenWeb())

  11:        {

  12:            WindowsIdentity impersonatedIdentity = WindowsIdentity.GetCurrent();

  13:            SPUser impersonatedUser = impersonatedSite.CurrentUser;

  14:            // SharePoint User: contoso\bob

  15:        }

  16:    }

Dem Konstruktor der SPSite-Klasse kann als Parameter ein SPUserToken-Objekt übergeben werden, das die Identität des neu generierten SPSite-Objekts definiert. Wichtig zu wissen ist, dass dieser Programmcode nur funktioniert, wenn in der Code Access Security-Richtlinie für die SharePointPermission das Attribut Impersonate=“True“ gesetzt ist. Eine Alternative ist den Code in den Global Assembly Cache zu deployen, was ich allerdings nicht empfehlen würde!

Wenn wir uns und die beiden beschriebenen Verfahren der Heraufstufung und Impersonifizierung genauer anschauen, ergibt sich ein sehr interessanter Implementierungsansatz. In der Praxis haben wir in einigen Szenarien die Erfahrung gemacht, dass RunWithElevatedPrivileges nicht immer der beste Weg ist Privilegien heraufzustufen. Vor allem bei der Arbeit mit SharePoint-Objekten in unterschiedlichen Sicherheitskontexten, kann es durch die Verwendung von RunWithElevatedPrivileges zu Fehlern kommen. Ein interessanter und robuster Lösungsansatz ist die Kombination beider Verfahren. Neben einen einfachen Benutzeraccount kann auch die SharePoint-Systemidentität impersonifiziert werden, um damit Code mit heraufgestufen Rechten ausgeführt werden. Hier ein Beispiel:

   1: SPUserToken systemAccountToken = SPContext.Current.Site.SystemAccount.UserToken;

   2:  

   3: using (SPSite impersonatedSystemAccountSite = new SPSite(SPContext.Current.Site.ID, systemAccountToken))

   4: {

   5:     using (SPWeb impersonatedSystemAccountWeb = impersonatedSystemAccountSite.OpenWeb())

   6:     {

   7:         WindowsIdentity impersonatedIdentity = WindowsIdentity.GetCurrent();

   8:         SPUser impersonatedUser = impersonatedSystemAccountWeb.CurrentUser;

   9:         // SharePoint User: SHAREPOINT\System

  10:     }

  11: }

Dieses Vorgehen würde ich mit meinem heutigen Wissenstand bei der Heraufstufung von Privilegien im Zusammenhang mit SharePoint-Objekten immer empfehlen. Soll der Heraufstufung genutzt werden, um auf andere Ressourcen außerhalb der SharePoint-Umgebung zuzugreifen empfehle ich RunWithElevatedPrivileges.

Das soll es zum Thema Heraufstufung und Impersonifizierung er einmal gewesen sein. Feedback, Hinweise und Anregungen sind gerne willkommen! Im nächsten Teil widme ich mich dem Thema Benutzer und Gruppen.