SharePointCommunity
Die deutschsprachige Community für SharePoint, Microsoft 365, Teams, Yammer und mit Azure
SharePoint Security Teil 1: Identitäten und Heraufstufung

Blogs

Fabian´s Blog [SharePoint MVP]

Syndication

Die Windows SharePoint Services 3.0 sind zu einer Technologie gereift, die weit über Organisationsgrenzen hinweg immer mehr Anwendung findet. Die Plattform ist mit ihrer aktuellen Version einen langen Weg gegangen ein robustes Sicherheitsmodell bereitzustellen, das für Unternehmen die Grundlage liefert, SharePoint-Lösungen umzusetzen, die den Anforderungen von internen Sicherheitsrichtlinien oder gesetzlichen Bestimmungen entsprechen. In dieser mehrteiligen Artikelserie möchte ich die Sicherheitsfunktionen der Windows SharePoint Services 3.0 aus Entwicklersicht vorstellen und Tipps und Tricks für die Umsetzung von sicherheitsbewussten Anwendungen geben. Die Artikelserie gliedert sich in folgende Teile:

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

Im heutigen Artikel werde ich die unterschiedlichen Identitäten innerhalb einer SharePoint-Website vorstellen sowie auf das Thema das Heraufstufung (Elevation) eingehen.

Die Arbeit mit dem SharePoint-Sicherheitsmodell verlangt zunächst die Betrachtung der unterschiedlichen Identitäten. Kern einer SharePoint-Plattform ist die Benutzeridentität, über die ein Anwender innerhalb einer SharePoint-Webseite berechtigt wird. Bevor ein Benutzer seine individuelle SharePoint-Identität erhält, muss er sich an der Webseite authentifizieren. Die Authentifizierung beschreibt den Prozess zur Identifizierung der Benutzeridentität. Neben der Windows-Authentifizierung unterstützt SharePoint zusätzlich die formularbasierte Authentifizierung gegen eine Datenbank (zum Beispiel SQL Server) oder einen LDAP-basierenden Verzeichnisdienst. Bei dieser Funktion kommt der pluggable ASP.NET Membership Provider zum Einsatz, den SharePoint vollständig unterstützt. Je nach Typ des Authentifizierungsanbieters kann über unterschiedliche Wege auf die Identität eines authentifizierten Benutzers zugegriffen werden. In einer Windows-basierten Systemumgebung können Klassen des System.Security-Namensraums genutzt werden.

   1: // Windows-Identität des aktuell angemeldeten Benutzers 
   2: WindowsIdentity currentWindowsIdentity = WindowsIdentity.GetCurrent();
   3: string userLoginName = currentWindowsIdentity.Name;
   4:  
   5: // Windows-Identität: CONTOSO\UserA
   6:  
   7:  
   8: // Windows Principal mit Informationen zu den Gruppenzugehörigkeiten
   9: WindowsPrincipal currentPrincipal = new WindowsPrincipal(currentWindowsIdentity);
  10:  
  11: if (currentPrincipal.IsInRole("Administrators"))
  12: {
  13:     // Aktionen, die nur für Administratoren erlaubt sind
  14: }
  15:  
  16: // Bei Verwendung der Formular-basierten Authentifizierung kann die aktuelle 
  17: // Benutzeridentität aus dem HttpContext ausgelesen werden
  18: IPrincipal currentHttpUser = HttpContext.Current.User;
  19: string httpUserLoginName = currentHttpUser.Identity.Name;
  20:  
  21: // http-Identität: CONTOSO\UserA
  22:  
  23: // SharePoint-Benutzeridentität mit zusätzlichen Informationen
  24: SPUser currentUser = SPContext.Current.Web.CurrentUser;
  25: string loginName = currentUser.LoginName;
  26: string displayName = currentUser.Name;
  27: string mailAddress = currentUser.Email;
  28: bool isSiteAdmin = currentUser.IsSiteAdmin;
  29:  
  30: // SharePoint-Identität: CONTOSO\UserA


Die WindowsIdentity-Klasse repräsentiert die Identität eines Windows-Benutzers (Active Directory oder lokale SAM-Benutzerdatenbank). Über die WindowsIdentity kann ein WindowsPrincipal-Objekt erzeugt werden, um im Anschluss über die Methode IsInRole die Gruppenzugehörigkeiten der Benutzeridentität zu prüfen. Das SharePoint-Objektmodell verwaltet Informationen eines externen Benutzers (unabhängig des Authentifizierungsanbieters) in einem SPUser-Objekt, das über den Kontext der Website (SPWeb) bereitgestellt wird. Das SPUser-Objekt enthält zusätzliche Informationen zur Benutzeridentität, wie zum Beispiel den Anzeigenamen, die E-Mail-Adresse oder eine Beschreibung.

Neben der Identität eines Benutzers übernimmt die des Anwendungspools einer SharePoint-Webanwendung noch eine besondere Rolle. Der Anwendungspool steuert den Prozess (Worker Prozess) einer Webanwendung der Internet Information Services (IIS) und gibt der Anwendung eigene Prozessor- sowie Speicherressourcen. Dieser Worker Prozess besitzt jeweils eine eigenständige Identität, die über einen Built-in Account (Local System, Local Service oder Network Service) oder einem dedizierten Windows-Benutzerkonto zugewiesen werden kann. Die zweitgenannte Variante ist in Active Directory-Umgebungen dringend zu empfehlen. Gründe liegen unter anderem in einer einfacheren Skalierbarkeit der Farm, granulareren Vergabe von NTFS-Berechtigungen oder dem Trouble Shooting.

Über die Identität des Anwendungspools wird der Zugriff auf Anwendungsdaten (Dateien auf dem Dateisystem des SharePoint-Servers) oder die SharePoint-Inhaltsdatenbank realisiert. Zudem werden alle durch das SharePoint-System ausgeführten Aktivitäten, wie zum Beispiel Workflows, Timer Jobs oder Event Handler, im Kontext der Anwendungspoolidentität ausgeführt. In diesem Zusammenhang liefern die Windows SharePoint Services 3.0 ein neues Konzept: die SharePoint-Systemidentität. Dieser innerhalb der SharePoint Runtime kontrollierte Account hat die Aufgabe, die höher privilegierte Identität des Anwendungspools zu verstecken. Die SharePoint-Systemidentität wird über das interne Benutzerkonto SHAREPOINT\System (SID S-1-0-0) repräsentiert. Durch dieses Verfahren bleibt den Benutzern einer SharePoint-Webseite die eigentliche Identität des Worker Prozesses verborgen.

Wozu benötige ich diese Information als Programmierer? Ein Webpart oder eine andere benutzerdefinierte SharePoint-Anwendung läuft per Default im Kontext des angemeldeten Benutzers. Die Anwendung kann die Aktionen ausführen, für die der aktuelle Benutzer berechtigt ist. In einigen Szenarien kann es jedoch erforderlich sein, die Anwendung mit höheren Privilegien auszuführen. Stellt euch vor, mit einem Webpart auf eine Liste (zum Beispiel eine Liste mit Konfigurationseinstellungen) zuzugreifen, auf die der angemeldete Benutzer keine lesenden Rechte hat. Für diesen Anwendungsfall stellt SharePoint eine integrierte Funktion bereit, die es ermöglicht, Programmcode „heraufzustufen“ und im Kontext des Anwendungspools auszuführen. Was in der Vorversion der Windows SharePoint Services (WSS v2) nur über den Umweg einer Windows API oder COM+ möglich war, kann nun über die Methode RunWithElevatedPrivileges der SPSecurity-Klasse implementiert werden.

   1: // Windows-Identität: CONTOSO\UserA
   2: // SharePoint-Identität: CONTOSO\UserA
   3:  
   4: // Code mit herauf gestuften Rechten ausführten
   5: SPSite currentSite = SPContext.Current.Site;
   6: SPSecurity.RunWithElevatedPrivileges(delegate()
   7: {
   8:     using (SPSite elevatedSite = new SPSite(currentSite.ID))
   9:     {
  10:         using (SPWeb elevatedWeb = elevatedSite.OpenWeb())
  11:         {
  12:             WindowsIdentity elevatedWindowsIdentity = WindowsIdentity.GetCurrent();
  13:             // Windows-Identität: CONTOSO\sp_app_teamsite (App Pool Identität)
  14:  
  15:             SPUser elevatedUser = elevatedWeb.CurrentUser;
  16:             // SharePoint-Identität: SHAREPOINT\system                                                    
  17:         }
  18:     }
  19: });

In diesem Beispiel führt RunWithElevatedPrivileges eine anonyme Methode aus, die im Kontext des Worker Prozesses agiert und somit volle Berechtigungen innerhalb der Webseite besitzt.

Bei der Verwendung der RunWithElevatedPrivileges-Methode gibt es einen wichtigen Aspekt: Die Identität des Anwendungspools wird nur erfolgreich angenommen, wenn der Zugriff auf das SharePoint-Element über ein neu instanziiertes SPSite-Objekt erfolgt. Die Verwendung der Methode SPContext.Current.Site würde nicht zu dem gewünschten Ergebnis führen, da das zurückgegebene SPSite-Objekt vor dem Aufruf von RunWithElevatedPrivileges und somit im Kontext des angemeldeten Benutzers erzeugt wird.

   1: SPSite currentSite = SPContext.Current.Site;
   2: SPSecurity.RunWithElevatedPrivileges(delegate()
   3: {
   4:     SPSite elevatedSiteA = SPContext.Current.Site;
   5:     // Windows-Identität: CONTOSO\UserA
   6:     // SharePoint-Identität: CONTOSO\UserA        
   7:  
   8:     // Erst die Erzeugung eines neuen SPSite-Objekts führt zu dem gewünschten Ergebnis 
   9:     // und führt den Objektzugriff über die SharePoint Systemidentität aus
  10:     using (SPSite elevatedSiteB = new SPSite(currentSite.ID))
  11:     {        
  12:         // Windows-Identität: CONTOSO\sp_app_teamsite
  13:         // SharePoint--Identität: SHAREPOINT\system                                                
  14:     }
  15: });

Im nächsten Teil dieser Artikelserie werde ich beschreiben, welche Möglichkeiten die Windows SharePoint Services bereitstellen, einen Aufruf innerhalb des Programmcodes zu impersonifizieren, also im Kontext eines dedizierten Benutzers auszuführen.


Bereitgestellt 16 Feb 2009 18:28 von Fabian Moritz
Gespeichert unter: ,

Kommentare

TrackBack geschrieben SharePoint Security - Teil 2: Impersonifizierung von Benutzeridentitäten
on 13 Mrz 2009 10:40

SharePoint Security - Teil 2: Impersonifizierung von Benutzeridentitäten

TrackBack geschrieben SharePoint Security - Teil 3: Benutzer und Gruppen
on 26 Mrz 2009 18:35

SharePoint Security - Teil 3: Benutzer und Gruppen

TrackBack geschrieben SharePoint Security - Teil 4: Berechtigungen und Vererbung
on 16 Apr 2009 9:08

SharePoint Security - Teil 4: Berechtigungen und Vererbung