Authorization architecture

Understand how identity, permission evidence, OpenFGA, and application checks constrain every read path.

Trang này chưa có bản dịch tiếng Việt đã được duyệt. Nội dung tiếng Anh đang được hiển thị tạm thời.

OrgMemory does not reduce access control to one role or one prefilter. A content read succeeds only when identity, tenant, relationships, source evidence, classification, lifecycle, and projection identity agree.

Authorization architecture with five mandatory gates: authenticate, bind identity, check OpenFGA relationships, apply canonical evidence, and audit before disclosure.
Layered authorization gatesAuthorization is an intersection, not a role hierarchy. Failure or ambiguity at any gate fails closed, and protected-object denial remains opaque.

Authentication is not authorization

OIDC issuer and subject are the only automatic identity lookup key. A verified email may select exactly one open invitation during first sign-in, but the durable binding is still issuer/subject. Email, display name, identity-provider roles, and the local application role cannot grant organization or Knowledge access.

Browser and bearer paths resolve the same server-derived actor. Unknown, inactive, stale, or ambiguous identity state fails closed.

Relationship authorization

OpenFGA relationships govern organization administration, Knowledge Spaces, stable Knowledge Assets, and registry Assets. The versioned model is exercised with allow, deny, list-object, and type-restriction tests.

An administrator can create a Knowledge Space and author supported grants, but cannot write arbitrary knowledge_asset tuples. Connected sources own the ACL ceiling for their content; a second writer would allow source and product permissions to diverge.

Source evidence and classification

Canonical retrieval intersects:

  1. organization and active actor;
  2. OpenFGA candidate Assets;
  3. immutable ingestion ACL;
  4. current sealed complete ACL head;
  5. source-principal mappings and current group membership;
  6. lifecycle, current version, source revision, model, and projection state;
  7. classification policy.

Control-plane roles and knowledge roles are separate. In particular, an Admin is not automatically an Executive.

ClassificationOrdinary knowledge rolesExecutive
PublicAllowed, subject to every other gateAllowed, subject to every other gate
InternalAll employees, subject to every other gateAllowed, subject to every other gate
ConfidentialOwn department onlyMay cross departments when the other gates allow
RestrictedDeniedAllowed when the other gates allow

Opaque denial

Eligible callers receive the same generic not-found response for missing, changed, or unauthorized object identifiers. Citation content is served through an opaque API route that performs a fresh authorization and integrity check. Object-store addresses and denial reasons are not disclosed.

A caller missing the control-plane role is rejected at the request boundary; that is distinct from hiding whether a specific protected object exists.

Audit evidence

Permission audit is append-only and commits independently of the surrounding business transaction. It stores actor, resource, operation, decision, reason, policy, request fingerprint, query fingerprint, and exact ACL snapshot IDs. Raw query text and unrestricted metadata are not stored.

An audit attempt proves that a decision was recorded, not that the surrounding business transaction committed.

Cập nhật lần cuối