16.1 Role-Based Security Architecture

16.1 Role-Based Security Architecture

Quick Answer: The Role-Based Security Model (RBAC) in Dynamics 365 Finance and Operations provides a declarative, four-tier authorization hierarchy: Users are assigned Security Roles (representing business functions or personas), roles contain Duties (representing distinct business responsibilities such as approving vendor invoices), duties contain Privileges (representing rights to perform specific jobs such as maintaining customer records), and privileges grant access to Entry Points and Permissions on securable objects (tables, fields, methods). Entry points support five primary types: MenuItemDisplay, MenuItemOutput, MenuItemAction, WebResource, and ServiceOperation. Access levels scale hierarchically from NoAccess through Read, Update, Create, Correct, to Delete. Conflicting role permissions resolve via a permissive union model (the highest granted privilege wins). Role assignments can be performed manually or automated using rule-based queries evaluated by background batch jobs.

---

1. The Role-Based Security Hierarchy

Security in Dynamics 365 Finance and Operations is organized around business functions rather than direct object permissions. Users are never granted direct rights to tables, forms, or menu items. Instead, authorization flows strictly downward through four metadata abstraction layers:

Dynamics 365 F&O Security Hierarchy

┌─────────────────────────────────────────────────────────────┐
│                            User                             │
│             (Individual user account / identity)            │
└──────────────────────────────┬──────────────────────────────┘
                               │ Assigned to
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                        Security Role                        │
│         (Business persona: e.g., Accounts Payable Clerk)     │
└──────────────────────────────┬──────────────────────────────┘
                               │ Composed of
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                            Duty                             │
│     (Business responsibility: e.g., Maintain vendor master) │
└──────────────────────────────┬──────────────────────────────┘
                               │ Composed of
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                          Privilege                          │
│       (Action-level task: e.g., View vendor invoices)       │
└──────────────────────────────┬──────────────────────────────┘
                               │ Grants access to
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                Entry Points & Securable Objects             │
│    (Menu items, forms, service operations, tables, fields)  │
└─────────────────────────────────────────────────────────────┘

Security Element Roles and Definitions

• Security Role: Represents the major business role or persona of a worker (e.g., Accountant, Purchasing Manager, Warehouse Worker). A role consists of multiple duties and sub-roles. Roles can also contain privileges directly, although Microsoft best practices dictate that privileges should be organized into duties first to support compliance, auditability, and Segregation of Duties.
• Duty: Represents a specific business process or responsibility within a department (e.g., Maintain vendor invoices, Inquire into customer payments). Duties group related privileges together and serve as the operational boundary for Segregation of Duties (SoD) policies. A duty can belong to multiple roles, but duties cannot contain other duties.
• Privilege: Represents the granular permission required to perform a discrete task or job step (e.g., Generate customer statements, Maintain sales orders). A privilege contains one or more entry points along with specific permissions on underlying tables, fields, and server methods.
• Permissions & Securable Objects: The physical assets protected by the Application Object Server (AOS), including menu items, forms, form controls, table records, individual table fields, and custom services.

Sub-Roles and Role Inheritance

Security roles support inheritance via sub-roles. An enterprise role (e.g., Regional Operations Lead) can inherit an existing role (e.g., Inventory Clerk) as a sub-role. All duties, privileges, and entry points belonging to the sub-role are automatically granted to users assigned to the parent role. This hierarchy simplifies administration across complex organizations with overlapping responsibilities.

---

2. Entry Points, Securable Objects & Access Levels

An Entry Point is a pointer within a privilege to a securable navigation element or service invocation. When a user activates a menu item or calls a web service, the AOS checks the user's effective privilege entry point permissions.

Entry Point Types

Access Level Hierarchy

Entry points assign an access level (AccessLevel) that determines what operations the user can perform against the target form or resource. The security model uses an ordered hierarchy of access levels:

Access Level Hierarchy (Union Model)

  Delete       (Level 5: Full CRUD — Create, Read, Update, Delete)
    ▲
    │
  Correct      (Level 4: Read, Update, Create + Edit historical time slices)
    ▲
    │
  Create       (Level 3: Read, Update, Create new records)
    ▲
    │
  Update       (Level 2: Read, Update existing records; cannot create or delete)
    ▲
    │
  Read         (Level 1: View records in read-only mode; forms open uneditable)
    ▲
    │
  NoAccess     (Level 0: Item hidden from navigation; explicit denial)

• NoAccess (0): Explicitly denies access. The menu item is completely hidden from menus, navigation panes, and search bars.
• Read (1): Allows viewing records. Forms open in read-only mode, and editing controls are disabled.
• Update (2): Allows modifying existing records. The user cannot insert new records or delete existing rows.
• Create (3): Allows creating new records and editing existing records. Inherits Read and Update.
• Correct (4): Specialized access level used primarily with Date-Effective (Valid-Time-State) tables. Allows editing past and future historical records directly without creating new date-effective slices.
• Delete (5): Full CRUD access. Allows reading, updating, creating, and permanently removing records.

The Permissive Union Model

When a user is assigned multiple security roles that specify conflicting access levels to the same entry point, Dynamics 365 Finance and Operations evaluates effective permissions using a permissive union model (the highest granted permission wins):

[!IMPORTANT] The Union Model Principle: Dynamics 365 Finance and Operations evaluates multiple role assignments additively. Unlike systems where an explicit 'Deny' trumps all 'Allows', F&O's NoAccess simply represents numeric access level 0. If Role A grants NoAccess to a menu item, but Role B grants Read, the user is granted Read. The only way to enforce row-level data restrictions that cannot be overridden by other roles is via Extensible Data Security (XDS) policies.

---

3. Assigning Security Roles to Users

Administrators assign security roles to user accounts through two distinct mechanisms: manual assignment and rule-based automatic assignment.

Role Assignment Strategies

┌─────────────────────────────────────────────────────────────┐
│                     Manual Assignment                       │
│  • Configured per user in System administration > Users     │
│  • Static; requires manual administrative intervention      │
│  • Best for exceptional, high-privilege administrative roles│
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                Automatic Assignment Rules                   │
│  • Query-based criteria (Entra ID groups, title, department)│
│  • Evaluated dynamically by background batch job            │
│  • Scales across thousands of enterprise employees          │
└─────────────────────────────────────────────────────────────┘

Manual Assignment & Legal Entity Scoping

In System administration > Users > Users, administrators assign roles directly to a user profile. Crucially, roles can be assigned globally or scoped to specific legal entities:

• Grant access to all organizations: The user exercises the security role across every legal entity (DataAreaId) in the environment.
• Grant access to specific organizations individually: The role is restricted to designated legal entities (e.g., granted Accounts Payable Clerk only in legal entity USMF and DEMO).
• Grant access by organization hierarchy: The role is granted based on an organizational hierarchy (e.g., all retail business units under the North American Operating Unit tree).

Rule-Based Automatic Role Assignment

Enterprise organizations configure dynamic membership rules under System administration > Security > Assign users to roles:

1. Select a security role (e.g., Employee or Warehouse Operator).
2. Click Add rule to create a query-driven condition based on fields in the UserInfo, DirPerson, DirPersonUser, or HcmWorker tables.
3. Common criteria include:
   • Microsoft Entra ID (Azure AD) Security Groups: Automatically grants roles when users belong to specific corporate directory groups.
   • Worker Department or Job Title: Grants operational roles based on HR employment records.
4. Click Run automatic role assignment or schedule the recurring batch task SysSecurityUserRoleRule to evaluate rules on a schedule. When an employee transfers departments or leaves a directory group, the batch job revokes the obsolete role automatically.

---

4. Security Diagnostics on Forms

One of the most powerful diagnostic utilities for developers and security administrators is the Security Diagnostics tool, built directly into the Dynamics 365 Finance and Operations client framework.

Security Diagnostics Inspection Workflow

┌─────────────────────────────────────────────────────────────┐
│               User reports form or button issue             │
│  "I cannot see the 'Post' button on the Sales Order form"   │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│          Action Pane > Options > Security Diagnostics        │
│  (Opens hierarchical security analysis panel for the form)  │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                   Inspect Security Tree                     │
│  • Identifies required Privilege: SalesOrderInvoicePost     │
│  • Identifies parent Duty: Maintain sales order invoicing   │
│  • Identifies assigned Roles containing this Duty           │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                    Remediation Action                       │
│  Assign the identified Duty/Role to the user, or add the    │
│  Privilege to an existing custom role using extension       │
└──────────────────────────────┬──────────────────────────────┘

Operating Security Diagnostics

1. Navigate to the form in question (e.g., Accounts receivable > Orders > All sales orders).
2. In the Action Pane, switch to the Options tab and click Security diagnostics.
3. The tool displays a modal panel listing:
   • The exact securable menu item driving the form.
   • All Roles, Duties, and Privileges that grant access to that menu item.
   • For any specific control (such as a posting button), it identifies the specific child privilege or entry point governing that control.
4. Administrators can directly click Add role to user or Customize role from within the diagnostics flyout, eliminating the guesswork of searching through thousands of AOT security elements.

[!CAUTION] Diagnostic Scope Limitation: The Security Diagnostics tool analyzes metadata-based role, duty, and privilege access only. It does not evaluate Extensible Data Security (XDS) policies, record-level security, or programmatic runtime checks (e.g., X++ hasSecurityRight() or workflow status validations). If a user has the correct role but still cannot see a specific record, the root cause is typically XDS or legal entity filtering, not entry point permissions.

---

5. Granular Security: Table Fields & AOSAuthorization

Beyond entry points, developers can enforce fine-grained defense-in-depth directly on table fields and table methods within AOT Privileges.

Table & Field Security Permissions in Privileges

Under an AOT Privilege, developers can navigate to the Permissions > Tables node to override access rights for specific tables and fields:

• Table Permissions: Set EffectiveAccess on a table (e.g., restricting CustTable to Read even if the form entry point allows Update).
• Field-Level Permissions: Override access to sensitive columns (e.g., setting CreditMax or BankAccount on CustTable to Read or NoAccess). Even if a user has full Delete permissions on the CustTable entry point, the restricted field will render disabled or hidden across every form in the system.

<!-- Metadata Representation of Field-Level Privilege Restriction -->
<AxSecurityPrivilege xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Name>CustCustomerCreditLimitMaintain</Name>
  <Label>@SYS123456</Label>
  <Permissions>
    <Table>
      <Name>CustTable</Name>
      <Fields>
        <AxSecurityPrivilegeField>
          <Name>CreditMax</Name>
          <Grant>Update</Grant>
        </AxSecurityPrivilegeField>
      </Fields>
    </Table>
  </Permissions>
</AxSecurityPrivilege>

Table Method Authorization: AOSAuthorization

Tables have an engine-level property called AOSAuthorization. By default, AOSAuthorization is set to None. Developers configure this property to enforce explicit authorization on table operations:

When AOSAuthorization is enabled on sensitive tables (such as ledger parameters, bank accounts, or tax setup tables), direct calls from untrusted client code or classes cannot modify the table unless the invoking user's role explicitly includes permissions for that table under a privilege's Permissions node.

---

6. Scenario Walk-Through: Configuring a Custom Accounts Payable Specialist Role

Business Context

Contoso Enterprise requires a customized security persona for a newly created position: Junior Accounts Payable Specialist. The compliance officer outlines the following precise authorization requirements:

1. Vendor Viewing: Must open and view all vendor master records (VendTable) in read-only mode.
2. Invoice Entry: Must create and edit vendor invoices in the invoice workspace (VendInvoiceWorkspace), but must never be permitted to execute the invoice posting action (VendInvoicePost).
3. Bank Account Protection: Under no circumstances should the specialist view or modify vendor bank account numbers (VendBankAccount table and CustVendBankAccount table), to protect against disbursement fraud.
4. Automated Provisioning: All employees with the job title AP Junior Specialist in Microsoft Entra ID must automatically receive this role upon provisioning.

Step-by-Step Implementation Flow

Junior AP Specialist Role Construction Structure

Privilege 1: ConVendTableInquire
 └── Entry Point: VendTable (MenuItemDisplay) -> AccessLevel: Read

Privilege 2: ConVendInvoiceMaintainNoPost
 ├── Entry Point: VendInvoiceWorkspace (MenuItemDisplay) -> AccessLevel: Create
 └── Permissions > Tables > VendBankAccount -> EffectiveAccess: NoAccess

Duty: ConMaintainVendorInvoicesJunior
 ├── Includes: ConVendTableInquire
 └── Includes: ConVendInvoiceMaintainNoPost

Security Role: ConJuniorAPSpecialistRole
 ├── Includes Duty: ConMaintainVendorInvoicesJunior
 └── Automated Assignment Rule: Query on HcmWorker.Title == 'AP Junior Specialist'

1. Create Privileges in Visual Studio:
   • Create ConVendTableInquire. Add entry point VendTable (MenuItemDisplay) with AccessLevel = Read.
   • Create ConVendInvoiceMaintainNoPost. Add entry point VendInvoiceWorkspace (MenuItemDisplay) with AccessLevel = Create. Crucially, omit the action menu item SalesFormLetter_Invoice or VendInvoicePost.
   • Under ConVendInvoiceMaintainNoPost > Permissions > Tables, add VendBankAccount and set EffectiveAccess = NoAccess.
2. Group Privileges into a Custom Duty:
   • Create Duty ConMaintainVendorInvoicesJunior.
   • Add both privileges to the duty.
3. Create the Security Role:
   • Create Role ConJuniorAPSpecialistRole.
   • Assign ConMaintainVendorInvoicesJunior to the role.
4. Configure Automated Assignment Rule:
   • In the F&O client, navigate to System administration > Security > Assign users to roles.
   • Select ConJuniorAPSpecialistRole and click Add rule.
   • Configure query: Join UserInfo to DirPersonUser to DirPerson to HcmWorker. Add range: HcmWorker.Title == "AP Junior Specialist".
   • Run the automatic role assignment job to verify user mapping.
5. Verify Security:
   • Log in as a test junior AP clerk.
   • Open the vendor list; confirm the form is read-only.
   • Open invoice entry; confirm new invoices can be keyed, but the Post button is missing or disabled.
   • Open vendor banking details; confirm the tab and fields are completely hidden.

---

7. Exam Traps & Architectural Pitfalls