Startseite > SharePoint Server > Berechtigungen konzipieren und verwalten für eigene SharePoint Anwendungen

Berechtigungen konzipieren und verwalten für eigene SharePoint Anwendungen

Vor der Erstellung eines Berechtigungskonzepts für Portale und eigenen Anwendungen in SharePoint steht immer eine fachliche Analyse und Konzipierung von fachlichen Nutzerrollen. (Wenn das bei Ihnen bisher noch nicht so war, dann sollte das dringend geändert werden.) Trotzdem kommt es anschließend fast immer zu nachträglichen (wenn auch minimalen) Anpassungen im Berechtigungskonzept.

Use Cases und weiter

Im Rahmen dieser fachlichen Anforderungsanalyse werden meist auch Use Cases (fachliche Anwendungsfälle) schriftlich ausformuliert. In den Use Cases werden als Akteure fachliche Benutzerrollen zum Tragen kommen.

Die Herausforderung ist das Mapping zwischen fachlichen Use Cases und den daraus entstehenden Aktionen/Funktionen auf Daten in SharePoint. Also welcher Teil von CRUD auf welche SharePoint Liste oder SharePoint Item. Öfters werden solche Aktionen mittels Standard-Actions aus der Ribbon-Bar oder selbst entwickelten Custom-Actions durchgeführt.

Irgendwann in dem Prozess wird es ein Mapping von fachlichen Nutzerrollen auf technische Benutzergruppen im Active Directory und/oder im SharePoint Server geben. Entweder ist es ein reines 1:1 Mapping, oder ein 1:n Mapping; je nach Konzeption der Portalstruktur und der (meist schon vorhandenen) Gruppen im Active Directory.

Definieren von Berechtigungs-Sets und Berechtigungen

Die Permission-Levels (Berechtigungs-Sets) spielen eine entscheidende Rolle. Entweder werden die standardmäßigen Permission Levels (Reader, Contributer, …) verwendet, oder es werden eigene Permission Levels aus den 36 Einzelberechtigungen (Auflistung der Permissions für SharePoint 2010) zusammengestellt. Ich empfehle die Definitionen von eigenen Permission Levels, welche anschließend einer Benutzergruppe zugewiesen werden. Zur Definition eigener Levels bietet sich diese Vorlage (Excel-Tabelle siehe diesen Blog-Post) an.

In diesem Schritt muss auch definiert werden, welches definierte Permission-Level auf welchen Bereich (z.B. „Site“, Liste“) in den Site Collections und Websites angewendet wird.

Das gute an der Erfassung in Excel-Listen ist die Abstimmung mit dem Anforderer und nachträgliche Änderungen. Weiterhin kann man diese gut den Entwicklern zur Umsetzung übergeben.

P.S. Ein Teil 2 nach diesem Blog-Post ist in Planung.

Quellen und weitere Literatur-Tipps:

  1. Es gibt noch keine Kommentare.
  1. No trackbacks yet.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: