SharePoint Provider Hosted Apps - Requirements und Vorteile

21. April 2015
SharePoint 2013 Provider Hosted Apps

Warum überhaupt Provider Hosted Apps?

SharePoint bietet sehr viele REST API's an, um Daten abzugreifen. Wenn man zum Beispiel in einer externen Anwendung Informationen aus SharePoint anzeigen möchte, geht man davon aus, dass die REST API's dazu genutzt werden können. Leider kommt man dort schnell an den Punkt an dem der Browser eine Fehlermeldung anzeigt, dass Cross Origin Resource Sharing nicht möglich ist. Selbst wenn nur die Subdomain anders ist, ist es nicht möglich Daten aus dem SharePoint abzugreifen. Das kommt daher, dass SharePoint standardmäßig keine CORS Header bei REST Requests mitsendet. Somit ist klar, dass die SharePoint REST API's nur zu SharePoint internen Verwendunszwecken genutzt werden können. Die Alternative, um doch die API's auf externen Systemen aufrufen zu können, bieten Provider Hosted Apps. Diese haben genau den Zweck, SharePoint Daten auf System anzeigen zu können, die nicht direkt auf dem SharePoint Server liegen.

Was sind Provider Hosted Apps?

Provider Hosted Apps werden auf einem externen Webserver (meist IIS) gehosted. Wird ein neues Provider Hosted App Projekt im Visual Studio generiert, werden automatisch zwei Projekte erstellt. Zum einen die App, welche im SharePoint deployed wird und zum anderen eine vorkonfigurierte IIS Site, die in einen bestehenden IIS Server integriert werden kann. Das Projekt mit der IIS Site bringt schon verschiedene Klassen mit, die für die Authentifizierung des Nutzers benötigt werden. Auf diese werde ich später eingehen. Provider Hosted Apps können sowohl in Office 365 sowie in OnPremise Tenants deployed werden. Allerdings sind die Implementierungen für die Authentifizierung bei Office 365 und OnPremise unterschiedlich.

Was ist der Unterschied zu SharePoint Hosted Apps?

Der Unterschied zu den SharePoint Hosted Apps ist, dass man die komplette Applikationslogik auf einem externen Server auslagert. Dies bringt verschiedene Vorteile, aber auch Nachteile, wobei die Vorteile in dem Fall überwiegen.

Vorteile:

  • Da die komplette Applikationslogik auf einem anderen Server implementiert wird, hat man bei Anpassungen der Applikation nur die Sourcen auf dem externen System zu aktualisieren und die Nutzer der App bekommen automatisch die aktuellste Version und müssen nicht wie bei den SharePoint Hosted Apps die App über den Office 365 App Store updaten
  • Ein weiterer Vorteil ist, dass die Applikation in jeder beliebigen Sprache implementiert werden kann. Es muss nur die Authentifizierung des Nutzers sichergestellt werden, sodass der Access Token für den Nutzer erstellt werden kann
  • Für .NET Web Applikationen sind die Klassen für die Token Generierung bereits generiert, wenn ein neues Projekt erstellt wird

Nachteile:

  • Die Applikationslogik muss auf einem externen System gehosted werden
  • Wenn die Applikation in einer anderen Programmiersprache geschrieben wird, muss die Authentifizierungslogik nachimplementiert werden

Wenn eine Provider Hosted App im SharePoint deployed wird, stellt diese lediglich eine Weiterleitung an den konfigurierten externen Server dar. Analog zu einer SharePoint Hosted App werden bei der Provider Hosted App die gleichen App spezifischen Berechtigungen festgelegt.

Welche Voraussetzungen haben Provider Hosted Apps

Wenn die App in einem Office 365 Tenant deployed wird, bestehen keine weiteren Voraussetzungen, da diese dort alle geschaffen sind. Anders sieht es da bei einem OnPremise Sharepoint aus. Um dort Provider Hosted Apps zu nutzen, müssen verschiedene Anforderungen erfüllt sein:

  • Eine Funktionierende App Domain (Wie die App Domain richtig eingerichtet wird, könnt ihr im Blog Post von Toni lesen)
  • Im User Profile Service müssen alle Nutzer hinterlegt sein, die die Applikation nutzen, damit die Authentifizierung klappt.
  • Für die Web Applikation, in der die Provider Hosted App eingespielt wird, muss zwingend "Claims-based Authentication" als Authentifizierungsprovider hinterlegt sein
  • Das .pfx Zertifikat des SharePoints muss exportiert werden
  • Die Web Applikation muss für Produktiv-Szenarien mit HTTPS versehen sein

Wie funktioniert die Authentifizierung

Die mitgelieferte "TokenHelper" Klasse wird dazu genutzt, um einen Access Token für den aktuellen Nutzer zu generieren. Dazu wird vorher in der IIS Site die "Windows Authentication" angeschaltet.

Die TokenHelper Klasse erstellt einen Token auf Basis des aktuellen Usernamen, der trusted AppId, die vorher auf der SiteCollection hinzugefügt wurde, einem Start und einem Expire Timestamp und verschiedenen SharePoint-internen Werten. Danach wird der generierte Token mittels JWT und dem exportierten SharePoint Zertifikat verschlüsselt.

Nachdem der Token erstellt und signiert ist, können Requests gegen die SharePoint API gestellt werden. Wenn SharePoint den Request empfängt, wird der Token mit dem Zertifikat wieder entschlüsselt und in seine Bestandteile zerlegt. Nach dem Zerlegen wird von SharePoint der zu impersonierende Nutzer geprüft, ob dieser im User Profile Service verfügbar ist, ob die mitgesendete AppID existiert sowie getrustet ist und zuletzt, ob die AppID überhaupt die Rechte besitzt den angeforderten Vorgang auszuführen.

Der komplette Authenfizierungs-Ablauf wurde von Microsoft in einem Anschauungsbild dargestellt:

S2S Auth Flow

Wie kann QuePort AppHero dort unterstützen

Mit QuePort AppHero wird die komplette Authentifizierungslogik schon mitgeliefert, sodass man in alle externen webbasierten Portale eine Authentifizierung gegen das eigene OnPremise SharePoint oder gegen Office 365 vollziehen kann, um dort Inhalte darzustellen. AppHero ist ein sehr schmaler API Server, mit dem man sowohl serverseitig als auch frontendseitig mit JavaScript arbeitet. Für weitere Informationen können Sie uns gerne kontaktieren.

Neuen Kommentar schreiben