As of October 2020, a recently revised policy went into effect for all SaaS offers in Azure Marketplace and AppSource, detailing integration requirements with Azure Active Directory (AAD) SSO in the subscription purchase and activation process.
The policy change was announced in July 2020 and is applicable to transactable SaaS offers across the Microsoft commercial marketplace.
This change helps ensure that transactable SaaS offers can be purchased and activated consistently by commercial marketplace customers, increasing overall buyer confidence. This requirement does not mean your application must support AAD SSO, rather that the commercial marketplace buyer is able to activate their subscription to your application using the same AAD information that originated the transaction in the commercial marketplace. Tackle customers are insulated from additional engineering work to satisfy this requirement because the Tackle’s commercial marketplace integration is already AAD-enabled and compliant with policy,
Let’s dive in and understand where this policy lives and why it’s important for SaaS offers in Azure Marketplace and AppSource.
If you are responsible for a SaaS offer in Azure Marketplace, you likely received an email similar to the one above in recent weeks. We received one, as did many of our 80+ customers that have a SaaS offer on Azure Marketplace with the Tackle Cloud Marketplace Platform.
Those of you who are Tackle customers, rest assured that your listing is fully compliant! For those that are considering a SaaS offer or wondering what you need to do to become compliant, this blog is for you.
We’ll outline the current requirements, describe the specific changes and walk through some history of the changes and some possible reasons why the policy changed and why now.
A bit of background on commercial marketplace policies
Before we head right into the new policy, let me summarize the various agreements and policies that any publisher of a SaaS offer must agree to before publishing to Azure Marketplace (or AppSource, for that matter).
Agreements explicitly signed by the ISV Partner (all can be found in Partner Center):
- MPN Agreement – governs the Partnership program
- Publisher Agreement (effective 5/20) – outlines the terms and conditions of publishing in AppSource or Azure Marketplace; references the various policies (below)
- App Developer Agreement – terms for building apps and outline of fee structure (this agreement is largely for game developers and doesn’t apply to most of our customers)
Policies referenced in the signed Agreements
- Commercial marketplace certification policies (this is what changed)
- Microsoft AppSource and Azure Marketplace review policies
- Azure Marketplace participation policies
- Azure Marketplace terms
NOTE: most of this posting discusses recent changes made to the “Commercial marketplace certification policies.”
Summary of Certification Policy Section 1000: “Software as a Service”
Many ISV’s that we engage with are not really aware of the details in this document, so it’s worth outlining the first section, 1000.1
The Microsoft commercial marketplace provides a variety of ways for the underlying products sold through SaaS listings to deploy.
This flexibility is a differentiator, in our opinion, as the reality in today’s ISV ecosystem is that few ISV’s are either true, multi-tenant SaaS (naturally providing a SSO experience) or ready to auto-deploy into a customer’s Azure tenant. The Microsoft policy gives ISV issuers the flexibility to crawl, walk, then run to a true SaaS product.
That said, Microsoft is delving deeper and deeper into the SaaS solution architecture to confirm the underlying product achieves the higher-level Microsoft goal of addressing customer needs through 1st (Microsoft) and 3rd (ISV Partner) party services that consume Azure resources.
While section 1000.1 isn’t new, our recent experience suggests that Microsoft is looking more often to this policy in assessing the fit of an ISV’s SaaS offer for Azure Marketplace. This is apparent through the listing certification process.
So, be ready – ensure your offer either (1) runs on Azure (2) is deployable to Azure or (3) integrates with or extends Azure Services.
Now, on to the new stuff: Section 1000.3
As noted above, we think about SaaS offers in two ways (1) the purchase of an ISVs product via a SaaS offer (that’s what we do) and (2) the deployment of entitlements for the ISV product (aka the “application” – that’s what you, the ISV, does).
However, after checking in with the commercial marketplace team earlier this year, it became clear that the requirement applies ONLY to the first portion—the purchase and activation (of the purchase with the ISV) step.
Not to over-simplify the solution (it’s straightforward yet fairly complex), but limiting this policy to the purchase and registration process makes the most sense to us. Why, you ask? Because, in our experience, many ISVs do not currently have a single sign-on capability due to the specific, unique deployment requirements of their specific product. Most are working towards true SaaS capabilities but are not there just yet.
Here’s how Tackle has addressed this policy. We support both MSA and AAD account types as well as manage the buyer’s consent using AAD in a way that is compliant with Microsoft’s certification policy.
We also offer the buyer the chance to leverage data obtained through AAD or to enter the details themselves.
Why did we elect this option? We offer this choice because we’ve found (from over 200 Marketplace listings and transacting $100sM) that the actual Marketplace “buyer” is often a different person from the one deploying or using the ISV product. So, the buyer may activate their subscription with a different email address and contact information than what was used to purchase in the marketplace.
What to do next
If you are a Tackle customer, don’t worry because we’ve made the necessary changes for you and now you have a bit more visibility into changes that can be made to Marketplace policies at any given time.
If you are not working with Tackle but have an offer in Azure Marketplace or AppSource that does not comply with these new requirements, you have two options:
| 1: Have your engineers do this…
|
Or 2: Go to Azure Marketplace and purchase this…
|
More seriously, though, if you decide to create your own route to the Microsoft commercial marketplace, we recommend you first allocate resources accordingly, as integrating into the Microsoft commercial marketplace requires engineering and business resources to:
- Build the integrations with Marketplace APIs like the “SaaS fulfillment API v2” and the “Marketplace metered billing APIs”
- Build and host the registration page
- Develop the business workflow processes to manage orders, license entitlements, transaction amounts, payment reconciliation, etc.
Finally, any ISV embarking upon this journey should understand that this effort is more of a product-oriented set of activities than a single project. As evidenced by this blog, things can and do change with regard to certification practices and policies over time.
Here at Tackle, all we do is think about helping sellers sell through any cloud marketplace, including the Microsoft commercial marketplace, as well as AWS Marketplace and GCP Marketplace. If you want to learn more, we’re here and ready to help! Schedule a demo or contact us at hello@tackle.io.
Additional Resources
For more details, check out these great resources from Microsoft:
- Complete details about Azure AD and transactable offers
- “Welcome to the commercial marketplace” documents
- Commercial marketplace certification policies
- Marketplace publisher agreement
- Azure Marketplace and AppSource publishing guide
- Commercial marketplace community forum
