📢Mona 2.0 is now in preview! #134
Replies: 3 comments 7 replies
-
[celebrate] Josh Marvel reacted to your message:
…________________________________
From: Casey Watson ☁️ ***@***.***>
Sent: Wednesday, July 17, 2024 9:14:45 PM
To: microsoft/mona-saas ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [microsoft/mona-saas] Mona 2.0 is now in preview! (Discussion #134)
Howdy, Mona community! 🤠 I'm excited today to announce the preview availability of Mona 2.0!
TL;DR: We've completely rewritten Mona from the ground up with some new security and usability features driven by your feedback and Microsoft's Secure Future Initiative (SFI)<https://www.microsoft.com/microsoft-cloud/resources/secure-future-initiative>. We'll be pushing this new version of Mona to the main branch<https://github.com/microsoft/mona-saas/tree/main> next week but we wanted to give you a chance to try it out first<https://github.com/microsoft/mona-saas/tree/mona20>. There is no automatic upgrade path from Mona 1.0 to Mona 2.0 due to underlying infrastructure changes but there's no need to fret: any integrations you've built using Mona 1.0 are fully compatible with Mona 2.0. Please share comments/thoughts/questions on this thread. We sincerely look forward to your feedback!
What's new?
Mona 2.0 is a complete ground-up rewrite of Mona 1.0 with new features focused on these three core pillars:
Pillar 1: Your feedback
Make it easier for CSPs to manage Mona deployments
We've heard you loud and clear: it should be easier for Cloud Solution Providers (CSPs)<https://learn.microsoft.com/partner-center/enroll/csp-overview> to manage Mona deployments on their customer's behalf. To address this problem and further enhance security, Mona 2.0 has been broken down into customer-facing and subscriber-facing apps. By default, any guest (for example, CSPs)<https://learn.microsoft.com/entra/external-id/user-properties> or member of the publisher's Entra tenant can access the subscriber-facing app and manage the Mona deployment.
Streamline the purchasing experience
When we first built Mona, the aim was to meet all the technical requirements for publishing your SaaS app on the Azure Marketplace<https://learn.microsoft.com/partner-center/marketplace-offers/plan-saas-offer#technical-information>, including user authentication and a default landing page for purchase confirmation. Only after this confirmation are subscribers redirected to your app, where typically they're asked to authenticate again.
We've heard from many of you that this flow is clunky and unintuitive. Some of you have reached out and asked to bypass Mona's landing page, making Mona's authentication unnecessary before users reached your app. A few years ago, we added this capability to Mona 1.0 with a feature called passthrough mode<https://github.com/microsoft/mona-saas/tree/main/docs#what-is-passthrough-mode>, which can be enabled today using an environment variable feature flag. Most of you can enable it on your existing Mona 1.0 deployment today.
With Mona 2.0, we've eliminated the landing page UI altogether and redesigned the purchasing flow around passthrough mode. Users will no longer see a Mona landing page or need to authenticate through Mona.
We understand this change may be controversial for some Mona users. However, we made this decision to simplify the Mona codebase and streamline the purchasing experience.
As open source maintainers, we reserve the right to be wrong. We'd love to hear your thoughts (good, bad, or ugly) about this decision by leaving a comment on this post.
Pillar 2: Adherence to the Secure Future Initiative (SFI)
"Microsoft runs on trust, and trust must be earned and maintained. Our pledge to our customers and our community is to prioritize your cyber safety above all else." — Charlie Bell, EVP Security, Microsoft.
Security is everyone's responsibility<https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility>, and at Microsoft, we're deeply committed to making Mona as secure as possible from the get-go.
In Mona 1.0, we securely store configuration settings and secrets as environment variables<https://learn.microsoft.com/azure/app-service/configure-common?tabs=portal#configure-app-settings> via Azure App Service. These secrets are encrypted and accessible only with your permission. Additionally, we utilize GitHub secret scanning<https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning> to ensure secrets never make their way into the Mona codebase.
While this approach is robust, we believe we can do even better. Our philosophy is simple: the safest secret is the one you don’t have to keep. That's why Mona 2.0 is moving to a completely secret-less architecture, using managed identities<https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview> for authentication to both internal and external service dependencies. The internal identity accesses Mona's own dependencies, like its storage account, event grid topic, and logic apps, while the external identity communicates solely with the Marketplace API. By employing two separate identities, we enhance security through isolation, limiting the impact of any compromised identity.
This shift underscores our unwavering commitment to your security. We're not just maintaining trust—we're elevating it.
Pillar 3: Compatibility with Mona 1.0 integrations
Although we've transitioned to a completely secret-less, managed identity-based security model, we've kept the event model<https://github.com/microsoft/mona-saas/blob/main/docs/event-models/README.md> the same. To update, simply reconnect your existing integrations to the Mona 2.0 event grid topic using Mona's internal managed identity. Logic App triggers can also be easily reconfigured to use managed identities.
What are the breaking changes?
Since Mona 2.0 uses a completely new infrastructure model, there is no automatic upgrade path from Mona 1.0 to 2.0. Let's walk through the breaking changes one by one so you can make an informed decision about if and when to upgrade to Mona 2.0.
No built-in landing page
Mona no longer has its own built-in landing page UI. Instead, users are redirected directly to your SaaS app, eliminating the need for double authentication. This streamlines the purchasing experience, as detailed in the previous section, and makes passthrough mode<https://github.com/microsoft/mona-saas/tree/main/docs#what-is-passthrough-mode> the only supported mode going forward.
Subscription information no longer passed through the _sub parameter
As part of the move to managed identities, we can no longer forward subscription information to your SaaS app through the _sub parameter<https://github.com/microsoft/mona-saas/tree/main/docs#can-i-retrieve-subscription-details-from-the-purchase-confirmation-page>. This feature relied on Azure Blob Storage account shared access signatures (SAS)<https://learn.microsoft.com/azure/storage/common/storage-sas-overview#account-sas>, which, by default, can only be created using a storage connection string. Now that we use a managed identity to access the storage account, we can't generate SAS tokens. While we considered using user delegation SAS tokens<https://learn.microsoft.com/azure/storage/common/storage-sas-overview#user-delegation-sas>, this would require reauthorizing the token every seven days<https://learn.microsoft.com/azure/storage/blobs/storage-blob-user-delegation-sas-create-cli#use-microsoft-entra-credentials-to-secure-a-sas>, adding significant management overhead for the SaaS publisher. Instead, we recommend handling this information through your Mona event grid-based integrations or directly accessing Mona's storage account to retrieve subscription details using a managed identity<https://learn.microsoft.com/azure/storage/blobs/authorize-access-azure-active-directory>.
This is a key feedback area for us. Ideally, how would subscription information flow from Mona into your SaaS app? We look forward to your thoughts!
Next steps
We're giving you a chance to try out Mona 2.0 before we push it to the main branch next week. Please share your feedback with us. Assuming there are no issues with the preview, there will be a follow-up announcement next week about the move to the main branch.
Thank you for being a Mona user! We hope you're as excited as we are about Mona 2.0.
— 🙏 The Mona Team
—
Reply to this email directly, view it on GitHub<#134>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A2S54Z74F4A3JYDYGSMMDZ3ZM3NELAVCNFSM6AAAAABLBM6JBOVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWHE2DOMBXGQ>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
How has the feedback been on the preview? When are you planning on making this the general availability version? |
Beta Was this translation helpful? Give feedback.
-
We use mona v1 for a transactable SaaS app and it works very well for us - so first of all thank you. The landing page experience is the one aspect I found a bit clunky. Specifically, you mention here for v2 that there is no landing page as you can just be passed 'directly to our SaaS app'. But the way we have configured it, at the point of purchase there is no SaaS app. This only gets created after purchase, via the 'add your integration logic' step of the Logic App. For this reason in v1 the handoff from the landing page also didn't work, as the customer SaaS page didn't yet exist so we have to redirect them to a generic purchase page. So we could not use mona v2 without rearchitecting our SaaS to include a permanent generic landing page that could be accessed before a purchase is made. I am also unsure on the difference\relationship between mona and the separate Microsoft repo called the SaaS Accelerator. It seems they are trying to solve the same problem, but in slightly different ways. Is one more 'official' than the other or any guidance available on how to choose between them? |
Beta Was this translation helpful? Give feedback.
-
Howdy, Mona community! I'm excited today to announce the preview availability of Mona 2.0!
What's new?
Mona 2.0 is a complete ground-up rewrite of Mona 1.0 with changes focused on these three core pillars:
Pillar 1: Your feedback
Make it easier for CSPs to manage Mona deployments
We've heard you loud and clear: it should be easier for Cloud Solution Providers (CSPs) to manage Mona deployments on their customer's behalf. To address this problem and further enhance security, Mona 2.0 has been broken down into customer-facing and subscriber-facing apps. By default, any guest (for example, CSPs) or member of the publisher's Entra tenant can access the subscriber-facing app and manage the Mona deployment.
Streamline the purchasing experience
When we first built Mona, the aim was to meet all the technical requirements for publishing your SaaS app on the Azure Marketplace, including user authentication and a default landing page for purchase confirmation. Only after this confirmation are subscribers redirected to your app, where typically they're asked to authenticate again.
We've heard from many of you that this flow is clunky and unintuitive. Some of you have reached out and asked to bypass Mona's landing page, making Mona's authentication unnecessary before users reach your app. A few years ago, we added this capability to Mona 1.0 with a feature called passthrough mode, which can be enabled today using an environment variable feature flag.
With Mona 2.0, we've removed the landing page UI altogether and redesigned the purchasing flow around passthrough mode. Users will no longer see a Mona landing page or need to authenticate through Mona.
We understand this change may be controversial for some Mona users. However, we made this decision to simplify the Mona codebase and streamline the purchasing experience. Did we get it right? You tell us!
Pillar 2: Adherence to the Secure Future Initiative (SFI)
Security is everyone's responsibility, and at Microsoft, we're deeply committed to making Mona as secure as possible from the get-go.
In Mona 1.0, we securely store configuration settings and secrets as environment variables via Azure App Service. These secrets are encrypted and accessible only with your permission. Additionally, we utilize GitHub secret scanning to ensure secrets never make their way into the Mona codebase.
While this approach is robust, we believe we can do even better. Our philosophy is simple: the safest secret is the one you don’t have to keep. That's why Mona 2.0 is moving to a completely secret-less architecture, using managed identities for authentication to both internal and external service dependencies. The internal identity accesses Mona's own dependencies, like its storage account, event grid topic, and logic apps, while the external identity communicates solely with the Marketplace API. By employing two separate identities, we enhance security through isolation, limiting the impact of any compromised identity.
This shift underscores our unwavering commitment to your security. We're not just maintaining trust—we're elevating it.
Pillar 3: Compatibility with Mona 1.0 integrations
We didn't touch Mona's event model which means you can keep all your existing integrations with a few minor changes. To update, simply reconnect your existing integrations to the Mona 2.0 event grid topic using Mona's internal managed identity. Logic App triggers can also be easily reconfigured to use managed identities.
What are the breaking changes?
Since Mona 2.0 uses a completely new infrastructure model, there is no automatic upgrade path from Mona 1.0 to 2.0. Let's walk through the breaking changes one by one so you can make an informed decision about if and when to upgrade to Mona 2.0.
No built-in landing page
Mona no longer has its own built-in landing page UI. Instead, users are redirected directly to your SaaS app, eliminating the need for double authentication. This streamlines the purchasing experience and makes passthrough mode the only supported mode going forward.
Subscription information no longer passed through the
_sub
parameterAs part of the move to managed identities, we can no longer forward subscription information to your SaaS app through the
_sub
parameter. This feature relied on Azure Blob Storage account shared access signatures (SAS), which, by default, can only be created using a storage connection string. Now that we use a managed identity to access the storage account, we can't generate SAS tokens.While we considered using user delegation SAS tokens, this would require reauthorizing the token every seven days, adding significant management overhead for the SaaS publisher.
Instead, we recommend handling this information through your Mona event grid-based integrations or directly accessing Mona's storage account to retrieve subscription details using a managed identity.
Next steps
We're giving you a chance to try out Mona 2.0 (in the
mona20
branch) before we push it to themain
branch next week. Please share your feedback with us. There will be a follow-up announcement when we push Mona 2.0 to themain
branch.Thank you for being a Mona user! We hope you're as excited as we are about Mona 2.0!
— 🙏 The Mona Team
Beta Was this translation helpful? Give feedback.
All reactions