SharePoint Apps for IT Pro

1. SharePoint Apps for IT Pro Michel Barneveld SharePoint Architect at Avanade @MichelBarneveld Michel.Barneveld@avanade.com

2. Dear Admin, please deploy this... • You get this from your developer:Dear Admin, please deploy the .app to sp.mbar.nl and the package to web.mbar.nl • And now?

3. Agenda What are Apps? Configure App support Server to Server (S2S) Trusts Conclusion

4. Do I need Apps? • Why can updates be difficult? • Why can upgrades be difficult? • What causes (most?) support issues? Customizations! Developers are EVIL!

5. Apps are good  • Apps allow customizations to be offloaded from SharePoint • Increased stability • Lower upgrade/update costs • Shorter upgrade/update timeframes More reasons?See: http://www.youtube.com/watch?v=7Sf0-g0EbZw SharePoint 2013 App Model – VesaJuvonen

6. What is an App? • Essentially a web application • Written in HTML, JavaScript, PHP, .NET, etc. • Hosted on SharePoint or ‘Cloud’ (azure, on-premises webserver, etc.) • Communicates and integrates with SharePoint using REST or SharePoint Client API (javascript, .Net) • Offloading custom server code from SharePoint

7. User experience options • Full page • App Part (iframe) • UI Custom Actions (menu extensions)

8. App Hosting • SharePoint hosted • Autohosted • Provider-hosted This presentation

9. SharePoint App Architecture • SharePoint-Hosted Apps • App resources added to SharePoint host • Stored in child site known as app web • App can have client-side code • App cannot have server-side code • Cloud-Hosted Apps • App resources deployed on remote server • Remote site known as remote web • App can have client-side code • App can have server-side code

10. App Package • File with a “.app” extension (add .zip to open it) • Contains items like appmanifest.xml, SharePoint solutions, Host web Features with custom actions, App Parts, .resx files, web deploy packages, etc. • Appmanifest.xml contains name, id, required permissions, location, etc. for the app

11. Authentication & Authorization • SP2013 now supports authentication and authorization for Apps • Required permissions for App in appmanifest.xml or requested on the fly • Not set using normal SharePoint permissions • More controls to elevate permissions for user(compared to full trust solution using SPSecurity.RunWithElevatedPriviledges full control on web app!)

12. Agenda What are Apps? Configure App support Server to Server (S2S) Trusts Conclusion

13. SharePoint vs Provider Hosted • SharePoint hosted • SharePoint Services • Service Applications • App domain • No Remote Web! • Provider Hosted • SharePoint Services • Service Applications • App domain (optional!) • Remote Web

14. Services needed • Start the Subscription Settings and App Management services

15. Service Applications • Create a Subscription Settings service application using powershell$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName <SettingsServiceDB> • Create a App Management service application using powershell or central admin

16. Site Collections and App Catalog • Use Host Named Site Collections (HNSC)! • Create HNSC for your intranet (sp.mbar.nl) • New-SPSite"https://sp.mbar.nl" -OwnerAlias "SP\sp_install" -HostHeaderWebApplication $wa -Name "Intranet" –Template "STS#0“ • Create HNSC for you App Catalog • New-SPManagedPath-RelativeURL "apps" -HostHeader –Explicit • New-SPSite "https://sp.mbar.nl/apps" -OwnerAlias “SP\sp_install" -HostHeaderWebApplication $wa -Name "Application Catalog" -Template “APPCATALOG#0” • Make sure the web application has a root site collection! • Reference: http://www.sharepointblues.com/2012/11/22/configurin-sharepoint-2013-host-named-site-collections-and-apps-host/

17. Prerequisites App domain • separate domain for apps • e.g. mbar-apps.nl for apps and sp.mbar.nl for intranet • Wildcard SSL certificate for app domain • Wildcard dns CNAME alias to SharePoint(*.mbar-apps.nl  sp.mbar.nl)

18. Configure app url • Configure App Catalog url in CA • Configure app url in CA or using powershell • Set-SPAppDomain<appDomain>Set-SPAppSiteSubscriptionName -Name "app" -Confirm:$false

19. Deploy Remote Web Application For Visual Studio projects: • Read the readme file? ;-) • Configure deployment settings in: <name>.SetParameters.xml • Execute <name>.deploy.cmd • Has a dependency on msdeploy.exe (Web Deploy: http://go.microsoft.com/?linkid=9278654 )

20. Deploy .App file • Add .app to App Catalog • Add app to Site Collection • Url of Remote web is located in AppManifest.xml in .app file!

21. Technet article Configure an environment for apps for SharePoint (SharePoint 2013)http://technet.microsoft.com/en-us/library/fp161236.aspx

22. Agenda What are Apps? Configure App support Server to Server (S2S) Trusts Conclusion

23. Scenario Remote app calls SharePoint on behalf of App or User Requires a Server to Server Trust (S2S) On-premises Farm SharePoint Web Server S2S STS 1 User 3 4 2 Client App SSL Cert Public/Private key pair (.pfx)

24. What is a S2S Trust? • Trusted connection between app and SharePoint • “oAuthand ACS*” for on-premises farms • Trust between servers configured using SSL certificates • App code requires access to private key of SSL certificate • Requires creating Security Token Service on SharePoint server(s) *) Access Control Services

25. S2S Trust Architecture • App has x.509 certificate with public/private key pair • Private key used to sign certain aspects in access token • Public key registered with SharePoint farm • This creates a trusted security token issuer • App creates access token to call into SharePoint • App creates access token with a specific client ID and signs it with private key • Trusted security token issuer validates signature • SharePoint establishes app identity • App identity maps to a specific client ID • You can have many client IDs associated with a single x.509 certificate

26. Remote Web

27. Why is it called a “High Trust” App • App must authenticate the user (!) • App provides user identity to SharePoint • SharePoint farm trusts that the app is telling the truth about user identity • “High Trust” is very different from “Full Trust” • Full trust code is not limited by permissions – it can do anything it wants • High trust app has set of permissions that say what it can do

28. Examples of S2S trust applications • Exchange 2013 • Workflow Manager 1.0 • Your Custom SharePoint Apps or Web Applications (non-SharePoint)

29. Configuring a S2S Trust • Steps to configure an S2S trust • Create an x509 certificate including private and public key • Export public key from above certificate for SharePoint • Use PowerShell to create a trusted security token issuer based on public key on SharePoint • Register App Principal on SharePoint • Deployed Remote Web App • Configure location for private key file in web.config

30. Certificate • Create certificate using makecert or use IIS for it. • .pfx file that includes the private key with password • .cer file with only the public key • Certificate must be trusted by SharePoint and Remote Web Server • S2S certificate ≠ SSL certificate for webserver (but can be the same certificate) • S2S certificate can be self signed or from existing CA

31. Creating the Secure Token Issuer • Steps to creating security token issuer in SharePoint farm (1 per certificate) • Get the authentication realm (aka tenancy) • Create realm-qualified app identifier • Create certificate object using .cerfile (public key) • Call New-SPTrustedSecurityTokenIssuer

32. Creating the App Principal • Can be done several different ways • Use built-in page named AppRegNew.aspx • Use Register-SPAppPrincipal • Use SPAppPrincipalManager • Let Visual Studio do it for you when developing

33. Using SPAppPrincipalManager

34. IssuerIDvsClientID • IssuerID • Used to create Secure Token Issuer in SharePoint • Used by remote web app (e.g. configured in web.config)

35. IssuerIDvsClientID • ClientID(aka App ID) • Used to create App Principal • Used by remote web app (e.g. configured in web.config) • Configured in appmanifest.xml

36. Quick Recap • App model is good (remember: developers are evil!) • App domain mandatory for SharePoint hosted, optional for Provider Hosted • Use Host Named Site Collections • Use SSL (HTTPS) for SharePoint and Remote Web • Configure S2S trusts if Remote Web App needs to call into SharePoint • Use dedicated certificate for Apps (but can be limited to 1 certificate per group of apps) • Register a certificate (Secure Token Issuer) only once in SharePoint! • Keep your private key private • Location of Remote Web App is in AppManifest.xml in .app file (OTAP?) • ClientID/AppID usually provided by Developer, IssuerID by SharePoint Admin

37. Questions?