Identity & access
Every request arrives as a principal, mapped to a profile, and permissions — granted to groups — decide who can see and change what, enforced by a shared evaluator on every read and write.
Principal & profile
Authentication resolves a principal — the account behind the request, whether it signed in as a person or as an API token. The principal is just identity; the profile is who they are in your data, a separate record with its own id. Your code reads both from the request context, so a controller or a route always knows who it's acting for — and one principal can carry more than one profile.
Permissions
Each entity carries its own permissions — a grant of an action, like view, edit, or manage, to a group. On a read, the owning service filters the results to what you're allowed to see; on a write, it verifies your access before the change lands. Public items need no grant, and a child inherits its parent's access.
Groups
Permissions are granted to groups. A principal gets access by belonging to a group that holds the grant, so access stays easy to reason about: put a principal in a group, and it inherits everything that group can do. Built-in roles come ready to use, and you add your own.
Keep exploring
Local setup and the platform reference for APIs, services, identity, and runtime behavior.
The patterns Bosca is built from — and built with.
Core and implementation modules in one Gradle build, with compile-time wiring.
From a model to a GraphQL and REST API.
Jobs, events, caching, scripting, and the CLI.