mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 09:26:52 +01:00
bfda67a95a
* Promote security knowledge from community to Microsoft layer Pure git-mv relocation of the SECURITY domain from the community layer to the Microsoft layer. No content changes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address review feedback on security knowledge promotion - do-not-grant-rights-beyond-a-users-entitlement.md: drop the See sample reference to a .good.al file that does not exist - Remove the 'Contributions welcome' boilerplate line from compose-permission-sets, prefer-oauth2, and protect-sensitive-data - protect-sensitive-data-in-temporary-tables: remove the pointless DeleteAll on the locally scoped temp buffer in the good sample and reword Best Practice to note local buffers are cleaned up automatically - Drop guard-bulk-operations-with-istemporary from the promotion; it stays in the community layer pending a decision on whether it is security Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Remove Contributions welcome boilerplate from do-not-grant article for consistency Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
22 lines
1.5 KiB
Markdown
22 lines
1.5 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: security
|
|
keywords: [entitlement, permissionset, license, clipping, sandbox-drift]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
|
|
# Do not grant rights beyond a user's entitlement
|
|
|
|
## Description
|
|
|
|
Entitlements are license-level caps on what a user can access, derived automatically from the BC license tier. Permission sets are application-level grants administered on top of the entitlement. A permission set can only grant within the entitlement's boundaries; grants beyond those boundaries are silently clipped at runtime. This means a permission set authored and validated in a developer sandbox (with a broad license) can appear to work correctly there and fail silently in a customer tenant where users hold a narrower entitlement.
|
|
|
|
## Best Practice
|
|
|
|
When designing a permission set that ships with an extension, consult the entitlement model for the target user population before finalizing the grants. Every object and tabledata right the set expects to grant should be reachable within the intended entitlement tier; if it is not, the set needs to be scoped to licenses that permit it, or the feature needs a different access path.
|
|
|
|
## Anti Pattern
|
|
|
|
Authoring permission sets in a sandbox with full-license context and shipping them without verifying which entitlement tier customer users actually hold. The sets look complete in test; on a real customer they silently lose rights at runtime and the symptom is "the feature does not work for some users" with no obvious authorization error.
|