Building Apps for SharePoint 2013 by Andrew Connell - SPTechCon
•Download as PPTX, PDF•
3 likes•6,317 views
Andrew Connell presented on building apps for SharePoint 2013. He discussed the SharePoint app model and app identity. The app model supports apps hosted in Office 365 and on-premises farms. Apps communicate with SharePoint using web services and have their own identity and permissions. Authentication can occur through OAuth or high-trust authentication using server-to-server certificates. Apps can be installed at the site or tenant level and can integrate client-side or server-side code depending on if they are SharePoint-hosted, auto-hosted, or provider-hosted.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Building Apps for SharePoint 2013 by Andrew Connell - SPTechCon
Similar to Building Apps for SharePoint 2013 by Andrew Connell - SPTechCon (20)
More from SPTechCon
More from SPTechCon (20)
Building Apps for SharePoint 2013 by Andrew Connell - SPTechCon
- 1. Building Apps for SharePoint 2013 Andrew Connell MVP, SharePoint Server www.AndrewConnell.com @AndrewConnell
- 2. Andrew Connell www.AndrewConnell.com me@AndrewConnell.com @andrewconnell www.CriticalPathTraining.com www.Pluralsight.com
- 3. Agenda SharePoint App Model App Model Shapes App Identity Authentication Authorization OAuth www.AndrewConnell.com @AndrewConnell
- 4. SharePoint 2013 Deployment Options On-Premises • Installed 100% on company servers (aka: on-prem • Access to 100% of SharePoint’s features & / behind capabilities firewall) Hosted (aka: Office • Installed 100% and managed in the cloud • Most common context: Office 365 / 365 / SharePoint Online SharePoint • Some features not available in the cloud Online) www.AndrewConnell.com @AndrewConnell
- 5. Overview of the SharePoint App Model SharePoint app model based on these assumptions Apps supported in Office 365 and in on-premises farms App code never runs in SharePoint host environment Apps talk to SharePoint using Web service entry points App code is authenticated and has established identity App has permissions independent of user permissions Apps deployed to catalogs using a publishing scheme Published apps are easier to find, install and upgrade www.AndrewConnell.com @AndrewConnell
- 6. App Installation Scopes Site-Scoped Installation App is installed in a specific site App is launched from same site This site is known as host web Tenancy-Scoped Installation App installed > app catalog site App available many host webs Host webs access one app instance Centralizes app management www.AndrewConnell.com @AndrewConnell
- 7. 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 www.AndrewConnell.com @AndrewConnell
- 8. Creating SharePoint Hosted & Cloud-Hosted Apps www.AndrewConnell.com @AndrewConnell
- 9. App Web App web is created during app installation App web created as child to site where app is installed SharePoint-Hosted apps must create app web App must add start page and related resources App can add other SharePoint elements (e.g. lists) Cloud-Hosted apps can create app web Most cloud-hosted apps will not create an app web Cloud-hosted app can create app web if needed www.AndrewConnell.com @AndrewConnell
- 10. Inspecting the AppWeb www.AndrewConnell.com @AndrewConnell
- 11. App Shapes What SharePoint Tells you… SharePoint-Hosted Apps Cloud-Hosted Apps What Visual Studio Forces You to Select… SharePoint-Hosted App Provider-Hosted App Auto-Hosted App www.AndrewConnell.com @AndrewConnell
- 12. App Shapes – What It Really Is SharePoint-Hosted Apps Everything resides in SharePoint All Other Types Majority resides external to SharePoint (IIS, Azure, etc.) By default, don’t trigger creation of AppWeb… Unless they include SharePoint artifacts Auto-Hosted Apps SharePoint handles deployment of external assets Azure Web Site SQL Azure Database www.AndrewConnell.com @AndrewConnell
- 13. Inspecting App Shapes www.AndrewConnell.com @AndrewConnell
- 14. Authentication in SharePoint 2013 Authentication Flow in SharePoint 2013 User authentication stays the same with standard sites In calls to app web, app authentication occurs internally Internal authentication occurs in calls to app web External authentication used for calls from remote web Call context can contain both user and app identity Requirements for establishing app identity Host web application must be a claims-based Incoming calls must target CSOM/REST endpoints Supported CSOM/REST endpoints not extensible www.AndrewConnell.com @AndrewConnell
- 15. User vs. App Authentication Flow SharePoint Farm Web Servers SAML call from user token OAuth call from app token www.AndrewConnell.com @AndrewConnell
- 16. SharePoint 2013 Authentication Flow start authentication request to set up call context SAML Token? YES NO app web with user identity NO YES set up call context CSOM/REST user info OAuth token? YES YES YES with user identity endpoint? in token? and app identity NO NO set up call context with app identity NO set up call context end with no identity authentication (anonymous access) www.AndrewConnell.com @AndrewConnell
- 17. Provider-Hosted Apps & App Identity • Apps can obtain an identity using one of two methods: High-Trust (via OAuth (via S2S Trust & Azure ACS) certificates) www.AndrewConnell.com @AndrewConnell
- 18. OAuth 2.0 Primer What is OAuth? Internet protocol for creating and managing app identity A cross-platform mechanism for authenticating apps Internet standard used by Facebook, Google and Twitter SharePoint 2013 use OAuth to establish app identity SharePoint integration with OAuth based on Azure ACS OAuth authentication used in Office 365 but not on-premises farms www.AndrewConnell.com @AndrewConnell
- 19. Windows Azure ACS Windows Azure Access Control Service (ACS) Required to use OAuth with SharePoint 2013 ACS server acts as authentication server ACS server must be trusted by content server ACS server must be trusted by client app How is ACS configured as authentication server? It's configured automatically in Office 365 tenancies Not supported in on-prem farms in SharePoint 2013 www.AndrewConnell.com @AndrewConnell
- 20. What is a Server-to-Server (S2S) Trust Trusted connection between client app and SharePoint Eliminates need for ACS when running apps in on-premises farm 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) www.AndrewConnell.com @AndrewConnell
- 21. Developing Apps that use S2S Trusts What are the developer responsibilities with an S2S app? Expose an endpoint to SharePoint to discover service metadata Authenticate the user (can use Windows Auth, FBA, etc.) Create security tokens to send to SharePoint server Details of creating the S2S security token S2S token like OAuth token but differs from OAuth specification Security token must contain app identity Security token can optionally include user identity Security token must be signed using certificate’s private key www.AndrewConnell.com @AndrewConnell
- 22. OAuth & S2S Trusts OAuth Enabled Apps Before deployment marketplace, app must be registered with Azure ACS Apps obtain their identity / token from Azure ACS When calling SharePoint, app includes OAuth token SharePoint trusts Azure ACS On-Prem deployments will typically use S2S Before deployment, app must be registered with SharePoint Developer registers a certificate with SharePoint & associates app with certificate App creates token using private key of certificate SharePoint trusts this token because it was signed with the private key www.AndrewConnell.com @AndrewConnell
- 23. What You Might Not Be Aware Of: #1 OAuth is only supported in Office 365 No support in On-Prem deployments at RTM Why? Possible update to this story after RTM Extra steps? Hotfix? Cumulative Update? Service Pack? Next Version? www.AndrewConnell.com @AndrewConnell
- 24. Creating Apps with Identities & Permissions www.AndrewConnell.com @AndrewConnell
- 25. What You Might Not Be Aware Of: #2 Office 365 Azure != Windows Azure Office 365 Azure Windows Azure • “Private Cloud” • www.azure.com • Azure Web Sites • Cloud services • SQL Azure DBs • Web Sites • Access Control Service • Virtual Machines • Storage (blob / queue / table) • Service Bus • SQL Azure • Access Control Service •… www.AndrewConnell.com @AndrewConnell
- 26. The Sandbox Isn’t Dead Where you build sandbox solutions, try to replace them with SharePoint Apps There are many scenarios where Apps can’t replace sandbox solutions Some things are ONLY possible with sandboxed solutions in a hosted deployment Remember, they are deprecated, not dead! www.AndrewConnell.com @AndrewConnell
- 27. App Model Parting Thoughts SharePoint ALM has always been hard .NET ALM > SharePoint ALM More tools, more mature, more documentation & support No longer limited to what SharePoint supports Latest version of the .NET Framework New “toys” (MVC, Entity Framework, etc) Not limited to any technology stack / infrastructure Working with service layer vs. server side API More community tools & libraries to choose from Can follow more “standards” Don’t have to scale SharePoint, can now just scale the app www.AndrewConnell.com @AndrewConnell
- 28. Questions? Want to Learn More? www.CriticalPathTraining.com www.Pluralsight.com Hands-On & Virtual Training On-Demand Training SharePoint Courses for Everyone SharePoint Courses for Everyone SharePoint 2007, 2010 & 2013 SharePoint 2007, 2010 & 2013 Developers, Administrators & End Users Developers, Administrators & End Users Get Training How You Like it Individual, Small Business & Enterprise Plans Hands-On (classroom with hands-on labs) Monthly or Annual Subscriptions Online (live webcast with take-away labs) Watch Online & Offline Private Classes Available for Large Groups Subscribers Have Access to Entire Catalog www.AndrewConnell.com me@andrewconnell.com @AndrewConnell
Editor's Notes
- You should understand how authentication flow works in SharePoint 2013. In a regular site (one that is not an app web), user authentication is essentially unchanged from SharePoint 2010. However, calls to app webs are authenticated with both user identity and app identity. When an app is running remotely, the app passes a security token to the SharePoint Web server to establish its identity. When an app creates a security token to send to a SharePoint Web server, it usually also includes the identity of the current user. However, it is also possible for an app to create a security token that is app-only which means it does not contain information about a specific user.Keep in mind that there are a few requirements for authenticating SharePoint app identity. First, the hosting Web Application must be a claims-based Web Applications. Also, incoming calls must target CSOM/REST endpoints as you will see in the next slide. Note that the supported CSOM/REST endpoints cannot be extended with custom Web services in SharePoint 2013. You can only authenticate an app using CSOM/REST entry points that ship with SharePoint 2013.
- When SharePoint 2013 begins to authenticate an incoming request, it first looks to see if the incoming request contains a SAML token with a user identity. If the SharePoint 2013 authentication pipeline finds a SAML token, it can then assume that the incoming request was initiated by a user and not an app. Once it finds a SAML token, SharePoint 2013 then inspects the target URL of the incoming request to see whether it references a standard SharePoint site or a child site associated with a specific app (i.e. an AppWeb). If the incoming request targets a standard site, SharePoint 2013 conducts its authentication and authorization identically to how things worked in SharePoint 2010. If the incoming request targets an AppWeb, SharePoint 2013 initializes the call context with both a user identity and an app identity.When an incoming request does not contain a SAML token, SharePoint 2013 knows that a user did not initiate the request. In this scenario, the SharePoint 2013 authentication pipeline inspects the incoming request to see if it contains a security token identifying a provider-hosted app. The security token for an app can be created using OAuth when Office 365 and ACS is involved. If the security token for an app was created in a server-to-server (S2S) configuration, it will be similar to but slightly different from a valid OAuth token. Once SharePoint 2013 finds a security token identifying an app, it sets up call context with the app identity and optionally the user identity as well.
- OAuth is an Internet security protocol for authenticating apps and authorizing them to access content on behalf of a specific user. Microsoft selected OAuth for app authentication with SharePoint 2013 because it provides a cross-platform mechanism for authenticating and authorizing apps. It is also noteworthy that the OAuth protocol is an increasingly popular Internet standard which is already used by sites that support apps such as Facebook, Google and Twitter. Note that these sites and SharePoint 2013 use OAuth version 2.0 which is significantly different from OAuth version 1.0.The OAuth protocol allows a SharePoint 2013 to authenticate a cloud-hosted app which is calling to a SharePoint site from across the network and to establish an identity for the app in the calling context. This makes it possible for SharePoint to manage permissions and enforce access control for apps separately from users. Note that the OAuth protocol has provisions to track app permissions in addition to app identity. However, SharePoint 2013 uses OAuth only to authenticate apps and establish app identity. SharePoint 2013 does not leverage to OAuth protocol in any way to track or pass permissions. Instead, SharePoint tracks all app permissions in its own internal databases.
- Windows Azure Access Control Service (ACS) is a requirement for using the OAuth protocol with SharePoint 2013. The ACS server acts as authentication server. The SharePoint servers acting as the content servers must be configured to trust the ACS server. The client app must also be written to trust the ACS server as well. When you are using sites in an Office 365 tenancy, there is no need to configure a trust to ACS. That's because Office 365 and each new tenancy are preconfigured with trusts to the ACS authentication server. However, the same configuration is not done automatically performed for on-prem farms.
- SharePoint 2013 makes it possible for Web servers in a SharePoint farm to respond and accept requests from a client app using a server-to-server (S2S) trust. This type of configuration can be used when deploying provider-hosted apps in a private network when it is beneficial to avoid any dependencies on ACS or any other servers running across the Internet. That means that all the servers involved can run behind a single firewall and on the same local area network.A S2S trust represents a trusted connection between a client app running on a local app server and the Web servers in the SharePoint farm. Configuring the trust requires an SSL certificate which is based on the URL with the DNS name (e.g https://appserver.wingtip.com) where the client app is located. The client app contains code which has access to the private key associated with the SSL certificate and it uses this private key to sign security tokens. On the SharePoint Web Server, you must create a security token service which can use the public key to authenticate and decrypt these security tokens generated by the client app.
- There are several responsibilities for the developer when creating an S2S app. First, you must deploy the Web project that contains the implementation of the client app itself. Next, the client app must be configured to perform its own user authentication. This can be done using any supported style of authentication includingWindows Integrated Authentication, Basic Authentication,FBA, etc. Finally, the client app must create its own security tokens and sign them with the private key associated with the SSL certificate.Note that the security token created by a client app in the S2S trust scenario is like OAuth token but it differs from the OAuth specification in a few different ways. The security token created by a client app in an S2S trust must contain information that indicates the app identity. The security token created by a client app in an S2S trust usually contains information about the identity of the current user however this is not a requirement. Once the security token is created and contains the required information, it then must be signed with the private key before it is sent to SharePoint. This private key signing is what allows SharePoint to perform the authentication on calls originating from the client app.