SharePoint Custom MembershipProvider und Custom RoleProvider

Nachdem ich in den vergangenen Wochen viel Spass mit der Entwicklung eines Custom MembershipProviders und – quasi als Nebenwirkung – Custom RoleProvider hatte möchte ich hier ein paar wichtige Erfahrungen teilen.

Was ist allgemein zu beachten?

Wenn man eine eigene Datenquelle als Authentifizierungsanbieter verwenden möchte muss man sich einen Custom MembershipProvider schreiben. Soweit so gut. Mit dem Authentifizieren ist es aber noch nicht getan. Denn nur, weil der Server nun weiß wer angemeldet ist heißt es ja noch lange nicht dass der entsprechende Benutzer auch ein Recht hat irgendetwas anzusehen. SharePoint ist was das angeht sehr restriktiv. Damit man nun nich händisch jeden Benutzer aus der Datenquelle einer SharePoint-Gruppe zuweisen muss (in meinem Fall mehrere Tausend) bietet es sich an auch einen Custom RoleProvider zu schreiben.

Was ists nun aber wenn die Datenquelle keine Informationen über Gruppen enthält, sondern einfach alle authentifizierten Benutzer auch gleichzeitig zum Zugriff autorisiert sein sollen? Für das Active Directory gibt es freundlicherweise eine eigene Gruppe namens „NT AUTHORITYAuthenticated Users“ die man auch komfortabel unter „Benutzer hinzufügen“ über einen Link aufrufen kann. Für eigene Benutzerdatenquellen geht dies leider nicht. Daher muss ein eigener RoleProvider geschrieben werden (siehe Blogeintrag von Brett Geoffro).

Continue reading “SharePoint Custom MembershipProvider und Custom RoleProvider” »

SharePoint Custom MembershipProvider: Abfrage gegen eine Datenbank

Teil meiner Diplomarbeit ist es einen Custom MembershipProvider für unser SharePoint-Portal zu schreiben, der es ermöglicht, dass sich Benutzer gegen eine bestehende SQL-Datenbank authentifizieren. Damit hatte ich bislang schon viel Spaß. Das Erstellen des Custom MembershipProviders (Ableiten der abstrakten Klasse MembershipProvider aus dem Namensraum System.Web.Security und implementieren der entsprechenden Methoden) ist dabei weniger ein Problem, als ihn in einer SharePoint-Umgebung ins Laufen zu bekommen.

Den Custom MembershipProvider habe ich zunächst in einem normalen ASP.NET Projekt entwickelt und getestet. Hat alles gut geklappt. Nachdem ich ihn dann in die SharePoint-Umgebung eingebunden hatte kam es zu einer SqlException, die mir mitteilte, dass der Verbindungsaufbau fehlschlägt. Und zwar, weil der Benutzer nicht berechtigt ist auf die Datenbank zuzugreifen. Das Problem war damit recht schnell ermittelt: Um auf die Datenbank zuzugreifen hatte ich im ConnectionString “Integrated Security=True”, wodurch der Benutzerkontext des angemeldeten Benutzers zum Zugriff auf die Datenbank verwendet wird. In meiner Testumgebung wurde automatisch mein eigenes Benutzerkonto verwendet. Im SharePoint wurde aber der Benutzer IUSR_<MachineName> verwendet, der immer zum Einsatz kommt, wenn kein Benutzer an der Webanwendung angemeldet ist. Und dieser hat nun mal nicht die benötigten Rechte.

Es gibt zwei Lösungsansätze:

1. Das “Impersonating” der Webanwendung deaktivieren und den Benutzeraccount des ApplicationPools für den Zugriff auf die Datenbank konfigurieren:

<system.web>
  <identity impersonate="false" />
</system.web>

Aber wirklich sinnvoll ist das nicht, da dann dieses Feature allgemein nicht mehr zur Verfügung steht.

2. Den ConnectionString dahingehend abändern, dass nicht mehr die “Integrated Security” verwenden wird, sondern ein SQL-Benutzer.

<connectionStrings>
  <add name="MyConnectionString"
       connectionString="Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;"
       providerName="System.Data.SqlClient"
     />
</connectionStrings>

Dies erscheint die bessere Alternative zu sein.

Weblinks:

Microsoft Virtual PC 2007 SP1 und BitDefender 2009 (v12)

Ich habe mich gewundert. Ich habe mich sogar sehr gewundert. Da das Entwickeln für SharePoint nun mal sinnvoller Weise in einer virtuellen Maschine geschieht habe ich mir schon sehr früh im Verlauf meiner Diplomarbeit einen VPC mit Windows Server 2008, MOSS 2007 SP1 und entsprechenden Entwicklungstools aufgesetzt. An meinem Arbeitsplatz funktionierte alles wunderbar. Sogar die Soundkarte ließ sich nach anfänglichen Startschwierigkeiten in betrieb nehmen.

Alles könnte so schön sein. Wäre ich da nicht auf die blöde Idee gekommen auch zuhause arbeiten zu wollen. Also, VPC geschnappt und auf heimische Maschine kopiert, Settings angepasst, hochgefahren und… Oh. Kein Netzwerk. Nunja, kann ja sein, dass ich etwas vergessen habe einzustellen. Also, nochmal Settings überprüft. Geht nicht. Anderes netzwerkinterface (kabelgebunden) probiert. Geht nicht. Gegoogelt. Virtual Machine Network Services neu installiert. Geht nicht.

VirtualMachineNetworkServices

Was war dann das Ende vom Lied? Nach ewigem Suchen bin ich dann irgendwann auf die Idee gekommen mal die Firewall von Bitdefender zu deaktivieren. Und siehe da: es geht!

Also so wichtig mit ein geschütztes System auch ist und so zufrieden ich bislang mit BitDefender war, muss ich doch sagen dass er immer häufiger – vor allem was Netzwerk angeht – Probleme macht.