One of the key challenges for providing enterprise scale provider hosted add-ins in the Microsoft Office Store has been lack of supporting full trust operations for any add-ins which are available from the store. This is common challenge for many ISVs and add-in providers, which have been asking to address this numerous times.
Challenge of providing full trust operations through the Microsoft Office Store would be unclear responsibilities related on the granted permissions and the used customizations. Due this limitation some ISVs and add-in providers have chosen not to use the Microsoft Office Store as the distribution channel, which has meant challenges on reaching out for the potential customers and challenges for customers on finding needed solutions for their deployment.
To address this challenge, the store policies have been adjusted slightly, which will enable ISVs and add-in providers to take advantage of the Microsoft Office Store as the main distribution and contact channel for new customers.
We will not support add-ins which require full trust permissions directly from the store, but you are allowed to add add-ins to store, which are dependent on manually deployed SharePoint add-ins installed on the Office 365 tenant by the tenant administrators. Store add-ins which require separate full add-in to be installed on the used tenant, will have roughly following description in the store, which also warns about the security impact of this model:
This SharePoint add-in works in conjunction with another add-in, which is only available from the provider. This requires installation on your environment outside of the Microsoft Office Store processes due the level of required permissions. A tenant administrator will need to deploy this specific add-in to the tenant manually, so that it can be installed to your environment. When apps are installed outside of the Microsoft Office Store, they may bypass any, and all, safety and security checks provided by Microsoft.
If you have not done so already, it is recommended that you establish contact with the provider before proceeding with installation. Consider trying this add-in on a separate SharePoint Tenancy before installing it on your primary SharePoint site(s).
“I’ve been able to do this before for add-ins which are not in the store, so what’s actually new?” – What’s new is that we are changing the store policies to also allow add-ins which have dependency for the manually installed high permission add-ins. This way you can use store as the connection channel between customers and ISVs. With this change, customers can find different ISVs or add-in providers more easily and it also provides easier connection channel for ISVs and add-in providers for exposing also high permission add-ins for the customers.
Logical model for full trust operations with store add-ins
Following picture explains the model more detailed.
- We will continue supporting similar add-ins as previously in the store side. These cannot request full trust permissions from the SharePoint sites. Add-ins can however have now dependency on second add-in or configurations performed outside of the store context.
- Customer will contact the add-in provider for requesting the high permission add-in to be installed. ISV or add-in provider will work directly with the customer on getting the high permission add-in installed with the needed permissions to the specific tenant(s).
- Add-ins installed from the store will delegate or bypass needed high trust operation requests for the high trust add-ins which will use the different client IDs and secret for needed operations.
Sample solution design with full trust operations
Here’s a sample scenario with high level logical design for the add-in model implementation. In this case we use the business case of providing self-service site collection creation capability for Office 365. There are multiple different ways to delegate the requests from the store add-in to high trusted add-in.
In this case we are using Azure Storage Queue and WebJobs to perform loosely coupled communications between store add-in and high permission add-in.
- Add-in is installed from the store to SharePoint site with normal permissions supported at the Microsoft Office Store
- Add-in from the store is providing needed UI for requesting the new site collection with specific template and branding
- Request for the new site collection is added by the store add-in to Azure Storage Queue for processing.
- Continuously running Azure WebJob is automatically executed when the message is added to Azure Storage Queue. Azure WebJob working as backend service will use full trust permissions granted manually for the tenant to perform needed actions. In this particular case Azure WebJob will provision new site collection and applies needed branding and customizations to it using remote provisioning pattern.
- New site collection with needed branding and customizations is available for end users. Emails are sent for the end users based on the information received with the original request related on just created site collection.
Can this be done with SharePoint hosted add-ins?
We do recommend implementing these kind of add-ins using provider hosted add-in model. Key challenge with using SharePoint hosted add-ins would be securing the communications from the store add-in to full permission add-in.
Vesa Juvonen, Senior Program Manager, Office 365, Microsoft
