Access share point-2013-data-with-provider-hosted-apps
•Download as PPTX, PDF•
1 like•2,353 views
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Access share point-2013-data-with-provider-hosted-apps
Similar to Access share point-2013-data-with-provider-hosted-apps (20)
More from Alexander Meijers
More from Alexander Meijers (20)
Recently uploaded
Recently uploaded (20)
Access share point-2013-data-with-provider-hosted-apps
- 2. Access SharePoint 2013 data with Provider-hosted apps on-premise
- 3. Agenda • Introduction to apps • SharePoint app authentication • Create our first out-of-the-box app (d) • Configure an on-premise environment (d) • Build our app on-premise (d)
- 4. • Introduction to apps • SharePoint app authentication • Create our first out-of-the-box app (d) • Configure an on-premise environment (d) • Build our app on-premise (d)
- 5. What are apps? • Apps are self-contained pieces of functionality that extend the capabilities of the SharePoint platform. • Also called the “Cloud App Model” • Representation – Immersive Full Page – Part – UI Custom action
- 6. Type of Apps Provider-Hosted App On- Use your own server hosting SharePoint premise architecture Web SharePoint Cloud-based Apps The app runs in a separate host Or as a service Autohosted App Windows Azure + SQL Azure SharePoint Azure provisioned inivisibly as Web apps are installed SharePoint-Hosted App Parent Creation of isolated sub web on a parent web Web Contains only web elements Examples are lists, out-of-the box Web Parts (Host) No server code allowed, only client JavaScript for logic and UX App Web
- 7. Provider-hosted Apps • A provider-hosted app is a SharePoint app which business logic runs in a hosted location in the cloud or on-premise. • Consists of: – An app for SharePoint – A separate web application or service running at a host
- 8. Advantages – Custom business logic moves up into the cloud or down to a client machine – No danger of installing custom SharePoint extensions – Easier in future upgrades – Extend SharePoint Online websites as on- premise SharePoint websites. – Easy for users at purchase and installation
- 9. • Introduction to apps • SharePoint app authentication • Create our first out-of-the-box app (d) • Configure an on-premise environment (d) • Build our app on-premise (d)
- 10. OAuth Authorization and authentication 7 STS (ACS) 3 6 2 4 8 Page 1 9 SharePoint Server 5 10 Contoso.co Browser m
- 11. App permissions • The app requests permissions from the user during installation – Defined in the manifest.xml – User must grant all requests or nothing
- 12. App permissions Level Scope URI Rights Site http://sharepoint/content/sitecollection Read, Write, collection Manage and Website http://sharepoint/content/sitecollection/web FullControl List http://sharepoint/content/sitecollection/web/list Tenancy http://sharepoint/content/tenant • The permission request for that “right” and to the “level” where the app is installed • For other SharePoint features request scopes are available – e.g. http://sharepoint/bc/connection
- 13. • Introduction to apps • SharePoint app authentication • Create our first out-of-the-box app (d) • Configure an on-premise environment (d) • Build our app on-premise (d)
- 14. What you need • Tooling – Visual Studio 2012 – Microsoft Office Developer Tools for Visual Studio 2012 • Visual Studio (F5) will create a temporarily website for the app web
- 15. Demo - Create our first out-of-the- box app • Creation of Provider-hosted app out-of-the- box connected with SharePoint Online – Authentication works with OAuth without any actions taken – Access token present • Connected the app with on-premise SharePoint – No access token present – Not a trust defined with the SharePoint environment
- 16. • Introduction to apps • SharePoint app authentication • Create our first out-of-the-box app (d) • Configure an on-premise environment (d) • Build our app on-premise (d)
- 17. Registering Apps • A remote app must have an app identity when interacting with SharePoint 2013 using OAuth. • Registering – Visual Studio 2012 (temporarily) App Identity – Through Seller dashboard Client Id – Using appregnew.aspx Display Name – Office 365 PowerShell cmdlet App domain – Autohosting
- 18. Server-to-server authentication (high trust) • High trust app is a provider-hosted app for use on- premises • High trust is not the same as full trust • It allows servers that support server-to-server authentication to access and request resources from another server on behalf of an user identity. – The app is responsible for creating the user portion of the access token • Server-to-server security token service (STS) provides access tokens for server-to-server • You will need to configure SSL – Or overrule with AllowOAuthOverHttp = $true
- 19. Server-to-server authentication (high trust) • Create a trust between a server-to-server principal – New-SPTrustedSecurityTokenIssuer – Parameters;-Certificate, -RegisteredIssuerName* • Register an app principal for on-premise – Register-SPAppPrincipal – Parameters; -Site, -NameIdentifier* * [appId]@[authentication realm]
- 20. Demo - Configure an on-premise environment • Configured service applications – Application Management Service Application • App Domain • App site subscription name – Subscription Settings Service Application – User Profile Service Application • Disable the app principle access token check • Create certificates • Generate a client id • Create a trusted security token service • Updating the project – Configuration of web.config – Manifest.xml – Permissions – Replace code in call for client context
- 21. • Introduction to apps • SharePoint app authentication • Create our first out-of-the-box app (d) • Configure an on-premise environment (d) • Build our app on-premise (d)
- 22. CSOM • CSOM = SharePoint Client Object Model • Several forms – .NET Framework redistributable assemblies – JavaScript library – REST/ODATA endpoints – Windows Phone assemblies – Silverlight redistributable assemblies
- 23. Access SharePoint data • Data Access done through server-side code using CSOM • ClientContext used – ClientContext.Web – ClientContext.Web.Lists • Creation objects – ListCreationInformation
- 24. Demo 3 • Added Html for the controls • Defined several methods for the application tasks – GetAllLists() – CreateList() – DeleteList() • Changed the permission request level for Scope=Web to “FullControl”
- 25. Questions?
Editor's Notes
- http://msdn.microsoft.com/en-us/library/jj163230(v=office.15).aspxhttp://msdn.microsoft.com/en-us/library/fp179922(v=office.15).aspxImportantSharePoint sandboxed solutions are deprecated in SharePoint 2013
- http://msdn.microsoft.com/en-us/library/fp179930(v=office.15).aspx
- http://msdn.microsoft.com/en-us/library/fp142381(v=office.15).aspx
- 4minhttp://msdn.microsoft.com/en-us/library/fp142382(v=office.15).aspxA user types a URL in a browser to go to a SharePoint page where a particular app is installed. In this case, the app is a Contoso.com app and the user interface element on the SharePoint page comes from the Contoso.com app.Note If the user is not already logged on, SharePoint 2013 prompts the user to log on.2. SharePoint processes the page and detects that there is a component from the Contoso.com app on the page. SharePoint must get a context token that it can send to the Contoso.com app. SharePoint asks ACS to create and sign a context token that contains context information (for example, the current user, what web is being rendered on SharePoint, and other context information) and an authorization code. This context token can be used later by Contoso.com to request an access token from ACS. The Contoso.com server can use the access token to talk back to SharePoint if the Contoso.com app wants to make a web service call to SharePoint later.Note The security token service (STS), ACS in this scenario, is configured and provisioned by SharePoint 2013. The ACS is the tenant in the cloud that does the OAuth authentication. You do not have to configure it. 3. ACS returns the signed context token to SharePoint. The signed context token is signed with an client secret that only ACS and the Contoso.com app share.Note The developer of the Contoso.com app receives the client secret value when the developer registers the app at the Seller Dashboard. 4. SharePoint renders the page, including an IFRAME pointing to the app host server—in this case, Contoso.com. When SharePoint renders the page, it also passes the context token to the IFRAME.5. The IFRAME causes the browser to request a page from the Contoso.com server. The context token is included in the browser request that is sent to the Contoso.com server.6. The Contoso.com server gets the context token. Contoso.com validates the signature on the context token. The token is signed with an client secret that only Contoso.com and ACS share. Contoso.com can validate that the token is really intended for it and that it is not a random request from some random server. It knows that it is part of a SharePoint request. If the Contoso.com server wants to talk back to SharePoint, there is a refresh token in the context token that Contoso.com can extract, so that it can include that information in the request to ACS for an access token. Contoso.com uses the refresh token that it extracted from the context token, the context token that it got from SharePoint, and its credentials (which are its client Id value and its client secret value) to request an access token from ACS so that it can talk back to SharePoint. Note The developer of the Contoso.com app receives the client Id value when the developer registers the app at the Seller Dashboard. 7. ACS returns an access token to the Contoso.com server. Contoso.com can cache this access token. That way, the Contoso.com server doesn't have to ask ACS for an access token every time that it talks back to SharePoint. (Or, Contoso.com can make an access token request every time and not cache the access token.)By default, access tokens are good for a few hours at a time. Each access token is specific to the user account that is specified in the original request for authorization, and grants access only to the services that are specified in that request. Your app should store the access token securely, because it is required for all access to a user's data. For more information about access tokens, see Authorization and authentication for apps in SharePoint 2013.Note Access tokens are not as long-lived as refresh tokens. By default, refresh tokens are good for about a year. So, the same refresh token can be redeemed for a new access token from ACS for about a year. 8. Contoso.com can use the access token to make a web service call or CSOM request to SharePoint, passing the OAuth access token in the HTTP Authorization header.Note Currently, sample code is provided. The sample code is also included in Visual Studio 2012. In the future, the access token value will be written into the OAuth Authorization field in the HTTP header automatically, via the SharePoint OAuth API calls that the Contoso.com app code makes.9.SharePoint returns the information that Contoso.com requested to Contoso.com.10.The Contoso.com app renders the IFRAME contents as a per-user request in step 1. This completes the OAuth transaction process. The user now sees the SharePoint page fully rendered.Tips and FAQs: OAuth and remote apps for SharePoint 2013http://msdn.microsoft.com/en-us/library/fp179932(v=office.15).aspx
- http://msdn.microsoft.com/en-us/library/fp142383(v=office.15).aspxWindows Azure Access Control Service (SP Online)Server To Server Security Token Service (SP)Microsoft Online Directory Service
- http://msdn.microsoft.com/en-us/library/fp142383(v=office.15).aspxAn app for SharePoint has its own identity and is associated with a security principal, called an app principal. Like users and groups, an app principal has certain permissions and rights. The app principal has full control rights to the app web so it only needs to request permissions to SharePoint resources in the host web or other locations outside the app web
- http://msdn.microsoft.com/en-us/library/fp142381(v=office.15).aspx
- Current time:12minDemo 1 present provider-hosted app with onlineDemo 2 present same with on-premise (should get an error)
- Current time:24min
- http://msdn.microsoft.com/en-us/library/jj687469(v=office.15).aspxFor a remote app to be able to interact with SharePoint 2013 using OAuth, an app must first have an app identity. An app identity includes the following basic information:Client Id of the appDisplay name of the appApp domain where the remote app is hostedDevelopers can get an app identity for their app by registering their app. When you register your app, your app gets a client Id, client secret, display name, and app domain. In some cases, it also gets a redirect URI associated with it.
- Configure server-to-server authentication between SharePoint 2013 farmshttp://technet.microsoft.com/en-us/library/jj655400(v=office.15).aspxServer-to-server authentication allows for servers that are capable of server-to-server authentication to access and request resources from one another on behalf of users. Servers that are capable of server-to-server authentication run SharePoint 2013, Exchange Server 2013, Lync Server 2013, Azure Workflow Service, or other software that supports the Microsoft server-to-server protocol. Server-to-server authentication enables a new set of functionality and scenarios, such as What's new in eDiscovery in SharePoint Server 2013, that can be achieved through cross-server resource sharing and access.To provide the requested resources from another server that can perform server-to-server authentication, the server that runs SharePoint 2013 must do the following:Verify that the requesting server is trusted. To authenticate the requesting server, you must configure the server that runs SharePoint 2013 to trust the server that is sending it requests. This is a one-way trust relationship.Verify that the type of access that the server is requesting is authorized. To authorize the access, you must configure the server that runs SharePoint 2013 for the appropriate set of permissions for the requested resources.Note that the server-to-server authentication protocol in SharePoint 2013 is separate from user authentication and is not used as a sign-in authentication protocol by SharePoint users. The server-to-server authentication protocol, which uses the Open Authorization (OAuth) 2.0 protocol, does not add to the set of user sign-on protocols, such as WS-Federation. There are no new user authentication protocols in SharePoint 2013. The server-to-server authentication protocol does not appear in the list of identity providers. Multiple farmsYou will need to configure a trust relationship with another farmUsing the same certificate requires to have the same name identifier of the SharePoint Security Token Service (STS) across the farms
- Configure server-to-server authentication between SharePoint 2013 farmshttp://technet.microsoft.com/en-us/library/jj655400(v=office.15).aspxServer-to-server authentication allows for servers that are capable of server-to-server authentication to access and request resources from one another on behalf of users. Servers that are capable of server-to-server authentication run SharePoint 2013, Exchange Server 2013, Lync Server 2013, Azure Workflow Service, or other software that supports the Microsoft server-to-server protocol. Server-to-server authentication enables a new set of functionality and scenarios, such as What's new in eDiscovery in SharePoint Server 2013, that can be achieved through cross-server resource sharing and access.To provide the requested resources from another server that can perform server-to-server authentication, the server that runs SharePoint 2013 must do the following:Verify that the requesting server is trusted. To authenticate the requesting server, you must configure the server that runs SharePoint 2013 to trust the server that is sending it requests. This is a one-way trust relationship.Verify that the type of access that the server is requesting is authorized. To authorize the access, you must configure the server that runs SharePoint 2013 for the appropriate set of permissions for the requested resources.Note that the server-to-server authentication protocol in SharePoint 2013 is separate from user authentication and is not used as a sign-in authentication protocol by SharePoint users. The server-to-server authentication protocol, which uses the Open Authorization (OAuth) 2.0 protocol, does not add to the set of user sign-on protocols, such as WS-Federation. There are no new user authentication protocols in SharePoint 2013. The server-to-server authentication protocol does not appear in the list of identity providers. Multiple farmsYou will need to configure a trust relationship with another farmUsing the same certificate requires to have the same name identifier of the SharePoint Security Token Service (STS) across the farms
- Current time:30min
- Current time:40min
- http://msdn.microsoft.com/en-us/library/fp179912.aspx
- Current time:45min
- Current time:55min