SharePoint Security – das Claims-basierte Identitätskonzept

14. November 2013Peter Scheidemann

Seit SharePoint 2010 ist die Nutzerauthentifizierung mit der Claims-based Identity möglich und ab SharePoint 2013 die einzige dauerhaft verbleibende Option, die nach den kommenden Aktualisierungen (Service Packs) noch unterstützt werden wird. Wie der Weg hin zu diesem Identitätsmodell aussieht und was die Vorteile sind, soll in diesem Beitrag erläutert werden.

Mit SharePoint 2007 (SharePoint Services 3.0) wurde ein Konzept zur Nutzerauthentifizierung eingeführt, das sich „forms-based authentication“ nennt. Es handelt sich um ein Feature der Basistechnologie ASP.NET das die Identifikation von Benutzern durchführt, indem vor der Autorisierung des Zugriffs auf gewünschte Inhalte (Seiten, Dokumente, SharePoint Listen, …) Informationen über ein HTML-Formular (meist Benutzername und Kennwort) erfragt werden, die die erforderlichen Rechte für diesen Zugriff nachweisen. Anders formuliert: Ein nicht authentifizierter Besucher wird beim Versuch des Zugriffs auf die Plattform zuerst aufgefordert, seine Benutzerdaten einzugeben. Die Daten werden validiert, bevor der Benutzer (bzw. dessen Browser/Client) mit einem Sicherheits-Token versehen wird. Dieser wird in einem Cookie gespeichert und vom Browser/Client mit jedem nachfolgenden Request bis zum Ablauf seiner Gültigkeit mitgesendet, sodass sich der Benutzer nicht bei jedem Folge-Request immer wieder authentifizieren muss.

Das grundsätzliche Verfahren besteht in dieser Form bis heute. Doch in der neuesten SharePoint-Version gibt es zentrale Unterschiede, die ich nun darlegen und beurteilen möchte.

Zur Veranschaulichung des zentralen Vorteils der neuen Version werfen wir einen Blick auf den vorhergehenden Standard: die Windows-Authentifizierung. Diese ist in der einfachsten Form folgendermaßen beschrieben: Der Web Server, nicht die Web Application, (im Falle von SharePoint der IIS) ist dafür zuständig, den Client zu authentifizieren und verwendet dafür den übermittelten Windows-Account des Nutzers. Der Laufzeit der Web Application wird eine Instanz der WindowsIdentity-Klasse übergeben, die nichts anderes ist als eine Repräsentation des Windows-Nutzers. Der zentrale Nachteil: Für alle potenziellen Nutzer ist eine Verwaltung von Windows-Nutzer-Accounts erforderlich.

Im Gegensatz dazu erlaubt die Formular-basierte Authentifizierung die Validierung von Identifikationsinformationen gegen eine Vielzahl von Datenquellen, in denen gültige Benutzerinformationen vorgehalten werden können. Microsoft bietet die dafür erforderlichen „Provider“ für verschiedene Datenquellen an, beispielsweise für den eigenen SQL-Server, für LDAP-unterstützende Systeme oder auch für Oracle-Datenbanken, hier insbesondere den Membership Provider, der die Benutzereingaben validiert. Werden vom Benutzer gültige Daten eingegeben, dann ist dieser authentifiziert, erhält ein Sicherheits-Token in Form eines Cookies und kann den SharePoint für die vom Administrator festgesetzte Gültigkeitsdauer nutzen.

Auf dem Weg zur Claims-basierten Identität wird ein Sprung von SharePoint 2007 über die 2010er Version hin zum neuesten SharePoint 2013 gemacht. Während die Formular-basierte Authentifizierung bei der 2007er Variante noch durch die Web Application selbst durchgeführt wurde, begann mit der Einführung von SharePoint 2010 die Zeit der sogenannten „federated Authentication“, also der Benutzerauthentifizierung durch „vertrauenswürdige Dritte“, die bei der Cloud-gehosteten Variante „SharePoint Online“ seit der 2010er Version Standard ist.

Neben der Verifizierung durch die Web-Anwendung ist die Authentifizierung damit auch delegierbar. Egal, wie die Authentifizierung erfolgt, letztlich wird dem SharePoint bei den einzelnen Requests keine Benutzeridentität in Form eines Windows-Accounts präsentiert, sondern eine Menge sogenannter „Claims“, die sich gemessen mit dem, was sie enthalten können, am ehesten mit dem Begriff „Zusicherung“ übersetzen lassen. Ein Claim kann beispielsweise den Namen des Benutzers enthalten, aber auch Dinge wie sein Alter oder das Geburtsdatum. Unternehmensrelevant wären auch die Abteilung, die Position oder der zugehörige Standort.

Das Identitätskonzept sieht vor, dass ein „Claims Provider“ den Benutzer authentifiziert. Dies geschieht nach wie vor gegen eine Benutzerdatenquelle, für die es keine vorgegebene Technologie gibt (AD, SQL Server, …). Das zurückgelieferte Sicherheits-Token des Benutzers enthält dann eine Menge von Claims und ist verschlüsselt. Damit SharePoint dem Token vertraut, muss eine Vertrauensbeziehung zwischen SharePoint und dem Claims Provider existieren. Liegt diese vor, kann SharePoint die Signatur des Tokens erfolgreich verifizieren und vertraut den darin enthaltenen Zusicherungen/Claims.

Informationsflüsse bei der federated Authentication in SharePoint 2013

Angenommen, eine SharePoint-Liste ist für Mitarbeiter eines bestimmten Standortes zum Lesen freigegeben. Dann kann der Mitarbeiter dies tun, wenn in seinem Token das erforderliche Claim enthalten ist. Vom Prinzip her ähnelt dieses Identitätskonzept einer Bar, in der ein Gast, der ein Bier trinken möchte, seinen Ausweis vorlegen muss. Der Wirt hat den Ausweis nicht erstellt und ihn interessieren Augenfarbe, Körpergröße oder Name des Gastes nicht, aber er vertraut einem deutschen Ausweis und damit auch der darauf enthaltenen Altersangabe und entscheidet darauf basierend, ob der Gast das gewünschte Bier erhält.

URL der Authentifizierungsstelle zahlreicher Microsoft-Cloud-Angebote beziehungsweise „SharePoint Online“ und „Office 365“

Neben dem Vorteil, dass dank der Formular-basierten Benutzerauthentifizierung Unabhängigkeit von der Benutzerdatenquelle geschaffen wird, gibt es noch einen weiteren vorteilhaften Aspekt bei der Einführung einer Claims-basierten Identität: SharePoint ist nicht mehr notwendigerweise dafür zuständig den Benutzer zu authentifizieren. Angenommen, es gibt in einem (großen) Unternehmen zahlreiche sicherheitskritische Systeme, auf die gleiche oder überschneidende Mengen von Mitarbeitern Zugriff haben müssen. Mit dem vorliegenden Identitätskonzept reicht die Umsetzung von Vertrauensbeziehungen all dieser Systeme mit einem Claims Provider, um die Benutzerauthentifizierung im Idealfall firmenweit umzusetzen. Innerhalb der Systeme selbst ist lediglich die Autorisierungsverwaltung erforderlich, also die Festlegung, wer was darf.

Positiv fällt auf, dass unter Beibehaltung der Nutzerauthentifizierung in Form einer Login-Seite der zentrale Vorteil der formularbasierten Authentifizierung erhalten bleibt; nämlich die Nutzung beliebiger Nutzerdatenquellen zur Verifikation. Zusätzlich wird die Basis für eine Integration verschiedener ID-Systeme in einem Unternehmen oder auch über Unternehmensgrenzen hinaus geschaffen. Somit ist Single-Sign-On über heterogene Web-Anwendungen hinaus denkbar und damit sehr vielversprechend. Wünschenswert wäre allerdings eine größere Unterstützung für Entwickler, die beispielsweise Client-Anwendungen für SharePoint entwickeln. Wie schon in der API für SharePoint 2010 fehlt in der Version für 2013 die Unterstützung für diese Form der Authentifizierung. Steht ein Entwickler vor der Aufgabe, eine Desktopanwendung zu entwickeln, die mit SharePoint kommuniziert (beispielsweise Dokumente herunterlädt), ist der Umgang mit der Weiterleitung zur Authentifizierungsstelle und die Weitergabe des Tokens an SharePoint „händisch“ zu programmieren.

Trifft diese Art der Nutzerauthentifizierung Ihre Sicherheitsstandards und welche Vor- oder Nachteile sehen Sie im Konzept der Claims-based Identity?

Sind Sie Entwicker und haben spezielle Fragen zur Programmierung? Ich beantworte gern Ihre Fragen und freue mich auf Ihre Meinungen.

Peter Scheidemann Peter Scheidemann ist seit 2 Jahren in der Softwareentwicklung tätig. Bei adesso arbeitet er im SharePoint-Umfeld und derzeit auch mit dem Content-Management-System FirstSpirit.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: