Launching an Azure Virtual Desktop (AVD)

0
Hi all,Has anyone worked on launching an Azure Virtual Desktop (AVD) application/session from a Mendix application?Our use case is:User logs in to Mendix via Azure Entra ID / SSOUser selects a project/version/context in MendixUser clicks a button to launch an AVD-hosted desktop applicationMendix needs to pass non-sensitive project context, such as ProjectId, VersionIdThe application inside AVD should open the relevant project/context if the user is authorisedI would like to understand the recommended approach for:Launching AVD or a RemoteApp from MendixPassing context from Mendix to the AVD-hosted applicationValidating the user/session on the AVD sideHandling URL parameters or deep links safelyAny limitations or best practices when using Mendix with AVDHas anyone implemented a similar Mendix → AVD integration pattern? Any guidance, architecture suggestions, or lessons learned would be really helpful.Thanks in advance.
asked
1 answers
0

I would approach your use case step by step like this:

.

1. User logs in to Mendix via Azure Entra ID / SSO

For this part, I would use the Mendix OIDC SSO module and configure Microsoft Entra ID as the OIDC provider. Mendix has official support for OIDC SSO, and Entra ID is one of the supported/common IdPs for this setup.


2. User selects project/version/context in Mendix

This part stays fully in Mendix. Once the user selects the project/version, I would store that as a short-lived launch context in backend rather than trying to pass the raw values directly in the AVD URL. That gives better control and avoids URL tampering. This is an implementation recommendation rather than a Mendix-specific feature.


3. User clicks a button to launch an AVD-hosted desktop application

For launching, Azure Virtual Desktop supports both direct launch URLs and the ms-avd URI scheme to connect to a specific desktop or RemoteApp. So from Mendix, the button can call/open one of those launch mechanisms.


4. Mendix needs to pass ProjectId /VersionId

Here I would not pass ProjectId / VersionId directly as raw URL parameters to AVD. Instead, I would generate a short-lived token/context ID in Mendix or in a backend service. The AVD-hosted app can then use that token to call an API and fetch the actual project context after validation. That is safer and cleaner than relying on the launch URL itself. This is the architecture I would recommend.


5. The application inside AVD should open the correct project if the user is authorised

For this, the AVD-hosted application should validate:

  • the logged-in user
  • the short-lived token
  • whether that user is authorised for the requested project/version


AVD itself can use Microsoft Entra ID single sign-on, so the same Entra identity can be reused for the session. That makes the identity side cleaner, but I would still do the final bu.siness authorization in my own backend/application logic.


So overall , my recommended design would be:

  • Mendix + Entra ID OIDC for application login
  • AVD direct launch / RemoteApp for session launch
  • short-lived backend token for passing context
  • backend/API validation inside the AVD-hosted app before opening the project


That would be my preferred implementation instead of trying to make AVD launch URLs carry application-specific business parameters directly

answered