Recommended winget strategies for LOB distribution #55
Description
First off thank you to the team working on this project and making it open source for community contributions very early into it's development. With the announcement that the windows store ecosystem will be sunset in the first quarter of 2023 I'm sure there are many organizations out there relieved to see a project like this in the works to serve as an alternative.
Initial deployment of the private repository was a little tricky, but I fully understand this is a work in progress and the process/documentation will improve over time. Once the API was deployed everything seems to work very well out of the box (and can definitely see the appeal of how easy it is to pull software down onto machines with Winget).
Now were trying to imagine how this private repository could potentially be used as a replacement for the Windows Store LOB distribution channels. A key feature of the store LOB distribution is the ability for publishers to have a single catalogue of software packages, but control individual package assignments to their partners. For example if the publishers catalog has 3 software packages in it total, all 3 packages might be assigned/available to one connected partner, but another partner may only have access to 1 or 2 of those titles out of the catalogue.
Testing with the private repository we can see its simple enough to control access to the api endpoint itself and the underlying storage for each package installer. Where there is uncertainty right now is simply what is the best practice/recommended way to try and achieve this (or if this is a bad idea to try entirely?). We have been working with @mjfusa from the app consult team at Microsoft to try and plan our impending transition, and it was suggested to post our situation here as this team has the most expertise with private repositories and would have a better idea of any development plans in the coming year.
Currently were able to think of 2 (potential?) approaches to take and trying to work out if either would be manageable.
Approach 1
Each partner deploys their own private API endpoint and controls access to their users how they see fit. The publisher maintains a separate storage account for each partner, and a master storage account containing all of their package installation media. To assign a package to a specific partner, the package is synced from the master storage to the partners storage account and a manifest is pushed to the partners private repository with reference to the installer location in their specific storage location.
pros
- partners are only able to see software titles that they can actually install
- access can be revoked by removing the manifest and installer out of the partners system
- each partners endpoint/storage could be secured in a way that suits the partner
cons
- if there are more than a handful of partners this could be a lot of infrastructure to manage
- the partner needs to supply access to their azure tenant for the publisher to deploy the infrastructure (unless its all deployed in publishers tenant)
- some development required for automation of process
Approach 2
The publisher creates a single private API endpoint (all partners have access), storage accounts for each partner, and a master storage account containing all installers. To assign a package to a specific partner, the installer is synced to that partners storage account, and a unique package manifest is added to the repository with reference to it.
pros
- only requires management of a single api endpoint
- each partner storage could be secured in a way that suits the partner
cons
- partners would see all programs in the repository, installations would fail on anything not assigned.
- software packages might need to use partner specific aliases which could be confusing to users trying to install something
- some development required for automation of process
Approach 3
Is there something we are totally looking over right now that could be done at the individual manifest level, or somewhere else to easier control access? For example maybe having redundant installation locations in a manifest which are partner specific?
Would be grateful for any suggestions or advice you can provide in this area. Unfortunately at the moment things are largely undocumented so just want to try and ensure we are not going down the wrong path in the coming months. As the deadline for the store going away gets closer, the urgency to find an alternative will definitely keep ramping up.
Thank you again!