Samstag, 27. August 2011

SharePoint - Rollen und Berechtigungen (3)

In der Artikelreihe "SharePoint - Rollen und Berechtigungen" wird auf die Konzeption von Berechtigungensvergabe und planen der benötigten Rollen für den SharePoint Betrieb eingegangen. Die Erfahrung zeigt, dass diese Konzeption an die Technologie "SharePoint" angepasst werden muss und zur Einführung eines SharePoint Systems nicht vernachlässigt werden darf. Bereits zwei Artikel sind zu diesem Thema erschienen, zum einem ein Artikel über Rollen ( SharePoint - Rollen und Berechtigungen (1) ) und ein Artikel über Authentifizierung ( SharePoint - Rollen und Berechtigungen (2) ). Insgesamt umfasst das Thema drei Artikel:
  1. Rollen,
  2. Authentifizierung,
  3. Autorisierung.
Dieser Artikel über Autorisierung ist somit der letzte Artikel der thematischen Behandlung von Rollen und Berechtigungen in SharePoint und der letzte Artikel vor einem Fazit.

3. Autorisierung

 Die vorangegangen Artikel über Rollen und Authentifizierung bilden die Grundlage für das Thema der Autorisierung in SharePoint.
Die Autorisierung bezeichnet die Zuweisung und die Überprüfung von Zugriffsrechten in SharePoint. Grundlage für die Autorisierung ist eine erfolgreiche Authentifizierung. Nur wenn der Benutzer dem System bekannt ist kann es die zugewiesenen Zugriffsrechte des Benutzers überprüfen. Zugriffsrechte können in SharePoint rechte granular über die einzelnen Hierarchiestufen der Elemente vergeben werden. Die folgende Abbildung stellt eine solche Hierarchie - oder auch Seitenstruktur - mit den entsprechenden Elementen dar.


Zugriffsrechte können auf jeder Ebene dieser Seitenstruktur vergeben. Wichtig dabei zu wissen ist, dass sich die Zugriffsrechte in dieser Seitenstruktur nach unter weiter vererben. Diese Vererbung lässt sich aber an beliebigen stellen, in der Abbildung sind die Pfeile diese Stellen, unterbrechen. Granulare Vergabe von Zugriffsrechten ist also möglich, zum Beispiel das Unterbrechen der Vererbung auf einem SharePoint Element vom Typ "Aufgabe", so dass nur ein bestimmer Personenkreis diese Aufgabe sehen kann. Auch sind bestimmte Zugriffsrechte in SharePoint bekannt, die einem Benutzer zu verschiedenen Aktionen befähigen. Hat ein Benutzer das Zugriffsrecht Lesen, kann er Dokumente zwar öffnen, aber nicht zurück speichern. Hierfür würde er das Zugriffsrecht Mitwirken benötigen. Diese verschiedenen Arten von Zugriffsrechte nennt man in SharePoint Berechtigungsstufen oder Permission Level.
Die Zuweisung und somit auch die Überprüfung von Zugriffsrechten kann für einzelne Benutzer oder für im Vorfeld definierte Gruppen von Benutzern erfolgen. Einer der Vorteile beim Verwenden von Gruppen liegt auf der Hand; ändert sich die Zugehörigkeit zu einer solchen Gruppe, müssen die Berechtigungen nicht über die gesamte Seitenstruktur neu vergeben werden! Die Grundlage der Benutzer und Gruppen sind die im zweiten Artikel über Authentifizierung benannten und erläuterten Benutzerquellen. In der Regel kann man Benutzergruppen schon in der Benutzerquelle verwalten, zusätzlich ist dies aber auch im SharePoint möglich.
Die Vielzahl an Berechtigungsstufen und die Möglichkeiten bei der Zuweisung von Zugriffsrechten durch Benutzerquellen und Gruppen lassen erahnen, dass die Autorisierung in SharePoint eine hohe Komplexität annehmen kann. Eine weit verbreitete Best Practice zum Umgang mit dieser hohen Komplexität rät zum konsequenten Verwenden von Benutzergruppen.

Die Abbildung setzt als Benutzerquelle für SharePoint ein Active Directory System - kurz AD - voraus. Alle Benutzerkonten werden in diesem AD wieder in Benutzergruppen zusammengefasst. Diese Benutzergruppen sind im Idealfall entsprechend der Unternehmensorganisation aufgebaut und losgelöst von Anwendungen oder der Seitenstruktur des SharePoints. Daher kann das AD und seine Gruppen durch einen eigenen Administrator ohne Zusammenarbeit mit einem SharePoint Administrator gepflegt werden. In SharePoint wiederrum werden SharePoint Gruppen entsprechend der Funktionalität der Seitenstruktur eingerichtet. Die im ersten Artikel über erläuterte Rolle des Website Administrator legt diese Gruppen an, weißt Ihnen eine Berechtigungsstufe zu und befüllt sie mit den Benutzergruppen aus dem AD. Am Beispiel einer Abteilungsseite würde dies bedeuten, dass der Website Administrator eine Gruppe Seitenbesitzer, Abteilungsmitglieder und Leser einrichtet und diese mit den AD Benutzergruppen Abteilungsleiter, Abteilungsmitglieder und allen anderen Abteilungsgruppen befüllt. Die Kompetenz der Pflege der Unternehmensorganisation liegt bei einem AD Administrator, die Kompetenz der Zuweisung von Berechtigungsstufen beim Website Administrator. In unserem Beispiel würde das bedeuten, dass ein Website Administrator nicht mehr aktiv eingreifen muss, sollte sich die Abteilungleitung ändern - durch die Pflege der Benutzergruppen hätte der neue Abteilungsleiter die gleichen Zugriffsrechte wie der alte Abteilungsleiter! Diese Best Practice hat also folgende Vorteile:
  • Die Kompetenzen von der Abbildung von Unternehmensorganisation und Abbildung von Zugriffsrechten im SharePoint werden entkoppelt - und so sowohl der Aufwand verteilt als auch die Fehler bei der Abbildung von Zugriffsrechten gering gehalten.
  • Der Pflegeaufwand wird durch die Verwendung der Gruppen minimiert, da nicht für jedes einzelne Benutzerkonto agiert werden muss.
Ohne diese Best Practice und bei der Zuweisung von Zugriffsrechten direkt an ein Benutzerkonto ist die administrative Kontrolle der Zugriffsrechte und die Wartbarkeit des Systems stark gefährdet. Denn Anforderungen wie "Der neue Kollege benötigt exakt die gleichen Rechte!" werden zu einem Problem, welchem nur überdimensionalem Aufwand begegnet werden kann!

Die Fragen, welche sich für eine Konzeption der Autorisierung stellen, sind recht übersichtlich:
  • Welche Berechtigungsstufen ( Zugriffsrechte ) müssen zur Verfügung gestellt werden?
  • Stehen Benutzergruppen in der Benutzerquelle ausreichend zur Verfügung?
  • Wer muss in der Zuweisung von Zugriffsrechten geschult werden?
Gerade der letzten Frage kommt besondere Bedeutung zu. Nicht nur, da die Best Practice für den Key User aus der Fachabteilung durchaus unverständlich sein kann, sondern vor allem da Sie eigentlich im Gegensatz zu den im ersten Artikel beschriebenen Verhältnis der Rollen steht. Je mehr Schlüsselbenutzer aus der Fachabteilung man als Website Administrator ausbildet, um so größer wird der Erfolg beim Einsatz von SharePoint und um so kleiner wird der Aufwand für die interne IT Abteilung. Jedoch: Je mehr Benutzer aus der Fachabteilung Zugriffsberechtigungen zuweisen, um so geringer wird der Erfolg der Best Practice sein!

Wieso Rollen, Authentifizierung und Autorisierung im Zusammenspiel keine wasserdichte Konzeption für SharePoint erlauben und was man dagegen unternehmen kann werden wir im nächsten Artikel, dem Fazit, genauer betrachten.

Good Luck,

Andreas

Freitag, 26. August 2011

SharePoint, PowerShell und Taxonomy

Eines der spannensten Features in SharePoint 2010 ist sicherlich der Managed Metadata Service und Taxonomien. Die Produktversion 2010 ist frisch mit diesem Feature bereichert worden. Daher ist gerade für Anwender, die schon ältere Produktversionen wie den Office SharePoint Server 2007 oder die Windows SharePoint Services 3.0 eingesetzt haben Umdenken angesagt! Hat man sich früher mit Auswahl- und Nachschlagefelder auf Schlagwortlisten beholfen, kann man heute Managed Metadata einsetzen! Dies erfordert allerdings auch neue Anforderungen an die Administration und schafft neue Herausforderungen bei der Migration - denn wer will schon die alten Notlösungen weiter verwenden, wenn er jetzt ein neues Feature dafür hat?! Die Erfahrung zeigt, dass man sich für solche Migrationen von alten Schlagwortspalten in Taxonomien oftmals am besten mit individuellen PowerShell Skripts behilft. Daher möchte ich im folgenden Skript- Beispiele für die häufigsten Anwendungsfälle bereit stellen.

  1. ####   
  2. # www.letssharepoint.com   
  3. ####   
  4.   
  5. # Get Taxonomy Session and Term Store   
  6. $site = Get-SPSite http://yoursiteurl   
  7. $taxonomySession = Get-SPTaxonomySession -site $site  
  8. $termStore = $taxonomySession.TermStores["Your Managed Metadata Service Application"]   
  9.   
  10. # Create Groups   
  11. $termStoreGroup = $termStore.CreateGroup("Your Groupname")   
  12. $termStoreGroup.Description = "Your Description"    
  13. $termStoreGroup.AddGroupManager("domain\user")   
  14. $termStoreGroup.AddContributor("domain\user")   
  15.   
  16. # Create Termset   
  17. $termSet = $termStoreGroup.CreateTermSet("Your Termset name")   
  18.   
  19. # Create Term   
  20. $term = $termSet.CreateTerm("Your Term Name", LanguageID)   
  21.   
  22. $termStore.CommitAll()  
Das Beispiel Skript oben zeigt, wie man sich gegen einen Term Store verbindet und neue Gruppne, Term Sets und Terms anleget. Zu beachten ist, das bei der Methode CreateTerm die LanguageID ausgetauscht werden muss!

  1. ####   
  2. # www.letssharepoint.com   
  3. ####   
  4.   
  5. # Load Microsoft.SharePoint.Taxonomy to work with TaxonomyFieldValueCollection   
  6. [Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Taxonomy")   
  7.        
  8. # Get Taxonomy Session and Term Store   
  9. $site = Get-SPSite http://yoursiteurl   
  10. $taxonomySession = Get-SPTaxonomySession -site $site  
  11. $termStore = $taxonomySession.TermStores["Your Managed Metadata Service Application"]   
  12.   
  13. # Get Web, List item and Taxonomy Field   
  14. $web = Get-SPWeb http://yourweburl   
  15. $list = $web.Lists["YourList"]   
  16. $item = $list.GetItemById(1)   
  17. $taxField = $item.Fields["YourTaxField"]   
  18.   
  19. # Create Taxonomy Field Collection for a Multi Managed Metadata Field   
  20. $taxCollection = new-object Microsoft.SharePoint.Taxonomy.TaxonomyFieldValueCollection $taxField  
  21.   
  22. ## Get Terms and Add them to the TaxonomyFieldValueCollection   
  23. # Get Term Group   
  24. $termStoreGroup = $termStore.Groups["My Group"]   
  25. # Get Term Set   
  26. $termSet = $termStoreGroup.TermSets["My Termset"]   
  27. # Get Terms    
  28. $term1 = $termSet.Terms["Term1"]   
  29. $term2 = $termSet.Terms["Term2"]   
  30. $term3 = $termSet.Terms["Term3"]   
  31. # Get TaxonomyFieldValues   
  32. $taxValue1 = new-object Microsoft.SharePoint.Taxonomy.TaxonomyFieldValue($taxField)   
  33. $taxValue1.TermGuid = $term1.Id   
  34. $taxValue1.Label = $term1.Name   
  35. $taxValue1.WssId = -1   
  36. $taxValue1 = new-object Microsoft.SharePoint.Taxonomy.TaxonomyFieldValue($taxField)   
  37. $taxValue2.TermGuid = $term2.Id   
  38. $taxValue2.Label = $term2.Name   
  39. $taxValue2.WssId = 0   
  40. $taxValue3 = new-object Microsoft.SharePoint.Taxonomy.TaxonomyFieldValue($taxField)   
  41. $taxValue3.TermGuid = $term3.Id   
  42. $taxValue3.Label = $term3.Name   
  43. $taxValue3.WssId = 1   
  44. # Add Values to Tyxonomy Field Value Collection   
  45. $taxCollection.Add($taxValue1)   
  46. $taxCollection.Add($taxValue2)   
  47. $taxCollection.Add($taxValue3)   
  48.   
  49. # Update Managed Metadata Colum on Item   
  50. $taxField = SetFieldValue($item$taxCollection)   
  51. $item.Update()  
Dieses Skript Beispiel zeigt, wie man eine Spalte vom Typ "Verwaltete Metadaten", welche mehrere Werte zulässt, befüllt. Im hier gezeigten Fall werden drei Werte in der Spalte gesetzt. Die WssId des TaxonomyFieldValues wird einfach hochgezählt, sofern das Feld noch nicht mit anderen Werten befüllt ist.

Good Luck,

Andreas

Mittwoch, 24. August 2011

SharePoint - Rollen und Berechtigungen (2)

In der Artikelreihe "SharePoint - Rollen und Berechtigungen" wird auf die Konzeption von Berechtigungensvergabe und planen der benötigten Rollen für den SharePoint Betrieb eingegangen. Die Erfahrung zeigt, dass diese Konzeption an die Technologie "SharePoint" angepasst werden muss und zur Einführung eines SharePoint Systems nicht vernachlässigt werden darf. Im ersten Artikel SharePoint - Rollen und Berechtigungen (1) wurden bereits die folgenden drei Themengebiete identifiziert, die bei der Konzeption berücksichtigt werden müssen:
  1. Rollen,
  2. Authentifizierung,
  3. Autorisierung.
Das erste Themengebiet "Rollen" wurde bereits behandelt, daher wird in diesem zweiten Artikel auf die Authentifizierung eingegangen.

2. Authentifizierung
Wikipedia definiert Authentifizierung wie folgt:

"Authentifizierung (griechisch αυθεντικός authentikós ‚echt‘, ‚Anführer‘; Stammform verbunden mit lateinisch facere ‚machen‘) ist der Nachweis (Verifizierung) einer behaupteten Eigenschaft einer Partei, die beispielsweise ein Mensch, ein Gerät, ein Dokument oder eine Information sein kann, und die dabei durch ihren Beitrag ihre Authentisierung durchführt."
http://de.wikipedia.org/wiki/Authentifizierung

Im SharePoint Umfeld bedeutet Authentifizierung also die Verifizierung eines Benutzer am System. Für eine erfolgreiche Konzeption sind die folgenden beiden Aspekte zur Verifizierung im Vorfeld zu betrachten:
  • Technologie zur Verifizierung,
  • Benutzerquelle.
Als Technologie zur Verifizierung werden in SharePoint verschiedene Möglichkeiten geboten. Natürlich bietet SharePoint die Möglichkeit der Windows Authentifizierung, bei der der aktuell am Computer angemeldete Benutzer vom Browser an das System übergeben wird. Diese häufig verwendete Methode hat den Vorteil, das der Benutzer bei den üblichen Browser-Einstellungen seine Anmeldedaten nicht erneut für die SharePoint-Webseite eingeben muss. Auch sind für die einfachste Art der Windows Authentifizierung - NTLM - keine weiteren Konfigurationsschritte notwendig. Weiterhin stellt SharePoint aber auch die Möglichkeit zur Verfügung, durch Konfiguration von sogenannten Membership- und Roleprovider eine andere Art der Authentifizierung zu verwenden. Bei dieser Möglichkeit wird das lokale Benutzerkonto nicht weitergegeben.
Jede dieser Möglichkeiten verifiziert die Benutzerdaten durch verschiedene Technologien, die natürlich verschiedene Vor- und Nachteile mit sich bringen können. Allen gemeinsam ist jedoch, dass die Benutzerdaten gegen eine Benutzerquelle geprüft werden müssen. Für die Windows Authentifizierung ist diese Quelle meist das Active Directory System des Unternehmens, über welches auch die Anmeldung des Benutzers am Computer verifiziert wird. Je nach Anwendung oder Sicherheitsstandard ist es jedoch notwendig, eine andere Benutzerquelle als das intern für Anmeldungen und Quelle für verschiedene Dienste verwendete Active Directory System , zu verwenden. Diese Quellen werden über die schon genannten Membership Provider angebunden. Solche Quellen können sein:
  • Benutzerdatenbanken,
  • LDAP Systeme,
  • Windows Live ID,
  • und viele weitere.
Da auch die Möglichkeit besteht, einen Membership Provider zu entwickeln, sind den Benutzerquellen kaum grenzen gesetzt!

Folgende Rahmenbedingungen müssen für einen anforderungsgerechten Einsatz allerdings bedacht werden:
  1. Nur Membership Provider ermöglichen die sogenannte Forms Based Authentication. Dabei handelt es sich um eine ASPX-Loginmaske, die an das Design des Portals angepaßt werden kann und sich daher insbesondere für Internet- und Extranetauftritte eignet. Windows Authentifizierung verwendet hingegen immer ein Client-Popup, dass nicht im Design und in der Funktionalität angepasst werden kann. Beim Einsatz dieser Forms Based Authentifizierung wird allerdings niemals der am Computer angemeldete Benutzer an SharePoint weitergegeben. In Folge muss sich ein Benutzer immer gesondert an SharePoint anmelden.
  2. Authentifizierungsmethoden werden pro Webanwendung im SharePoint konfiguriert und können somit nicht verschieden für verschiedene Sites innerhalb einer Webanwendung angelegt werden. Es ist durchaus möglich, verschiedene Methoden für eine Webanwendung einzurichten. Welche Methode SharePoint jedoch für einen Benutzer verwendet, wird durch die Zonen der Alternativen Zugriffszuordnung gesteuert - und somit also über die URL, über die der Benutzer die Webanwendung ansteuert. Möchte man dem Benutzer die Auswahl der Benutzerquelle beim öffnen des Portals ersparen, ist diese Beziehung 1:1 .
  3. SharePoint legt für jeden technischen Benutzer einen internen, so genannten SPUser an. Dieses Benutzer wird zum Beispiel in den Personenspalten von SharePoint verwendet.
  4. Bei der Personenauswahl im SharePoint - zum Beispiel zum setzen von Berechtigungen oder zuweisen von Aufgaben - wird der Benutzer aus der entsprechenden Quelle gewählt.
Aus diesen vier Punkte ergeben sich verschiedene "Fallen" bei der Konzeption, insbesondere bei Internet- oder Extranetszenarien, die Quellen für interne und externe Benutzer mischen. Verwendet ein Benutzer intern Windows Authentifizierung über eine interne URL um die Vorteile der Office Client Integration und der automatischen Anmeldung zu verwenden, von extern aber einen Membership Provider über eine externe URL, hat dieser eine Benutzer zwei Benutzerkonten für die gleiche SharePoint Seite. Die oft geäußerte Anforderungen, das Mitarbeiter von Zu hause über das Internet genau so arbeiten sollen wie von intern und nur ein Profil besitzt, läßt sich so kaum realisieren.

Wie dieses Beispiel zeigt, sollte die Einrichtung der Authentifizierung im Vorfeld gut durchdacht werden, damit man bei der Umsetzung von Anwendungen und Szenarien keine Anforderungen übersieht, die im Gegensatz zur Machbarkeit bei der SharePoint Authentifizierung stehen. Eine Konzeption zur Authentifizierung muss daher die folgenden Fragen für jede Webanwendung beantworten:
  • Über welche Wege wird zugegriffen?
  • Welche Benutzerquellen werden aus Anwendungs- und Sicherheitsgründen benötigt?
  • Sind einem Benutzer zwei oder mehr Benutzerkonten ( SPUser ) zugeordnet? Wird damit eine Anforderung erfüllt oder nicht erfüllt?
  • Erfüllt der gewählte Membership Provider die Anforderungen an die Benutzerquelle?
Die Klärung der Authentifizierung ist neben den Rollen die zweite Säule eines erfolgreichen Rollen- und Berechtigungskonzeptes für SharePoint. Neben der dritten Säule Autorisierung bleibt nur ein Fazit, um alle relevanten Themen zu behandeln.

Good luck,

Andreas