Provider-hosted Add-Ins mit Azure - spmoshpit.de · Strategie und Infrastruktur berücksichtigen Add-Ins App Catalog und Store Conscent Remote API‘s App Parts Web Sites SharePoint

Partner: Veranstalter:

Provider-hosted Add-Ins

mit Azure

Carsten Büttemeier

▪ Carsten Büttemeier

▪ Head of Development bei der deroso

Solutions GmbH

▪ Seit 2006 SharePoint Entwicklung und

Beratung

▪ http://www.spmoshpit.de

▪ Twitter: @spmoshpit

▪ XING, LinkedIn, …

Add-In

Model

On-premise

Office 365

Azure

als App

Host

App Service

Azure ACS

API Apps

SW

Archi-

tektur

Authentifizieung

Zugriff auf Daten

Dienste

Entwicklungs-

modelle

Tooling Demo in O365

Deployment Optionen für

Entwickler

Add-In Modelle und APIs

▪ Add-In Modell existiert seit 2012

▪ SharePoint-hosted vs. Provider-hosted vs. Autohosted

▪ Auch Farm Solution sind nach wie vor ein valides Modell

▪ „Das eine Immer-Richtig“ gibt es nicht

▪ Situativ bestimmen, welches Modell passt

▪ Strategie und Infrastruktur berücksichtigen

▪ Add-Ins

▪ App Catalog und Store

▪ Conscent

▪ Remote API‘s

▪ App Parts

▪ Web Sites

▪ SharePoint Framework

▪ OAuth

▪ Farm Solution

▪ WSP

▪ Feature Framework

▪ Web Parts

▪ Application Pages

▪ Full Trust

SharePoint Hosted Add-Ins Cloud Hosted Add-Ins

Add-In-Ressourcen liegen in SharePoint Unterwebsites

Nur clientseitiger Code möglich

App-Ressourcen auf Remoteserver

Remote-Web als Speicher

Nahezu jeder Code möglich

▪ SharePoint-hosted Add-Ins

JSOM

Auto Deployment

Inherited Context

Deklarative Elemente

REST

CSOM

Kompilierter Code

Event Receiver

Iteratives Deployment

Forms Authentication

▪ Provider-hosted Add-Ins

CSOM, REST & O365 API‘s

Iteratives Deployment

Kompilierter Code

Deklarative Elemente

Event Receiver

JSOM

Inherited Context

Auto Deployment

RequestDigest

Client Secret läuft ab

Grundsätzliches zu Provider-

hosted Add-Ins

▪ Authorisierungssysteme bei provider-hosted Add-Ins

▪ Ziel: Add-In soll als beliebiger Benutzer im Host agieren können

▪ Low-Trust

▪ Azure Control Service (ACS) als Trusted Token Issuer im OAuth2.0-Flow

▪ High-Trust

▪ Statt Token aus ACS wird ein digitales Zertifikat benutzt

▪ Cross-Domain Library

▪ Bibliothek zum Umgehen von Cross-Site-Scripting mit JavaScript

▪ Wird einzeln oder in Kombination mit Low-/High-Trust eingesetzt

▪ Visual Studio Template

▪ SharePointContext.cs

▪ TokenHelper.cs

▪ MVC Add-In

▪ FilterAttribute sorgt für

Context und Token

▪ Low-Trust und High-

Trust werden

abstrahiert

Speicherort der SharePoint-

Komponenten

Speicherort der

RemotekomponentenVertrauensbroker

Lokal In der Cloud ACS, Zertifikat

Lokal Lokal ACS, Zertifikat

Office 365 SharePoint-Website In der Cloud ACS

Office 365 SharePoint-Website Lokal ACS

▪ Zusammengefasst: Wann geht was?

▪ Permission Policies

▪ App + User Policy▪ Der Benutzer und das Add-In benötigen Berechtigung auf die Ressource

▪ Access denied Fehler tritt auf, wenn entweder der Benutzer oder die App keine Berechtigung hat

▪ App-only Policy▪ Nur das Add-In benötigt Berechtigung um auf eine Ressource zuzugreifen

▪ Erlaubt dem Add-In code, über die Berechtigungen des Benutzers hinaus zu elevaten.

▪ Nur supported für serverseitigen Code in cloud-hosted Add-Ins

▪ Lesetipp: https://blogs.msdn.microsoft.com/kaevans/2013/02/23/sharepoint-2013-app-only-policy-made-

easy/

▪ User policy – wird nicht benutzt

▪ Site App (Add-In?) Permissions

Tooling

▪ Visual Studio (2013)/2015/2017

▪ Cloud Explorer seit 2015, hilfreich für Debugging

▪ Visual Studio Code, beliebige andere IDEs

▪ Office SDK

▪ Templates mit TokenHelper.cs/vb und SharePointContext.cs/vb

▪ SPO Management Shell + MSO Services Sign-In Assistant

▪ Fiddler (Achtung mit VS 2017 und Zertifikaten!)

▪ Obligatorisches SharePoint Development Tooling

▪ Entwickler sollten kennen…

▪ Add-In Modell

▪ SharePoint Funktionen, Features, Limitationen und Best Practices

▪ SharePoint API‘s (JSOM, CSOM, REST, Graph, …)

▪ Eine oder mehrere Webentwicklungssprache(n) (JavaScript, C#,

Java, PHP, Python,…)

▪ Authentifizierungsgrundlagen (OAuth, Claims, High/Low-Trust)

▪ Azure Basics für App Services

▪ Anmeldung bei Visual Studio Essentials macht Sinn

▪ Das Toolkit ist

auch über

NuGet

verfügbar bei

bestehenden

Projekten.

Azure-hosted Add-Ins mit

Office 365

▪ Host Web des Add-Ins in Office 365

▪ Azure als Host für das Remote Web

▪ Hinzufügen über App Catalog oder Office Store

▪ Azure Access Control Service (ACS) für Authentifizierung

▪ Sideloading

▪ Schutz vor Schadcode durch Add-Ins

▪ Bei Nicht-Developer Sites (hinterher wieder ausschalten!):

[Microsoft.SharePoint.Client.ClientContext]$cc = New-Object Microsoft.SharePoint.Client.ClientContext($siteurl)

[Microsoft.SharePoint.Client.SharePointOnlineCredentials]$spocreds =

` New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $password)

$cc.Credentials = $spocreds

$sideLoadingEnabled = [Microsoft.SharePoint.Client.appcatalog]::IsAppSideloadingEnabled($cc);

$cc.ExecuteQuery()

[…]

$site = $cc.Site;

$sideLoadingGuid = new-object System.Guid "AE3A1339-61F5-4f8f-81A7-ABD2DA956A7D"

$site.Features.Add($sideLoadingGuid, $false, [Microsoft.SharePoint.Client.FeatureDefinitionScope]::None);

$cc.ExecuteQuery();

▪ Windows Azure ACS 2.0

▪ Identity Provider und Security Token Service

▪ Kann diverse externe Identity Provider nutzen

▪ Microsoft Account, Google, Facebook, ADFS2.0/3.0, Azure AD, …

▪ Keine weiteren Kosten

▪ Erfordert allerdings eine gültige Azure Subscription!

▪ App Registration

▪ ~siteURL/_layouts/

15/appregnew.aspx

▪ Generieren von

ClientId und Secret

▪ Registrieren im ACS

▪ App Lookup und Setzen von Berechtigungen

▪ ~siteURL/_layouts/15/appinv.aspx

▪ Für Nutzung ACS: Add-In Secrets laufen ab!

▪ Standard: Ein Jahr Gültigkeit

▪ Generieren und Einsetzen eines neuen Secrets:

https://msdn.microsoft.com/en-us/library/office/dn726681.aspx

Demo:

Azure-hosted Add-In

mit Office 365

OfflinedemoOnlinedemo

Azure-hosted Add-Ins

on-premise

▪ Host Web des Add-Ins in SharePoint 2013/2016 on-prem

▪ Azure als Host für das Remote Web

▪ Anbindung über App Catalog oder Office Store

▪ Authentifizierungsoptionen

▪ High-Trust

▪ On-Prem mit ACS verheiraten (Azure Subscription notwendig!)

▪ High Trust (!= Full Trust)

▪ Ziel: Add-In darf Aktionen als beliebiger Benutzer ausführen,

Verantwortung liegt bei ihm.

▪ Zertifikat statt Token über ACS

▪ Trusted Token Issuer wird in SharePoint konfiguriert

Falls es bereits einen registrierten SPTrustedSecurityTokenIssuer gibt, muss dieser entfernt werden

High-Trust per PowerShell konfigurieren – Trust Zertifikat über New-SPTrustedSecurityTokenIssuer

SSL/Nicht-SSL Verbindungen zwischen SharePoint Farm und Provider-hosted Add-Ins

konfigurieren per AllowOAuthOverHTTP

▪ In der PowerShell

▪ Root Zertifikat und Zertifikatobjekte erstellen

▪ SharePoint die Zertifikate als Root Authority bekannt machen

▪ New-SPTrustedRootAuthority –Name „RootCAHighTrustCert“-

Certificate $rootCertificate

▪ New-SPTrustedRootAuthority –Name „SharePointHighTrustCert“-

Certificate $certificate

▪ Das Zertifikat als Trusted Token Issuer registrieren

▪ https://msdn.microsoft.com/en-us/library/office/fp179901.aspx

▪ Add-In muss das Zertifikat in der web.config adressieren

▪ In Produktion Seriennummer des Zertifikats verwenden

▪ https://msdn.microsoft.com/de-de/library/office/jj945118.aspx

Bereitstellung von Add-Ins

▪ Deployment

▪ App Catalog

▪ Lokale Bereitstellung auf Farm ohne Office Store

▪ Low-trust und High-Trust Add-Ins möglich

▪ Office Store

▪ Bereitstellung durch Microsoft Service

▪ SharePoint-hosted Add-Ins

▪ Low-trust Add-Ins

▪ Achtung: Die prüfen wirklich! ☺

Optionen für Entwickler

▪ App Services bieten mehr

▪ API App

▪ Logic App

▪ Remote Event Receiver

▪ Azure Web Jobs

▪ Azure Functions

▪ Azure AD Apps

▪ Bereitstellung von Registerkarten in Microsoft Teams

FRAGEN?

Ich freue mich auf Ihr Feedback!

Partner: Veranstalter:

Vielen Dank![Speaker]