In diesem Beitrag möchte ich mich einem etwas unübersichtlichen Thema widmen: den Authentifizierungsmöglichkeiten unter SharePoint 2010.

Oftmals fällt es Kunden und Consultants schwer, die passende Lösung für Ihr SharePoint-Szenario zu finden – aus einem einfachen Grund: es fehlt an einer deutlichen Abgrenzung zwischen den verfügbaren Lösungsmöglichkeiten und deren Auswirkungen auf die SharePoint Umgebung.

In der Tat wird Komplexität und Vielfalt der Ansätze unter SharePoint 2010 nicht geringer, jedoch hat sich einiges getan, was einer Erwähnung wert ist. Daher möchte ich in diesem Beitrag zunächst eine Übersicht über die Möglichkeiten und den zentralen Neuerungen auf diesem Feld geben.

Bislang (unter SharePoint 2007) war die Ausgangssituation folgende. Wir wählen zwischen drei Authentifizierungskategorien:

• Windows Authentifizierung
• Formularbasierte Authentifizierung (FBA)
• Web SSO (Single Sign-On)

Da die hier angeführten Authentifizierungsmethoden weitestgehend ebenfalls unter SharePoint 2010 zur Verfügung stehen, werfen wir doch zunächst einmal einen Blick hinter die Kulissen der jeweiligen Kategorie :

Die Windows Authentifizierung enthält unsere alten Bekannten: Windows integrierte-, Kerberos-, Basic-, Digest- und Zertifikatsauthentifizierung.

Hinter FBA schlummern in Form einer Reihe an Built-in-Mitgliedschaftsanbietern (Providern) die Möglichkeiten, endlich auch Benutzerkonten außerhalb unserer Active Directory Gesamtstruktur in SharePoint zu integrieren. Wir finden hier den AspNetSqlMembershipProvider wieder, mit dessen Hilfe wir Anwender aus einer SQL-Datenbank in SharePoint berechtigen können, sowie weitere, selbstredende Provider:

• ActiveDirectoryMembershipProvider – für die Anbindung an das AD
• LDAPMembershipProvider – für die Anbindung eines nicht-MS-LDAP-Verzeichnisdienstes

Da diese Schnittstelle erweiterbar ist, finden sich noch weitere Kandidaten, wie beispielsweise einen ADAM-Provider im Netz.

Sollten Sie sich am Ende des Tages für FBA entscheiden, dann sieht Ihre Standardanmeldemaske unter SharePoint 2010 so aus:

Hinter Web SSO verbirgt sich die Möglichkeit, sowohl ADFS (AD-Verbunddienste), als auch weitere, alternative Identitätsmanagementsysteme anzusteuern. Konkret bedeutet dies im Falle von ADFS, dass sich zwei Partnerunternehmen so beispielsweise Zugriffsrechte für Konten beider Unternehmen in einer Farm gewähren können, ohne dass eine AD-Vertrauensstellung existieren muss. Abgekürzt müssen lediglich die Federation Proxyserver beider Unternehmen via HTTP bzw. HTTPS miteinander kommunizieren können. In SharePoint 2010 gibt es im übrigen ADFS der Version 2.0 (mit der gleichen Basis wie die Forderungsauthentifizierung – mehr dazu später).

Somit haben wir also schon einmal eine ganze Menge an Möglichkeiten, Berechtigungen für unterschiedliche Benutzerkontenstämme zu adressieren – die Frage bleibt: welche Hilfe gibt es für die Entscheidungsfindung bei mehrfachen Lösungsansätzen?

Nun zu den Problemen: Zunächst einmal ist die Einrichtung von Web SSO und FBA alles andere als selbstredend – gut, Kerberos ist auch nicht immer leicht einzurichten – jedoch bleibt es leider nicht bei der schwierigen Einrichtung – sobald wir auf Web SSO oder FBA zurückgreifen verlieren wir in der Regel etwas sehr wichtiges (siehe Folie aus meinem Security-Vortrag auf der SharePoint-Konferenz):

Zu erläutern bleibt vielleicht noch der Begriff der Client-Integration:

Hinter der Client-Integration verbergen sich die vielen Dinge, die richtig Spaß machen:

• Dokumente direkt aus SharePoint heraus bearbeiten
• Aus dem Portal direkt auf Office-Funktionen zugreifen

Demnach müssten die Anwender also ohne Client Integration zunächst die Daten offline speichern, Sie bearbeiten und dann wieder hochladen! Schlimm, oder? Glücklicherweise gibt es seit Office 2007 SP2 bzw. Office 2010 Abhilfe für dieses Problem…

Nur leider bleibt es nicht bei den hier erwähnten Problemen – sobald Sie übergreifend Berechtigungen vergeben merken Sie warum - abgekürzt: Sie bzw. der PeoplePicker finden Anwender von der “Anderen Seite” jeweils nur unter bestimmten Bedingungen…

Bevor wir uns weiter frustrieren wird es also Zeit für etwas Neues: die Forderungsauthentifizierung (auch Claims based Authentication genannt)!

Bei dieser neuen SharePoint-Authentifizierungsmethode finden wir neben einem drastisch veränderten Rahmenmodell einige Lösungen für die Probleme der Vergangenheit.

Das Forderungsauthentifizierungsmodell für SharePoint Server 2010 basiert auf Windows Identity Foundation (WIF) und ermöglicht die Authentifizierung für Windows und nicht auf Windows basierende Systeme. Das WIF-Framework wiederum ist eine Gruppe von .NET Framework-Klassen zur Implementierung von anspruchsbasierten Identitäten. Durch die Integration von SAML (Security Assertion Markup Language) wird es Ihnen ermöglicht, SSO-Phantasien auf ein breites Spektrum an vorhandenen Webdiensten zu erweitern.

Mit Hilfe der Forderungsauthentifizierung können Sie mehrere Authentifizierungsmethoden in einer einzelnen Zone implementieren. Sie benötigen also nicht mehr eine erweiterte Webanwendung für jede gewählte Authentifizierungsvariante und können die altbekannten Authentifizierungskandidaten unter einer Haube vereinen.

Ähnlich wie bei FBA werden Cookies als Single Sign-On Tickets für die Anwender verwendet. Für die Ausstellung der Token wird jedoch der Sicherheitstokendienst (STS) genutzt – glücklicherweise stellt SharePoint 2010 einen vollständigen STS für Sie bereit, der sich der eingehenden Sicherheitstokenanforderungen annimmt!

Eine weitere, gute Nachricht: Die Anwender sehen sich beispielsweise bei der Rechtevergabe ohne Probleme untereinander, dafür jedoch unter Verwendung eines erweiterten PeoplePickers:

Nach der Fertigstellung der Konfiguration sieht Ihr Anmeldefenster dann beispielsweise so aus:

Natürlich gibt es noch deutlich mehr frohe Botschaften, die zugegebenermaßen teilweise auch auf den gut zuspielenden Windows Server 2008 R2 zurückzuführen sind – aber: Hilfe ist in diesem Technologiesegment wirklich sehr willkommen.

Neben all diesen schönen Möglichkeiten wird bei dem ein oder anderen vielleicht die Frage nach der Integration von Windows LiveID-Identitäten aufkommen. Stand heute werden Sie keine Out-Of-The-Box-Lösung hierfür vorfinden, es ist jedoch recht sicher, dass dies nicht mehr allzu lang auf sich warten lässt, schließlich gab es ja auch schon unter SharePoint 2007 hier Lösungen, wie das Community Toolkit auf Codeplex. Für die, die jetzt schon nicht mehr warten können, gibt es eine günstige Drittanbieterlösung: Windows Live Authentication for SharePoint - Shetab Technologies

Sollten Sie Appetit auf das Authentifizierungsmenü bekommen haben, so sollten Sie einen Blick auf das im Juli im MS Press Verlag erscheinende SharePoint 2010 Handbuch werfen – dort schreibe ich deutlich mehr zu diesem Thema – inklusive der detaillierten Einrichtung der angedeuteten Lösungen:

http://www.amazon.de/Microsoft-SharePoint-Server-2010-Administratoren/dp/3866451369/ref=sr_1_1?ie=UTF8&s=books&qid=1267475207&sr=8-1