A schema is a formal, shared description of the entities, attributes, actions, relationships, and request context that an authorization system may use. It acts as a contract between policy logic and the surrounding systems: policies can reference only the vocabulary and shapes the schema permits. This prevents a rule from silently relying on an unknown attribute, mismatched action name, or invalid entity type. section 9.2 section 9.10
Schema design is a security decision, not merely documentation. Typed entities and narrowly scoped actions constrain which principals and resources can match a policy. For example, defining a document owner as an Employee prevents policies from treating a customer as an eligible editor, while modeled device context supports consistent device-trust conditions. Broad types such as Any weaken those guardrails and can let newly introduced entities become eligible unexpectedly. section 9.2.2 section 9.2.3
A collaboration schema
A collaboration service can define Employee, Customer, Team, and Document entities; give documents an owner, classification, reader teams, and a delegatable flag; and register doc:view, doc:edit, and doc:share actions. Request context can include managed-device status and time. Policies then share a precise vocabulary for ownership, team membership, external access, and zero-trust conditions. section 9.2.1 section 9.0
namespace ACME {
type RequestContext = {
device: { managed: Bool },
time: { hour: Long, weekday: String },
};
entity Employee in [Team] {
department: String,
on_call: Bool,
manager: Employee,
clearance?: String,
};
entity Customer in [Team];
entity Team {
name: String,
};
entity Document {
owner: Employee,
classification: String,
delegatable: Bool,
employee_readers_team: Team,
customer_readers_team: Team,
};
action "doc:view" appliesTo {
principal: [Employee, Customer],
resource: Document,
context: RequestContext,
};
action "doc:edit" appliesTo {
principal: [Employee],
resource: Document,
context: RequestContext,
};
action "doc:share" appliesTo {
principal: [Employee],
resource: Document,
context: RequestContext,
};
}
This listing shows how entity attributes, relationships, action applicability, and request context are declared together before policies are written. section 9.2.1
A schema supports reliable authorization when it is treated as a maintained system boundary:
- Define the narrowest valid principal and resource types for each action, rather than relying on universal types. section 9.2.3
- Model separate, typed attributes or related entities instead of packing several concepts into fragile strings. section 9.2.3
- Establish consistent names for entity types, attributes, and actions so policies and services use the same vocabulary. section 9.2 section 9.2.3
- Update the schema before adding policies, then validate and test the change. section 9.2.3
- Normalize data from identity, HR, device, and resource systems into the entity shapes that evaluation expects. section 12.2
Schemas also distinguish authorization approaches. In Cedar, a schema provides typed entities, attributes, actions, and context for policy validation. In OpenFGA, it declaratively defines entity types, relations, and permissions; relationship tuples supply the graph facts used to answer access requests. OpenFGA evaluates relationship structure rather than conditional request attributes, making the schema central to relationship-based access control. section 8.3.1 section 8.3
A shared schema can govern multiple policy layers and tenants without giving each layer freedom to redefine the core model. Validating policies against that common vocabulary catches invalid attributes, type errors, unsafe assumptions, and inconsistent action names before publication. It can also expose a data-model gap—for example, when a policy references a department attribute that was never represented for the principal. section 13.5.7 section 10.2.1
