Editja

Ixxerja permezz ta’

Azure Lighthouse in ISV scenarios

  • Artiklu

A typical scenario for Azure Lighthouse involves a service provider that manages resources in its customers' Microsoft Entra tenants. Independent Software Vendors (ISVs) using SaaS-based offerings with their customers may also benefit from the capabilities of Azure Lighthouse. Using Azure Lighthouse can be especially helpful for ISVs who offer managed services that require access to a customer's subscription scope.

Managed Service offers in Azure Marketplace

As an ISV, you may already have published solutions to the Azure Marketplace. If you offer managed services to your customers, you can do so by publishing a Managed Service offer. These offers streamline the onboarding process and make your services more scalable to as many customers as needed. Azure Lighthouse supports a wide range of management tasks and scenarios that can be used to provide value to your customers.

For more information, see Publish a Managed Service offer to Azure Marketplace.

Using Azure Lighthouse with Azure managed applications

Azure managed applications are another way that ISVs can provide services to their customers. You can use Azure Lighthouse along with your Azure managed applications to enable enhanced scenarios.

For more information, see Azure Lighthouse and Azure managed applications.

SaaS-based multitenant offerings

An additional scenario is where the ISV hosts resources in a subscription in their own tenant, then uses Azure Lighthouse to let customers access those specific resources. Once this access is granted, the customer can log in to their own tenant and access the resources as needed. The ISV maintains their IP in their own tenant, and can use their own support plan to raise tickets related to the solution hosted in their tenant, rather than the customer's plan. Since the resources are in the ISV's tenant, all actions can be performed directly by the ISV, such as logging into VMs, installing apps, and performing maintenance tasks.

In this scenario, users in the customer's tenant are essentially granted access as a "managing tenant," even though the customer isn't managing the ISV's resources. Because the customer is directly accessing the ISV's tenant, it's important to grant only the minimum permissions necessary, so that they can't make changes to the solution or access other ISV resources.

To enable this architecture, the ISV needs to obtain the object ID for a user group in the customer's Microsoft Entra tenant, along with their tenant ID. The ISV then builds an ARM template granting this user group the appropriate permissions, and deploys it on the ISV's subscription that contains the resources that the customer will access.

Next steps