Back to path
Draft complete11 minutes

Security, privacy, records, and data authorities

Authentication is not authorization

Separate identity proof from the application decisions that permit an action or data access.

The short answer

Authentication establishes confidence about an identity. Authorization decides what that identity may do with a specific resource in a specific context. Successful sign-in does not prove that roles, data policies, privileged actions, or deprovisioning are correct.

01

Core distinction

One user action crosses two gates

At the authentication gate, an identity system verifies credentials or another authentication factor and returns identity information. At the authorization gate, the application evaluates that identity, assigned role, requested action, resource, and relevant policy.

The gates may be implemented by different components. That separation is useful, but it creates mapping and testing duties at every trust boundary.

Identity to permitted actionA valid identity still needs an explicit, tested permission decision.
01AuthenticateVerify identity and obtain trustworthy identity claims.
02MapTranslate claims or group membership into application roles.
03AuthorizeEvaluate role, action, resource, ownership, and policy.
04RecordLog the security-relevant decision without exposing secrets or excessive data.
02

Defense in depth

Do not trust the interface as the control

Hiding an administrative button improves the experience but does not prevent a user from sending the underlying request. Authorization must be enforced at the API, service, database, or other trusted boundary that controls the resource.

For direct browser-to-Supabase operations, tested row-level security and least-privilege grants are essential. Privileged, cross-user, controlled-sensitive, integration, or secret-key operations belong behind an approved server-side boundary in the working Ember pattern.

  • Deny access by default when no rule grants it.
  • Test allowed and denied actions across roles, record ownership, and environments.
  • Keep service-role keys and other privileged secrets out of browser code.
Authorization belongs at every trusted layerInterface cues support the user. Server and data controls protect the resource.
01InterfaceShow appropriate actions, but never treat hiding as enforcement.
02Application/APIValidate the session and enforce action-level permissions.
03Data policyConstrain rows, objects, operations, and grants near the resource.
04AdministrationLimit privileged access and review provider and repository roles.
03

Lifecycle

Access is a process, not a login screen

A complete access model covers request, approval, assignment, use, review, change, suspension, and removal. Group owners and reviewers need to know what each role permits and how provider roles map to business responsibilities.

Evidence should include the role matrix, approval basis, identity-to-role mapping, positive and negative authorization tests, privileged-role justification, review result, and deprovisioning validation. A screenshot of successful SSO proves only part of the path.

  • Test what happens when group membership or employment status changes.
  • Validate provider-side removal when provisioning is manual or unsupported.
  • Review privileged access on an approved cadence and retain the result.

The Ember lens

The project team accepted Microsoft Entra SSO for internal users and Supabase Auth for approved external users as direction on July 22, 2026. The identity governance standard remains APPROVAL NEEDED. No application yet demonstrates the full external-user lifecycle, cross-provider role mapping, row-level policies, negative authorization tests, completed access review, or provider-side deprovisioning validation, so those controls remain MISSING or INSUFFICIENT.

Responsibility remains

The identity provider authenticates according to its configured service. Platform Engineering supplies supported integration patterns. Each application team defines and enforces application roles and resource permissions. Owners and access-governance authorities approve and review access within their authority. Cyber evaluates the security posture and exceptions; it does not implement the application's authorization logic.

Apply it

Find the missing authorization gate

An internal user signs in through Entra. The interface hides the manager action, but changing an API request lets the user approve another team's record.

  1. 01Identify which part of the flow succeeded and which control failed.
  2. 02Name the trusted boundary that should enforce the permission.
  3. 03Write one allowed and two denied test cases for the action.
  4. 04List the role-mapping and log evidence a reviewer should request.

Check your understanding

Make the ideas usable

2 questions
01A user successfully signs in with Entra. What does that prove?
02Why is hiding a button insufficient authorization?

Source trace

Reviewable by design

Content owner: Wesley Almeida
Last reviewed: 2026-08-18

  • Ember identity governance and access review standard draft05-projects/vibe-coding-platform/resources/standards/
  • Ember platform reference architecture and data flow draft05-projects/vibe-coding-platform/resources/diagrams/platform-reference-architecture-and-data-flow-draft-2026-07-13.md
  • NIST digital identity guidelines
  • Supabase row-level security guidance