OAuth und der aktivierte Benutzer in SharePoint 2013 – wie wird's gemacht, und was muss ich wissen?

Veröffentlichung des Originalartikels: 16.08.2012

Eines der Dinge, die mir beim Bloggen zu allen möglichen, mehr oder weniger schwierigen Fragen rund um das Arbeiten mit SharePoint gefallen, ist die Möglichkeit, vollkommen umgangssprachliche Formulierungen zu verwenden, wie z. B. im Titel dieses Beitrags. Etwas, das normalerweise verpönt ist, es sei denn, man entwickelt z. B. eine neue Version von SharePoint. Hat schon jemand die rührend menschlich anmutenden Meldungen in SharePoint 2013 gesehen? „Es tut mir leid, dass Sie warten müssen. Ich bin gleich fertig.“ (Sorry about the wait, I’m almost done) und ähnliches. Hmm ... je mehr sich die Dinge ändern, desto mehr bleiben sie sich gleich.

Aber zurück zum Thema. Ich habe oAuth bereits ein oder zwei Mal in diesem Blog erwähnt, als es um neue Features von SharePoint 2013 ging. In diesem Beitrag will ich zwar nicht voll in das Thema „was ist oAuth“ einsteigen, denn daran arbeitet bereits ein Team von Autoren, aber ich möchte einige Möglichkeiten beschreiben, wie sich oAuth nutzen lässt. Ein gutes Beispiel für Vertrauensstellungen bei oAuth ist ein SharePoint-Remoteindex für Suchvorgänge. Dieser ermöglicht, dass eine Person in einer Farm eine Abfrage senden kann, die an eine andere SharePoint-Farm weitergeleitet wird, und in dieser Remote-SharePoint-Farm kann die Identität des Benutzers rekonstruiert werden, damit Suchergebnisse ordnungsgemäß entsprechend den Sicherheitsregeln eingeschränkt werden können. oAuth-Vertrauensstellungen werden auch in anderen Szenarien verwendet, z. B. im neuen App-Modell (verfügt dieser Benutzer über die Rechte für den Zugriff auf den von der App angeforderten Inhalt?), zwischen Serveranwendungen wie SharePoint und Exchange (verfügt dieser Benutzer über Zugriffsrechte für den Postfachinhalt?) und in vielen anderen Szenarien. Mir scheint der SharePoint-Remoteindex dennoch ein gutes Beispiel zu sein, da sich daran sehr gut veranschaulichen lässt, warum wir bestimmte Aktionen ausführen müssen, um die erwarteten Ergebnisse zu erzielen.

Fangen wir also mit den Grundlagen an: Wie kann in FarmA eine Version von „Steve“ erstellt werden, die in FarmB als „Steve“ dargestellt wird? Nun, die Grundlage des Ganzen ist die Benutzerprofilanwendung. Angenommen, Steve befindet sich in FarmB und sendet eine Abfrage. Die Abfrage wird an FarmA gesendet, zusammen mit Attributen von Steve. Standardmäßig handelt es sich bei diesen Attributen um die SMTP-Adresse, die SIP-Adresse, den Kontonamen und den Namenbezeichner von Steve. Wenn FarmA die Anforderung empfängt, wird zunächst eine Suche in der lokalen Benutzerprofilanwendung ausgeführt. Dabei wird ein Profil gesucht, das mit den gesendeten Werten für Steve übereinstimmt. Darum ist es so wichtig sicherzustellen, dass die Benutzerprofilanwendung fehlerfrei ist und in SharePoint 2013 aufgefüllt wurde, und darum habe ich den folgenden Blogbeitrag zu diesem Thema verfasst: https://blogs.msdn.com/b/sharepoint_de/archive/2012/09/20/zuordnen-von-benutzerprofilen-f-252-r-saml-benutzer-durch-einen-ad-import-in-sharepoint-2013.aspx.

Nachdem also FarmA das Benutzerprofil „Steve“ gefunden hat, was kann sie damit anfangen? Ab hier lautet die Antwort „es kommt darauf an“, und darum ist die Planung dieses Aspekts Ihrer Organisation so wichtig. Worauf es ankommt, ist der von Ihnen verwendete Authentifizierungstyp, also einer der folgenden:

• Windows-Forderungen: Wenn Sie Windows-Forderungen verwenden, ist im Wesentlichen alles, was Sie benötigen, im Benutzerprofil enthalten. Es enthält den Kontonamen und die AD-Gruppenmitgliedschaften. Was „im Wesentlichen“ bedeutet, erkläre ich später. Die Kurzfassung lautet: Mit Windows-Forderungen sind Sie auf der sicheren Seite.
• Forderungen der formularbasierten Authentifizierung: wenn Sie FBA verwenden, müssen Sie einige Dinge beachten. Erstens benötigen Sie eine Methode, um die Benutzerprofilanwendung aufzufüllen und aktuell zu halten. Wenn Sie FBA mit einem LDAP-Anbieter und Windows Active Directory verwenden, haben Sie gute Karten. Sie können eine Profilverbindung mit Active Directory erstellen und sie dem FBA-Anbieter zuordnen, so wie ich es in dem Beitrag beschrieben habe, den Sie mit dem obigen Link aufrufen. In den meisten Fällen ist jedoch Ihr Anbieter nicht AD, sodass Sie benutzerdefinierten Code zum Auffüllen der Benutzerprofilanwendung schreiben müssen. Auf diese Weise greifen Sie auf das einzige Attribut zu, das für FBA-Benutzer eigentlich von Belang ist, und zwar der Kontoname. Wie Sie alle wissen, werden die restlichen Daten „zum Großteil“ (auch dies erläutere ich in Kürze) vom Rollenanbieter geliefert. Das Elegante bei diesem Authentifizierungstyp ist, dass beim Aktivieren eines FBA-Benutzers außerdem der zugeordnete Rollenanbieter aufgerufen wird, was auch geschieht, wenn der FBA-Benutzer lokal angemeldet ist. So erhalten wir alle Rollenforderungen für einen FBA-Benutzer.
• SAML-Forderungen: In diesem Szenario müssen Sie wie bei FBA zunächst die Benutzerprofilanwendung auffüllen. Wenn Sie Glück haben, sind die Benutzer in AD enthalten, und Sie können sie direkt importieren. Die entsprechende Vorgehensweise ist in dem oben verlinkten Blogbeitrag beschrieben. Wenn Sie weniger Glück haben, müssen Sie eine Methode finden, eine Verbindung mit dem Quellverzeichnis herzustellen und den Import direkt von dort durchzuführen. Das ist natürlich bei SAML-Forderungen am kompliziertesten, da möglicherweise mehrere Verzeichnisse vorliegen und Sie eventuell nicht einmal der Besitzer aller dieser Verzeichnisse sind (eventuell arbeiten Sie mit Partnern zusammen, nutzen ACS und verwenden Facebook oder einen anderen Anbieter usw.). Sei es, wie es wolle, wenn dies alles einwandfrei funktionieren soll, müssen Sie eine Möglichkeit zum Auffüllen der Benutzerprofilanwendung finden. Es gibt aber noch einen zweiten, wichtigeren Punkt: Wenn Sie sich als SAML-Benutzer anmelden, erhalten Sie eine Reihe von Forderungen von Ihrem Identitätsanbieter (IdP). Bei diesem Prozess der Benutzeraktivierung gibt es keine Möglichkeit, diese Anmeldung zu simulieren. So ist das eben bei SAML – Sie können beliebig oft umgeleitet werden und eine beliebige Anzahl von Authentifizierungsaufforderungen und Authentifizierungstypen (z. B. zweistufige Authentifizierung) bereitstellen, die niemals alle vorausgesehen und berücksichtigt werden können. Was bedeutet das also für Sie? Sie müssen die Forderungen per Forderungserweiterung hinzufügen, wenn Sie die Forderungen zum Schützen des Inhalts und Autorisieren des Zugriffs auf den Inhalt im Rahmen der Benutzeraktivierung verwenden möchten. Während der Aktivierung erhalten Sie keine Forderungen vom IdP, daher müssen Sie Forderungen ggf. lokal gewähren. Darauf bezieht sich das oben erwähnte „im Wesentlichen“, das ich jetzt erläutere.
• Was bedeutet „im Wesentlichen“? Nun, die Antwort auf die Frage sollte inzwischen klar sein – ob Sie Windows-Benutzer, FBA-Benutzer oder SAML-Benutzer sind, Sie können zusätzlich zu den Forderungen, die Sie vom Authentifizierungsanbieter erhalten, per Erweiterung weitere Forderungen hinzufügen; https://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx. Außerdem können wir während der Aktivierung alle registrierten benutzerdefinierten Forderungsanbieter aufrufen. Somit erhalten wir ggf. auch zusätzliche Forderungen für den aktivierten Benutzer, die der Benutzer empfangen würde, wenn er sich lokal anmelden und diese Anbieter aufrufen würde.

Darum verwende ich so gerne das Szenario „SharePoint-Remoteindex“, um die hier erforderliche Planung zu erläutern. Es lässt sich leicht vorstellen, dass Sie in einer Farm Rechte auf Inhalte basierend auf einer Windows-Gruppe, einer FBA-Rolle, einer SAML-Forderung oder einer beliebigen per Erweiterung hinzugefügten Forderung gewähren können. Wenn Sie diese Forderungen beim Abfragen von Inhalt nicht besitzen, wird der Inhalt aus Sicherheitsgründen eingeschränkt und nicht für Sie angezeigt. Dies zeigt, wie wichtig es ist, dass Sie jede Forderung, die Ihnen gewährt wird, wenn Sie sich lokal anmelden, auch erhalten, wenn eine Version von Ihnen aktiviert wird.

Damit all dies zu einer erfolgreichen Implementierung führt, ist sehr viel Planungsarbeit erforderlich. Ich hoffe, dass dieser Beitrag Ihnen hilft, die wichtigsten Aspekte zu bestimmen, damit Sie wissen, worauf Sie sich konzentrieren müssen.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know