We design and implement the broker layer that gates every file open with real SSO and per-record authorization, so nobody ever hands out a reusable link again.
Azure Files supports identity-based auth for SMB mounts, and OAuth-over-REST for tools like AzCopy — but nothing that maps one Salesforce user to one file, enforced the moment they click a link.
A raw file link just returns an auth error. Browsers can't attach the headers Azure's REST API requires — there's no page to redirect to, no prompt to answer.
Works, but it's one shared secret standing in for every user. No per-person audit trail, no revocation without breaking everyone, and a real credential if it leaks.
Grants admin-level access that bypasses directory and file ACLs, unless you've separately built out SMB-based identity ACLs most orgs never touch.
Real per-user RBAC — but only for domain-joined machines mounting a network drive. Irrelevant to anyone clicking a link from inside Salesforce.
The user's browser only ever talks to a small authorization service. It holds its own credential to Azure Files, checks who's asking and what they're allowed to see, then streams the file back — or it doesn't.
We implement this directly inside your Azure subscription and Salesforce org — nothing shared, nothing multi-tenant. You own the Function, the resource group, and the code when we're done.
We map your Salesforce object model to your Files layout, confirm your Entra tenant and SSO setup, and settle the authorization rule.
We stand up the broker Function, wire Easy Auth, provision managed identity access, and build the authorization logic — plus staging before production.
Documentation, a walkthrough with your team, and a defined support window while your engineers take over.
This is a narrow, technical engagement. It's a strong fit for some teams and the wrong tool for others.
Three engagement sizes, based on how many file types and authorization rules you need. Every tier ends the same way: your team holding a working, documented broker.
One Salesforce object type maps to one file location, with a single authorization rule (e.g. "owner or their manager").
Multiple Salesforce object types, each with its own file location and authorization logic — the shape most real orgs actually need.
Your Azure Files share sits behind a private endpoint with no public access — the broker needs its own VNet integration to reach it.