For uploading and deploying SPFx packages I found these permissions to be the bare minimum:
Delegated Microsoft Graph User.Read
Delegated SharePoint AllSites.FullControl
Service Account
The second part is the service account that just has access to one site collection – Tenant App Catalog. That plus Delegated AllSites.FullControl of the app registration narrows the access to just that site. To install apps the Uploader Account needs to be Site Collection Administrator.
Least privileges for SPFx Upload & Deploy
Azure Pipelines
In our project we use Azure Pipelines where we also define the release using .yml. The deployment consists of series of bash inline scripts.
I am not going to describe all the steps for setting up node, npm and installing the office 365 cli. If you already have used Office 365 CLI with the default AAD APP it might look like this:
– task: Bash@3 # login
displayName: "Login to O365 spAppCatalogSiteUrl with user $(username)"
That’s straight forward when you run the cli in your own console. But the fact is (or at least from what I can see), you cannot “export” variables to other pipeline tasks.
Instead of setting the variables in the inline script, we can take advantage of the Bash task parameter called env:.
Some other findings:
Office 365 CLI needs them in all three commands: login, spo app add, and spo app deploy
If you create and export a variable in a pipeline task, it won’t persist, because every task starts a new shell session.
That means that we need to provide environment variables in every task in the pipeline, that uses Office 365 CLI with a custom Azure AD App. Or is there a better way? Anyway, the version below (the same tasks plus `env`) will work:
– task: Bash@3 # login
displayName: "Login to O365 spAppCatalogSiteUrl with user $(username)"
My goal is to remove the need of legacy authentication. Previously we installed spfx packages using PnP PowerShell. PnP PowerShell in Pipelines causes Legacy Authentication, it can be solved, though:
Site Collection App Catalogs are great for special cases (like developing apps or site unique apps), but using them on scale would be a mess.
I got a question: Why should we use the Tenant App Catalog at all when we could enable a Site Collection App Catalog on every teamsite? So the suggestion here is to install SharePoint Framework Packages on many Site Collection App Catalogs, instead of the Tenant App Catalog. In that way those wouldn’t be visible for all users in the “Add an app” page.
Technically, both ways are possible, but I would say, we should use the Tenant App Catalog for apps that are installed on many sites. I have gathered some pros and cons to help people decide.
But first, some abbreviations and notes on terminology:
SCAC = Site Collection App Catalog, (Local App Catalog)
TAC = Tenant App Catalog, (Global App Catalog)
App = SharePoint Framework Package, but also a SharePoint Add-In
Pros and Cons of Site Collection App Catalogs
👍 A SCAC makes it possible to have local instances of an app. It is perfect if you want to test an app without making it visible for the whole tenant. It is also good for apps that are only installed on one site collection. There are benefits of distributing site specific apps through the TAC, such as better governance, once installed on a site, those apps can be Disabled.
👎 Mess in all the apps and the versions. There might be different versions of the apps. The update procedure will require a special script to find all the sites and run the update. This also requires owner access to that site. If the owners would like to remove all the IT accounts in order to collaborate on confidential information, then it won’t be possible to update that site. It will lead to poor governance. Just to give it a perspective. Imagine that every smartphone had its own local App Store/Google Play. Possible but counterproductive.
👎 A SCAC is a security risk. The control and governance is handed over to site owners. It means that they can install any apps on their site collections. Poorly designed and implemented apps can lead to big security issues, in the similar way as custom script.
👎 Enabling a SCAC adds additional lists and features (such as Apps for SharePoint). It will require more space (not so much, but still), but first of all it will make some users more confused, actually more confused then some more available apps. Imagine all the support: What is it, Oops I deleted “Apps for SharePoint”.
👎 Every app will install the resources on every site collection, meaning every app will have multiple copies of the same app. It means more space needed. That is of course, not the case if you use Azure CDN.
👎 Every app will use its own urls to resources, preventing browsers from gaining performance by caching the resources cross site collections.
👎 If Azure CDN is used, you must make sure all the versions of javascript and css files are kept because you might not know which versions of an app are still used.
Pros and Cons of the Tenant App Catalog
👍 Easier to control the apps and have better governance. The Tenant App catalog tells what apps exist in your tenant. As admin you can verify that the code complies with the guidelines (by running code checks), you can make sure, every app there has all needed information such as app owner, description etc.
👍 Easier to update apps. Installing a new version of an app will update all the instances. There won’t be any custom script to traverse all the sites with that app.
👍 It is more cost efficient to follow the Tenant App Catalog approach, because it is the recommended way of installing and updating apps. Having scripts and procedures for SCAC, (even completely automated) will always cost more: to keep the scripts up to date, support etc.
👍 Benefits of the common apps. If a business unit comes up with a good solution, it can be used by other Business units, if it is discoverable and follows quality guidelines (more on that later).
👎 The Apps from the TAC are visible to all Business Units and the users might be confused. This issue can be mitigated in two ways:
The business units that have not rolled out SharePoint Online and don’t use any apps, can remove their users from the App Catalog.
Having a good naming policy, app icons, good descriptions, disabling any “auxiliary” apps. On top of that, some user guidance.
Summary of pros and cons
To summarize, Site Collection App Catalogs for reusable apps installed to many site collections, is a bad idea, because it means a security risk, less control and governance, encreased data and traffic to SharePoint Servers.
How can we scope apps to our business units
Are there other ways of scoping the apps to business units other than misusing the Site Collection App Catalogs?
First of all, it is a question of user adoption. It is better to help users instead of breaking the functionality or misusing other concepts.
Second, it is a question about governance of the Tenant App Catalog. It should be clear how an app can be added, and how that package should be wrapped:
good naming standard,
proper localization
a mandatory icon,
good description,
owner/contact person. Also, only relevant apps should be “Enabled”. All the other apps should be Disabled.
A couple of apps from your organization is a drop in the ocean compared to SharePoint Store Apps
Control with Permissions
If you remove a user from the Tenant App Catalog, the apps will disappear for that user.
There are apps, but this user cannot see any apps to install.
The permissions can set on the whole Tenant App Catalog by removing “Everyone except external users” and then adding all AD Groups who should see the apps.
The permissions could also be set on the specific packages or folders.
The permission way of scoping the apps might work. But it is important to know that it is a workaround and it breaks the default setup (where all users have READ on the TAC). This means that along the way you can bump into limitations or bugs, more or less unique to your organization. It will be harder to get help from Microsoft or from community.
I uploaded my app to two site collection app catalogs. Do I need to get approval for the app twice? – No.
I have got my approval for Delegated Groups.ReadWrite.All for App X. Now I want to use the same permissions in another app, do I need a new approval? – No.
Recent Comments