Freigeben über

Security in SharePoint Apps - Part 8

  • Artikel

PREVIOUS: Security in SharePoint Apps – Part 7

For this, the very last in the series, I just wanted to briefly talk at a high level about the process you should be doing when developing an App for a SharePoint site that uses SAML (or FBA for that matter). I’ve already written a detailed post on the “how” you develop an application for this scenario, I just want to cover the high level overview because I’ve seen some folks getting stuck trying to wrap their head around this and figure out how to even get started. So here are the basic steps when you need to build this out.

The first caveat here is I’m going to assume that you already have SharePoint up and running, and one or more web applications configured to use SAML authentication. Also…I strongly recommend that at least at first, you use both Windows and SAML authentication on the web site where you will be doing your development. It will greatly simplify the process while you are trying to get everything up and running. Now…knowing that, here’s how you can think about tackling this:

  • Phase 1 – A working SharePoint App. During this phase you’re going to create a new SPTrustedSecurityTokenIssuer, if you don’t already have one. That’s because in order to use Apps with SAML you must use high trust; low trust will not work. Once you have that in place you should create a new SharePoint App using the provider hosted option with high trust. At this point you should just hit F5 to validate that you can trust the App and the App security is configured correctly so that you can use CSOM to retrieve the web site title. NOTE: I have periodically experienced problems when trying to use Visual Studio to deploy an App to a SharePoint site that uses SAML. If that happens, you should use appregnew.aspx to create a client ID for your application, then hard-code that client ID into your AppManifest.xml and web.config files in your solution. You can get to appregnew.aspx in the _layouts directory; for example, if your site is at https://sps, then you would navigate to https://sps/_layouts/15/appregnew.aspx.
  • Phase 2 – A functional provider hosted app. What I mean by “functional” is that you should create an ASP.NET application that is going to be your provider hosted app. You should go through all of the steps necessary to configure it to use SAML authentication, including setting up a relying party for it in ADFS. You should be able to independently navigate to that ASP.NET site and successfully authenticate using SAML authentication before you ever try and integrate with SharePoint. Generally speaking you should find it easier to configure your provider hosted web to use SAML authentication if you use the Identity and Access tool for Visual Studio. You can download it from https://visualstudiogallery.msdn.microsoft.com/e21bf653-dfe1-4d81-b3d3-795cb104066e. Once this phase is completed, you should have a working SharePoint site, a working App, and a working ASP.NET site that will become your provider hosted app – it just isn’t hooked up to SharePoint yet.
  • Phase 3 – A working provider hosted app. At this point you’re going to hook up your ASP.NET app to SharePoint so you can use it to start making CSOM calls. I’ve actually already written a fairly detailed set of instructions about how you can take the web application that Visual Studio creates for you and port it over to a full blown ASP.NET app; look at this post for more details:  https://blogs.technet.com/b/speschka/archive/2013/06/12/converting-a-vs-net-web-for-a-provider-hosted-sharepoint-app-to-a-full-blown-web-or-console-application.aspx. Follow the guidance in there for getting your ASP.NET application hooked up as a provider hosted app. Then you can use my original post on building Apps for SharePoint sites that use SAML and FBA:  https://blogs.technet.com/b/speschka/archive/2012/12/07/using-sharepoint-apps-with-saml-and-fba-sites-in-sharepoint-2013.aspx. At this point you should have end-to-end connectivity, authorization and authentication and can access content in your SharePoint site.

With that, I’ll conclude this series. This topic is one that I expect will continue to rapidly evolve over the next few years because let’s face it – SharePoint Apps are really a v1 release, so they’re going to keep getting better and open up many new opportunities. I hope you find this series helpful as you build your SharePoint Apps and figure out how make the security model work for you.

Comments

  • Anonymous
    January 01, 2003
    thanks
  • Anonymous
    January 01, 2003
    thanks for sharing.
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    April 14, 2014
    Just wanted to thank you for your hard work and let you know someone is reading! I read every word of each section. And this article really needed to be written. As you point out, the documentation does not provide enough 'what this means' type of instructions.
  • Anonymous
    March 02, 2015
    I recently put together a session around security in SharePoint Apps. There seems to be enough content