Securing FME Flow MCP with organizational Microsoft Entra ID accounts

I totally second this. Especially because SAML has another flaw, where incorrect SAML Identity Provider URLs under Authentication Services are created, in case your hostname contains the string 'fmeserver’.(FMEFLOW-20430)

Yes, this needs to be addressed!  I haven’t heard of any expected fixes yet.  I can confirm that using Auth0 as a federated connection with Entra works. However, not acceptable long term solution for an enterprise. In my case every user needs to be provisioned, and the auditing in FME is the same as any other SAML user.     

Hi ​@rsun , thanks for the detailed question, and thanks ​@jglick and ​@tb09114  for chiming in. I’ll take your questions in order.

1. Fix timing. This is tracked as FMEFLOW-29112. Unfortunately the fix is taking longer than we hoped, and it’s currently targeting 2027.1. It turned out to be much more complex than expected, because of how Entra implements OAuth for MCP. We’ve had to rework the authentication mechanism itself rather than patch around it. That target could still change, so the known issues article will have the latest status.

2. Recommended setup today. Short of using a different identity provider, there is no recommended way to use Entra directly with MCP in FME Flow right now. As ​@jglick  mentioned, putting an intermediary IdP in front of Entra (federating Entra into it) is one option people have used. I can’t offer guidance on how to set that up, so you’d want to validate it against your own security and Conditional Access requirements.

3 and 4. User provisioning and audit logging. Every MCP user is provisioned as an FME Flow user through SAML. That’s what lets you keep per-user roles, logging, and user details available in the MCP workspaces, and it applies whether or not an intermediary IdP is involved. As ​@jglick  noted, auditing for these users looks the same as for any other SAML user. Access can’t currently be managed purely from the Entra side without those FME Flow users.

I would be curious on any feedback about user provisioning and what cases may benefit with direct authentication. 

I know it’s not the update with the best news just yet- it is a widely recognised challenge with MCP adoption in FME Flow and so it has been a priority with the development team(s) and the product management group lately.

Hi ​@NickAtSafe,

Thanks for explaining. Here are a few practical use cases from a local government perspective.

Many local governments here in BC rely heavily on Microsoft 365. In our organization, staff already use their Microsoft account to sign into our enterprise AI solution, ArcGIS and majority of business infomation systems. Ideally, they could use FME MCP tools through their AI agent with that same identity, without us having to manage another set of users/groups in FME Flow.

This goes beyond GIS. For example, staff could ask an agent to:

• Find municipal assets and submit inspection or maintenance queries/updates in ArcGIS.
• Query information or submit records in finance, fire or other municipal systems.
• Find documents in SharePoint or OneDrive, update a SharePoint List, or generate a report using information from several systems.

In each case, the employee should only be able to access information and perform actions they already have permission to use. We should also be able to see who did what, including in FME’s audit logs and the receiving system’s records, such as ArcGIS editor tracking and SharePoint document library versioning (modified by, created by).

We can already restrict who is allowed to use a particular AI agent. The additional capability we need is for FME to securely act on behalf of that person when connecting to the systems behind the tools. Access to an agent alone should not give someone broader access to those systems.

An easy setup through an Entra app or ArcGIS Enterprise/Online app registration, with support for using each employee’s identity in downstream connections, would make adoption much easier. I believe that organizations using Google Workspace or other identity providers would likely want the same experience.

FME’s value is its ability to connect and process information across so many systems and data formats with unlimited potentials. Making organizational sign-in, permissions and individual accountability work smoothly throughout that process would help us bring those capabilities to more staff.

I suggested the same for FME Flow App as well. 

More than happy to chat in person with you!

Cheers,
Reno

Hi ​@NickAtSafe, 

It sensed the answer regarding FMEFLOW-20430 did not make it into your answer. 😉

Hi ​@tb09114 - I did forget to mention it 😀 I did do some digging into on my own and there is a comment from our support team that says “this is only a UI issue and if the URLs are corrected before applying on the SAMl IDP side, the SAML configuration should work as designed. “

I’ve had to check with another colleague about the status of it- they’re away right now, but as soon as I hear more, I’ll report back.

Hi ​@NickAtSafe,

any news from your colleagues about the issue of malformed Audience URI and ACS URL?

The way I understand your colleagues comment it seams I should have to possibility to correct the URLs, but I do not. Both Audience URI and ACS URL are shown in the SAML IPS, but I cannot edit them.

Bests Thomas

Hi ​@tb09114! 

If I understand correctly, you mean the URLs you obtain from the Admin Authentication Services> SAML Configuration page which you need to pass to an Identity Provider. 

If yes, our documentation outlines the correct Audience and Assertion Consumer Service (ACS) URLs. You can enter these values directly:

Where <FMEFlowWebURL> is the fully-qualified hostname for your FME Flow, including both the hostname and domain (for example, https://fmeflow.domain.com).

Where <FMEFlowWebURL> is the fully-qualified hostname for your FME Flow, including both the hostname and domain (for example, https://fmeflow.domain.com).

• Entity ID (Audience URI): Set to <FMEFlowWebURL>/fmesaml/saml2/service-provider-metadata/fmeserver
• Single Sign On URL (Application Callback URL, Assertion Consumer Service URL): Set to <FMEFlowWebURL>/fmesaml/login/saml2/sso/fmeserver

This article might also be a good resource here: Configuring FME Flow for Azure AD SAML Authentication

Let me know if this helps or if I misunderstood anything! 

Hi ​@desiree_at_safe , our <FMEFlowWebUrl> contains “fmeserver” hence Audience URI and ACS URL are both malformed to https:/.<domain>.com/...

As I understand it in earlier versions of FME Flow it was possible to correct this but in version 2026.2 the values cannot be adjusted, but just copied.