In den meisten SharePoint-Projekten, die wir umsetzen, befinden sich nicht alle Daten in einem einzigen System. Oft kommen die Daten aus verschiedenen Datenbanken und aus unterschiedlichen Vorsystemen. Die Herausforderung besteht dann darin, die Daten auf sichere Art und Weise zu Übergeben und zur Verfügung zu stellen und dem entsprechenden Benutzer zu Visualisieren oder Anzuzeigen. Dafür benötigt man im SharePoint Umfeld meistens REST Endpunkte, die in der Kunden Azure Abo gehostet werden.
Wir setzen dafür oft Azure Functions ein, denn diese sind nicht nur äußerst kosteneffizient, sondern auch Serverless. So muss nur die App und keine Infrastruktur verwaltet werden. Um die Azure Function abzusichern, bedienen wir uns dem Azure Active Directory.
Im ersten Schritt muss überlegt werden, ob der API Endpunkt nur für einen Tenant (ein Office 365 Abo) gültig ist, oder für mehrere sein soll. In den meisten Fällen ist er nur für einen Tenant relevant, da selten Daten auf mehrere Unternehmen verteilt werden.
Im Azure Portal bei der Function APP gibt es unter „Platform Features“ die Einstellung „Authentication / Authorization“. Die App Service Authentication muss auf „On“ gestellt werden. Es wäre zwar möglich, das Service auch anonym zu verwendet, wie aber der Name schon sagt, ist es dann für alle zugänglich. Bei anonymem Zugriff wird vorausgesetzt, dass ein Code mitgeschickt wird. Dieser Code könnte aber von Benutzern einfach mittels Web Development Tools ausgelesen werden. Würde diese URL an firmenfremde Personen weitergeschickt werden, hätten diese Zugriff auf die Daten.
In einem SPFx Projekt gibt es das Verzeichnis „Conifg/package-solution.json“. Dort muss mitgeteilt werden, dass ein Endpunkt verwenden werden soll.
"webApiPermissionRequests": [
{
"resource": "custom-api",
"scope": "user_impersonation"
}
resource: ist der App Name oder die ID, die im nachfolgenden Bild rot eingerahmt ist.
scope: es wird nur der API Endpunkt abgesichert, reicht "user_impersonation"
Sobald die Solution gebaut ist und diese auch im App Catalog veröffentlicht wurde, muss die App noch im SharePoint Admin Center unter „API Management“ approved werden.
Für den Entwickler macht es kaum einen Unterschied im Aufwand, ob er einen abgesicherten oder einen anonymen Endpunkt verwendet. Statt dem HttpClient muss dieser nur einen AadHttpClient verwenden.
Hier sind zwei Möglichkeiten, wie dies zum Implementieren geht:
Vorinizialisiertes Object mittels „aadHttpClientFactory“ nützen...
this.context.aadHttpClientFactory.getClient('API ID').then((client: AadHttpClient): void => {
client.get('https://???.azurewebsites.net/api/xyz',AadHttpClient.configurations.v1)
.then( /*OK*/ , /*Error*/);
}, err => {alert('Error');}); });
... oder einfach einen neuen Client erstellen:
const client: AadHttpClient = new AadHttpClient(this.context.serviceScope, 'API ID');
client.get('https://????.azurewebsites.net/api/ xyz', AadHttpClient.configurations.v1)
.then(/*OK*/ , /*Error*/);
});
In unseren Augen gibt es keinen Grund, Sicherheit aus Bequemlichkeitsgründen einfach auszublenden. Office 365 ist weltweit verfügbar und sobald auch nur theoretisch ein User einen Datenendpunkt einfach auslesen kann, muss dieser auch entsprechend abgesichert sein, sodass zumindest nur User mit einem gültigen Login zu den Daten kommen. Die Berechtigungsstruktur muss immer noch implementiert werden, aber zumindest funktioniert die Datenweitergabe nicht einfach durch Weiterschicken der URL. Bitte bedenkt dies gleich am Start eines Projekt: Sicherheit zuerst! Später wird dies meistens nicht mehr gemacht.
