SharePoint Hosting & Authentication Options for LightSwitch (Brian Moore)

SharePoint Hosting & Authentication Options for LightSwitch (Brian Moore)

Rate This
  • Comments 26

One of the many awesome things about LightSwitch is its flexible deployment model. When you design a LightSwitch application you are actually building a multi-tier application.

clip_image001 

Because of this multi-tier design, you can deploy a LightSwitch application in a variety of ways. Since LightSwitch apps are just web apps, you can host them on your own IIS box, third-party ISPs, or even Azure. This plays well into the new app model of SharePoint 2013 where apps are now isolated from the SharePoint server. When you install a SharePoint app, a manifest is installed into SharePoint that has information on where your app runs (among other things). Client-side code can be run from SharePoint but any apps that contain server-side code, like all LightSwitch apps, must run on a separate server outside of SharePoint. This isolation provides better stability of the SharePoint farm.

When you enable SharePoint in your LightSwitch apps, you are telling LightSwitch to do a few things:

    • Create a SharePoint project with a manifest that tells SharePoint how to communicate with your app
    • Add references to the SharePoint client-side object model (CSOM) so you can access SharePoint via code
    • Use SharePoint to control Authentication via OAuth

There are three ways you can host a SharePoint 2013 app. Provider-hosted, Autohosted and SharePoint hosted. SharePoint hosted apps do not have a middle-tier / database backend – they are simply client-side JavaScript/HTML apps so this type of hosting does not apply to LightSwitch. Since LightSwitch apps are multi-tier web apps there are a couple ways you can host these.

clip_image002

Autohosted

With Autohosted apps, the web site and database are provisioned automatically into Azure each time app is installed. The data is provisioned into SQL Azure and the middle-tier into an Azure website. This means that each instance of your LightSwitch app that is installed into SharePoint is isolated from all other instances on other SharePoint sites.

While autohosting is a very quick and easy way to get a app running there are a few downsides.  One is that you don’t have access to the LightSwitch web app or data outside of SharePoint and if you remove the app from SharePoint, everything is deleted – even the data.  Also, autohosting is not yet available for the Office Store, though it works fine for a private app catalog in Office 365.

If any of that concerns you, not to worry, you can still host your LightSwitch app for SharePoint just as you always have with the other option.

Provider-hosted

Provider-hosted apps give you the flexibility of hosting the web application and database wherever you want. However, with flexibility comes responsibility. With this model, all SharePoint app instances share the same middle-tier and data so you will need to provide your own tenant isolation (multi-tenancy).  You also need to manage availability – if your server goes down, all your SharePoint apps stop working.

However, the benefit is that you own the data and have access and control over the entire application. LightSwitch supports row level filtering and access control so you can design your database appropriately.  You could also deploy separate instances of your app for each installation.  Essentially, this is the same thing you would do today taking into account your need for multi-tenancy.

App Authentication

Because your app runs outside of SharePoint we need to have a way to authenticate the app so not just any ol’ app can go communicate with your SharePoint site and data.  Again, LightSwitch makes it easy for you to take advantage of the options SharePoint offers and just like hosting, you can change them whenever you need to.  You can set these options when you enable SharePoint and also when you publish.

ACS

ACS is short for “Access Control Service” which is another server that brokers authentication between your app and SharePoint.  Your app will have a “secret” known to SharePoint and can use it to authenticate via ACS.

High-Trust or Server-to-Server

In this configuration, a certificate is installed on the SharePoint server and the server running your app.  The app needs to know where the cert is installed on the server (i.e. where is the pfx file) and the password.  Then the app can use that cert to prove to SharePoint who it really is…  There is a fair bit of manual configuration to enable this and you can find that on MSDN.

image 

So that’s great info – a very terse description (trust me you want it to be terse), but what should you use?  For starters, it depends on where you want to host your app (On-prem or Cloud) and where SharePoint is running (On-prem or Cloud).  This will make some decisions for you.  I’ll give you my personal preference as well but first here’s the matrix… 

 

SharePoint On-Premises

SharePoint In the cloud

LightSwitch app is Provider-hosted

ACS1 or High-Trust

ACS only

LightSwitch app is Autohosted

n/a2

ACS only

1 ACS on-prem is also known as a “hybrid” mode which requires the farm be configured for ACS
2 Autohosting is not yet available on-premises 

So you you don't have spend a lot of time deciding because it may be decided for you – if you’re running in the cloud, you must use ACS and this doesn’t actually require you do do anything other than tell LightSwitch that’s what you want to use.  On-premises you have the option, but my personal preference is to use ACS whenever possible, simply because you never have to worry about anything related to app auth – LightSwitch will take care of it for you.

If you’re working on-prem and have the option – a few pros/cons.  ACS will require domain admin involvement to get this up and running.  Trust needs to be established between Azure and your internal network.  There’s more to it than that (again being terse) but once that’s done, it’s done.

For High-Trust apps, you have to manage the cert, install it on the SharePoint server, install it on your dev box and install it on the server the LightSwitch app will run on when deployed.  You might have different certs for dev and production, different certs for each app (meaning you have to track all these) or you might have one cert for everything which can be a pain if you ever have to revoke that cert because everything using it will need to be updated.

Now you also may have some “internal restrictions”.  For example, since running ACS on-prem requires some domain admin involvement to setup ACS with your on-prem SharePoint server, you might have to wait to get started.  If so, you can configure your app to use High-Trust while you wait for ACS.  Remember that LightSwitch will let you change this setting whenever you want and it won’t affect your code.  You could also sign-up for a trial of Office 365 and develop against that while you’re waiting.  Hopefully, by the time your trial is done, you’re either hooked or ACS is configured ;)

I’ve used both for months now and you likely won’t notice the difference between on-prem and cloud, you *will* notice the difference between ACS and High-Trust.  ACS is the way this stuff should be done, just in case you have a say in the matter…. 

The LightSwitch Publish Wizard

So you’re done with your app…  You might have had to go through some other blogs to get here, but let’s walk through how the LightSwitch Publish Wizard works.

Those options covered above come into play when publishing.  The options may be determined by your customer’s environment, for example if they’re using Office 365, but in any case, here’s what you’ll come across when publishing.

The first option is how you want to host your app.  If you autohost your app, then you just need to provide the data connection information, if you have it, and you’re done.  Remember that when autohosted, you app will be provisioned in Azure automatically by SharePoint so that’s all there is to publishing an autohosted app. 

image 

When your app is provider-hosted, you need to specify how you want your app to authenticate.  This is the “ACS vs. High Trust” choice you make when you start developing with SharePoint.  In most cases, this is likely to be the same during development and publish but it doesn’t have to be.  Also, even if the type of authentication is the same, the values or artifacts used are likely different between a dev and production environment.  So we have the option to configure those things during publish.

If your SharePoint server or farm is using ACS then all that’s required is a ClientID and Secret that’s shared between your application and SharePoint.  You can get those values by from your SharePoint site where the app will be installed.  You get them by visiting a page on the SharePoint site – found at http://mysite.sharepoint.com/_layouts/15/appregnew.aspx.  Just add _layouts/15/appregnew.aspx to the end of the url for your site.  Here you can generate both the Client ID (or App Id as it’s referred to at times) as well as the App Secret – these values apply to your server farm, not just the site you collect them from.  Once generated, you need to keep this information in a safe location so that another app doesn’t get the ability to impersonate your app.  You also need to supply the App Domain for your app, which is where the app will be hosted (e.g. yoursite.azurewebsites.net).  So it’s not just a matter of stealing the App ID and Secret in case you were wondering.  Finally, if you ever need to retrieve or change some of these settings with SharePoint you can do that by visiting appinv.aspx but you need to know the App Id to retrieve anything.

image 

Once you have those values, you can complete the publish wizard. 

image 

Now if you’re running in a High Trust configuration, you don’t need the client secret, but you do need the App ID and the certificate information as you did during development.  Ideally, this information is different than what you used during development since the production server should have a different certificate…  It doesn’t have to be different of course, but it should be ;)

Also, you might be wondering why you never needed a secret (or ID for that matter) before publishing.  That’s because Visual Studio handles all of that for you during development.  Your app still uses an id and secret, but you never have to worry about it until you’re ready to publish your app.

The last thing you need then is the Client ID or App ID.  This also comes from the appregnew page and you need this whether you’re using ACS or High Trust. 

image 

Now, the LightSwitch publish wizard will put this information into web.config for the app to use at run-time.  Once you’re done with the publish, you’ll need to install your app package file that’s generated by publishing into the SharePoint catalog -- but we’ll cover that in another post.

-Brian Moore, Program Manager LightSwitch Team

Leave a Comment
  • Please add 7 and 1 and type the answer here:
  • Post
  • Super Great!!! Thanks!!!

  • With the official release, have the auto-hosted options changed to allow on-premise auto-hosting?

  • @Chris - Chris, at this time, SharePoint 2013 does not offer autohosting on-prem.  When they do, the current publish paths in LightSwitch should support it.  HTH

  • Where can I find LS to SP Publishing Details. Please Provide me link

  • @DK - we should have a blog post for LS/SP publishing in the next couple weeks.  In the meantime if you have any questions, kick off a thread in the forums and we'll do our best to guide you there.

    Also, if you have any specific things you'd like to see in the publishing details, let us know.

  • hi,

    these kind of SharePoint Hosting & Authentication Options for LightSwitch having 3 tier structure one is client tier,middle tier,and data sources this structure is used in this type of hosting.

    thanks

    www.veebrij.com

  • veebrij - I'm not following you - can you rephrase your question?  (or were you just commenting on the architecture?)

  • Thanks for a great post! We are investigating deploying multi-tenanted applications under SP using the provider-hosted model on Azure and we are currently exploring options around using a shared database vs using a separate database per tenant. The following bit under the "Provider-hosted" paragraph is not clear to me:

    "You could also deploy separate instances of your app for each installation.  Essentially, this is the same thing you would do today taking into account your need for multi-tenancy."

    Under default provider-hosted deployment (in say Azure) all tenants will share the same app and same database and we can write LS filters to isolate the data - this is all good and understandable.

    Does the above quoted part from the above article imply that we could also use a separate app per tenant and more importantly, a separate SQL Azure database per tenant?

    Any additional information to help clarify this would be very welcome. Thanks in advance.

  • Hi Xander!

    There are 2 types of hosting options for LightSwitch. One is provider hosting, which you have a handle on. You would have one database/middle-tier shared for every SharePoint deployment, hence you would need to architect for multi-tenancy, but then you could deploy the LightSwitch application exactly where you wanted.  Then there is Auto-hosting -- this is when you package the entire app up and hand it off to the SharePoint catalog.  Then when users install the app on their site, SharePoint handles the provisioning of this into Azure for each instance. The downside is that it's out of your control -- if a user deletes the SharePoint app from their site, all the data goes with it. For more info see: msdn.microsoft.com/.../fp179887.aspx

    Cheers,

    -Beth

  • Hi Beth, thanks for the reply. That part of the paragraph I quoted therefore referred to "auto-hosted". That clears it up for me.

    We definitely want to go with the provider-hosted model.

    I may start a separate discussion about this on the LightSwitch forum as we explore how best to architect for a provider-hosted deployment where each tenant has a separate database. This is easy when using a RIA domain service (as you can easily change the connection string dynamically) but not so with an external database data source which is what we hope to use.

    Thanks again

    Xander

  • @Xander - a simple way to think this is to give each tenant their own copy of the app.  That simplifies your development as well as billing for the customer (assuming an O365 model)...  but that really only works if you can scale giving each customer a distinct copy of the app.

    This is an interesting scenario that I think many folks are or will be interested in so do let us know how you go...

  • What are the options for granular security with a LightSwitch SharePoint app?  In non-SharePoint LightSwitch we can use roles and permissions to restrict access to specific tables and screens to specific users - I'm wondering how to accomplish something similar with LightSwitch on SharePoint.  Thanks

  • @Simon - for SharePoint apps all of the authZ are handled by SharePoint, so you don't manage the perms in the LightSwitch dev environment the way you do with non-SP apps.  On SharePoint you would check against any SP perms that are configured.  That help?

  • Thanks for the reply Brian.  So if I've understood, you would controls access to screens and data by querying the user's membership of SharePoint Groups (or maybe access to SharePoint Permission Levels)?

  • Does this work in sharepoint Online (office 365) with provider hosted Azure?  I cannot get it to work.  Generally I get an error after production deployment that I do not have permissions to view the site.  Has anyone tried this.  I talk about this error on the forums at social.msdn.microsoft.com/.../vs2013-cloud-business-app-lightswitch-provider-hosted-azuresharepoint

Page 1 of 2 (26 items) 12