Security and Access Control
Security and Access Control tests authentication, authorization, and data protection in ODC. Authentication establishes who the user is; authorization decides what they can do. ODC provides built-in identity and supports enterprise federation through SSO, so the exam expects you to separate identity concerns from application roles and to enforce authorization on the server.
Core rules
- Model roles by job function, not by individual. Typical roles are Employee, Approver, and Auditor, not Alice or Bob.
- Enforce authorization on screens, server actions, and exposed APIs. Hiding a UI control is not access control.
- Apply least privilege to integration accounts and service credentials; do not reuse an admin account for routine calls.
- Scope data by tenant or organization at query time, not only at login time.
- Keep secrets out of code and screen variables. Use secure configuration and rotate credentials.
- Validate and encode untrusted input, and log security-relevant events without logging secrets.
Worked example
An expense app has Employee, Approver, and Auditor roles. Employees submit expenses; approvers see only their team's pending items; auditors read all approved records but cannot edit. The tempting design hides the Approve button for employees and lets the server action trust the caller. The defensible design checks the role inside ApproveExpense, verifies the expense belongs to the approver's team, and returns an authorization error otherwise. Reasoning: a direct API call bypasses the screen entirely, so the server action must be the enforcement point.
Traps
- Client-side role checks only, which fail as soon as someone calls the API directly.
- Role explosion: creating a role for every screen instead of every job function.
- Over-privileged integration accounts that can read all tenants.
- Putting secrets in module settings that are visible to developers.