Building Apps for SharePoint 2013 by Andrew Connell - SPTechCon

Editor's Notes

• #5: 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.
• #6: 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.
• #7: 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.
• #8: 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.
• #9: 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.
• #10: 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.