Identity & Access — Overview
Honeyframe keeps every identity in one directory — the people who build and administer your workspace, and the people who only ever open a published app — and governs all of them through one authorization engine. This section is the map. Each page below goes deep on one piece of it.
Two kinds of identity
| Platform users | Site users | |
|---|---|---|
| Who they are | People with a seat in your workspace — build, administer, or consume | People who only open a published app (a webapp) — never the build surface |
| Licensing | Consumes a licensed seat (admin / designer / analyst / viewer) | Seat-free — invite as many as you need |
| Write access | Depends on seat + group grants | Never — read-only, unconditionally |
| Scope | The whole organization | One deployment (a subscription_id) at a time |
| Set up on | Groups & Permissions | Site Users |
Both kinds of identity are authorized the same way underneath — the same groups, the same permission strings, the same resolver. What differs is who they are and what ceiling applies to them before that resolver ever runs.
Two axes: role vs. group
Honeyframe's access model is deliberately two-axis, and the two axes answer different questions:
- Role is the capability axis — "what you're allowed to attempt." A
platform user's role (
admin/designer/analyst/viewer) sets their baseline: can this person build recipes and flows at all, or are they read-only by design? A site user'srole(viewer/editor) is narrower still, and — see below — doesn't actually widen anything today. - Group membership is the authorization axis — "what you can see." Permissions are never granted to a person directly. They're granted to a group, and a person's real access is the union of every grant held by every group they belong to — narrowed to one dashboard or one project, or opened organization-wide. This is the mechanism in Groups & Permissions.
A person can hold the "right" role and still see nothing, if no group grants them anything. Role decides whether a capability exists for them at all; group membership decides which specific resources it applies to.
Building a dashboard requires a licensed seat
Dashboard and flow authoring is a project.edit-class capability — gated to
a designer-or-better platform seat. Site users can't be promoted into
it by giving them a wider group grant: every write-class permission is
denied for a site user unconditionally, before any group lookup even
runs. It isn't a gap that a broader grant would close — it's an
architectural wall.
In practice: if someone who normally only opens a published app now needs to build or edit dashboards, they need a real platform seat, not an elevated site-user account. Site users are viewers by design.
Where to go next
| Page | Covers |
|---|---|
| Groups & Permissions | Creating groups, granting org-wide vs. per-resource permissions, the Authorization Matrix |
| Site Users | Inviting and managing seat-free app end-users, site scoping, the login flow for app developers |
| Applications & SSO (OIDC) | Registering an application for "Login with Honeyframe" |
For the full permission-string catalog, seat types, and superadmin rules, see Security → Users and Groups and Security → Permissions Reference. For minting a Personal Access Token for scripts and CI, see Developer → Authentication.