Finance | Project Operations, Human Resources, ...

Shielding HR compensation data via XDS and securing the OData/Data Entity bypass

(1) Share

Report

Posted on by Huma Selot CU200816...

194

I need to securely shield highly sensitive HR compensation and payroll tables using context-driven Extensible Data Security (XDS) policies in D365 F&O.

While I can secure the UI forms, we know that XDS policies are natively bypassed by OData endpoints and Data Entities (leaving the data vulnerable to "Open in Excel" or third-party API extractions). What is the Microsoft-recommended architectural pattern to fully secure this HR data? Do we need to apply additional row-level security directly on the Data Entities, or is there a way to force the XDS context to respect OData queries?

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (5)

Answers (0)

Sort by

Suggested answer

NikolajSorensen 1,816 on at

Like (1)

Report
Copy link

Link copied!

I wonder where you understood that XDS policies natively bypass Data entities?
In your previous post about this it is clearly explained that XDS policies will also affect data entities, if you restrict access to them in your security policy.

I realize that you first got incorrect advise and reply because it was someone asking an AI agent, but in reality it works.
https://community.dynamics.com/forums/thread/details/?threadid=feebd7f2-599e-f111-b8dc-7c1e520ce2de

So try it out - you should see that it works.

Was this reply helpful? Yes No
Suggested answer

SajeedMullaji 798 on at

Like (1)

Report
Copy link

Link copied!

@Huma Selot CU200816...
Why XDS alone is insufficient:
XDS policies enforce row-level filtering at the AOT query layer. OData and Data Entity calls execute through a separate service stack that bypasses this layer unless the entity is specifically configured to respect it.
The three layer pattern:
Layer 1 — XDS policy on the root table:
Create your XDS security policy targeting HcmWorker or the specific compensation table as the constrained table. Ensure your policy's primary table matches the exact root data source of the HR Data Entity — not just the form data source. If the entity uses a view check the underlying base table the view pulls from.
Layer 2 — AOSAuthorization property on the Data Entity:
Open your HR Data Entity in Visual Studio. Set AOSAuthorization to CreateReadUpdateDelete. This forces the entity to respect AOS security checks including your XDS predicate when called via OData or DMF. Without this property set the entity bypasses your XDS policy entirely regardless of how well it is configured.
Layer 3 — Explicit Data Entity security privilege:
Create a dedicated privilege for the HR compensation data entity with Read permissions scoped only to authorized HR roles. Remove the entity from any broad standard roles that grant blanket data service access — particularly roles that include Data entity wildcard grants. This ensures unauthorized users cannot call the OData endpoint at all.
For Open in Excel specifically:
The Office integration uses the same OData stack. Layers 1 and 2 together enforce XDS on Open in Excel exports. Test by attempting an Open in Excel export as a restricted user — only their authorized compensation rows should appear.
Additional hardening for payroll specifically:
Consider setting the Data Entity's IsPublic property to No in Visual Studio — this removes it from the public OData metadata endpoint entirely, making it invisible to third party API discovery tools scanning your environment.
All three layers must be configured together. Any single layer alone leaves a gap.

If it helps, Mark answered.

1 people found this reply helpful.

Was this reply helpful? Yes No
Martin Dráb 240,521 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

@SajeedMullaji Are you a bot or someone who doesn't bother to read the discussion, because his goal is just to produce some content, not to actually help anyone?

If you read it, you'd have surely reacted to NikolajSorensen, instead of just generating almost the same (incorrect) content as in the thread mentioned by NikolajSorensen. This is already the third thread where your statement about XDS with OData was challenged, but you haven't seemed to notice.

Was this reply helpful? Yes No
Suggested answer

AS-21081411-0 26 on at

Like (0)

Report
Copy link

Link copied!

Agreeing with Nikolaj — the premise isn't right. XDS filters what the policy names as constrained. If the policy names only the underlying tables and not the entity, nothing filters on the entity. That's what looks like a bypass. Name it, then test as a restricted user.
On forcing the context: you can't. Application context needs XDS::SetContext called in code, and nothing runs on an inbound OData call. Role context does work, since roles travel with the request. If your HR policies use application context, that's probably the real gap.
Two things that aren't XDS. If a role should have no API access at all, deny the entity's Data services and Data management entry points — a broken filter still returns rows. And if the concern is salary amounts rather than which workers, XDS won't help; it filters rows, not columns.
Worth checking which user your app registration maps to, too. Everything above is evaluated against that account.

Was this reply helpful? Yes No
NikolajSorensen 1,816 on at

Like (0)

Report
Copy link

Link copied!

Well there is a pretty clear correlation between the original posters previous questions and the responder to said questions. Especially if you then check which of the original posters' question have verified answers and the user with answers that are verified.
Dear mods, please strike down on the obvious Q&A farming either completely or partially AI generated.
Either I'm stupid for replying to clearly AI generated Q&A and calling it out, therefor providing AI models with even better training content, or the forum will suffer - which it probably will anyway…

Was this reply helpful? Yes No