Access Control
Access Control is how S-Launch decides who can do what. Every identity — whether a person or an integration — is granted a set of permissions, and every action in the platform is checked against them.
This section explains the concepts and how they fit together. To manage them on screen, see the Admin › Access Control views; for the programmatic reference, see the API.
The model
A few building blocks combine to control access:
- Scopes are the atomic permissions (e.g.
store:read). Every feature and API endpoint requires one or more scopes. - Scope Sets — also called Roles — are named, reusable bundles of scopes. Define a role once and attach it anywhere.
- Users are the people with accounts. Their type (External, Internal, or Guest) sets the baseline for what they can reach.
- Groups collect users so scopes and assignments can be managed in bulk.
- API Keys are non-human identities for integrations — they carry scopes just like users.
In short: identities (users and API keys) are granted scopes — directly, through a role / scope set, or by belonging to a group — and a user's type sets the starting point.
The pieces
| Concept | What it is | Concept page | API reference |
|---|---|---|---|
| Users | People with accounts; typed External / Internal / Guest | Users | Admin › Users |
| Groups | Collections of users for bulk assignment | Groups | Admin › Groups |
| Roles (Scope Sets) | Reusable named bundles of scopes | Roles (Scope Sets) | Admin › Scope Sets |
| Scopes | The atomic permission vocabulary | Scopes | Scopes catalogue |
| API Keys | Non-human identities for programmatic access | API Keys | Admin › API Keys |
How access is granted
A principal's effective permissions come from any combination of:
- Scopes assigned to it directly.
- Scopes from any roles (scope sets) attached to it.
- Scopes inherited from groups it belongs to.
The admin scope is special: it grants access to everything, so no other scopes are needed alongside it. Admin is not a user type — it's simply this scope assigned to an internal user. See Internal Users.
Concepts here, screens elsewhere
This section describes what each piece is. To actually create users, build roles, or issue API keys in the interface, use the Admin › Access Control views.